Comfort  Automation/ Security System Forums Home

 Moderated by: hendy  
AuthorPost
richylloyd
Member
 

Joined: Monday Aug 29th, 2011
Location: Woking, United Kingdom
Posts: 23
Status: 
Offline

  back to top

Hi
I've just upgraded my UCM/CBUS unit to V2 (by replacing the CBUS plug-in) and am running V7.068
Most of the functionality is working as it should but I have a few responses that contain multiple CBUS commands (AllOff etc..) that are not processing all the individual steps.
These responses worked flawlessly with my V1 unit but are now causing issues.I have tested by adding a 1 second 'Wait' command between cbus commands and this corrects the issue but it is not how I want, or expect, the system to behave.
Is this a known bug or is there are fix I need to implement?
thanks

tech07
Administrator
 

Joined: Thursday Jan 29th, 2009
Location: Singapore
Posts: 106
Status: 
Offline

  back to top

can you send the cclx file to support@cytech.biz after doing a Scan for modules and saving the file

tech07
Administrator
 

Joined: Thursday Jan 29th, 2009
Location: Singapore
Posts: 106
Status: 
Offline

  back to top

The UCM/Cbus2 does automatic concatenation of messages into a single command instead of sending the commands one by one, which causes the cbus devices to respond much faster

However the maximum length of the message is limited to 18 as explained in the UCM/Cbus2 manual section below

To prevent message overflow, insert a Wait 1 second every 5 cbus commands
In fact it is not  necessary to insert a wait command. Just inserting a dummy non-cbus action should do the job, eg Get Flag 1
In future, we may get Comfigurator to break up the command if it is too long, but I think his workaround should fix your problem for now


Concatenation of messages (in UCM/CBUS2 Manual)
Concatenation is the default behaviour in UCM/CBUS2.
A concatenated command consists of 2 or more commands  in the changed format
197, <ID>,  <$05>, <Application>, <00> <SAL command> [ <SAL Data>],... 255
197, <ID>, <$03>,< No of Bridges> <bridge1>, <bridge2>,.., <bridgeN>, <Application>,<SALData> [<SAL Data>]...., <255>
Limitation of message length to Cbus
The CBUS SIM command length is limited to 21 bytes  between \ and CR
For Action 197 concatenated messages, the length of message transmitted to Cbus should be limited, according to the formula,
(No of Bridges) + (2 * No of On/Off commands) + (3 * no of Ramp commands) < = 18 (as there are 3 overhead bytes in the message)
If the number of concatenated commands in a Response exceeds this number and the concatenated option is enabled then the command should be broken up into 2 or more messages so that the limit applies
Eg consider the response
Cbus Off 2 0
Cbus On 2 1
Cbus On 2 2
Cbus RampInst 2 3 0
Cbus RampInst 2 4 0
Cbus RampInst 2 5 0
Cbus RampInst 2 6 0
Cbus RampInst 2 7 0
Cbus RampInst 2 8 0
Cbus RampInst 2 9 0
Cbus RampInst 2 10 0
Cbus RampInst 2 11 0
Cbus RampInst 2 12 0
Cbus RampInst 2 13 0
There are 3 on/off command and 11 ramp commands and no bridges hence total of 6+33 = 39 bytes which exceeds the limit of 18 bytes
This should be broken up into 3 groups to be concatenated separately

Cbus Off 2 0
Cbus On 2 1
Cbus On 2 2
Cbus RampInst 2 3 0
Cbus RampInst 2 4 0
Cbus RampInst 2 5 0
Cbus RampInst 2 6 0
(2 * 3 + 3 * 4 = 18 bytes)
Wait for 1 sec
Cbus RampInst 2 7 0
Cbus RampInst 2 8 0
Cbus RampInst 2 9 0
Cbus RampInst 2 10 0
Cbus RampInst 2 11 0
Cbus RampInst 2 12 0
(3 * 6 = 18 bytes)

Cbus RampInst 2 13 0
(3 bytes)
This prevents the message frem being corrupted in the Cbus SIM Module

richylloyd
Member
 

Joined: Monday Aug 29th, 2011
Location: Woking, United Kingdom
Posts: 23
Status: 
Offline

  back to top

Many thanks
This does indeed solve my problem - used a 'get counter value' to split cbus commands instead of the 'wait' function.


UltraBB 1.172 Copyright © 2007-2014 Data 1 Systems