Comfort Automation/ Security System Forums > Third Party (interfacing to Comfort) > CBus > UCM/CBUS Problems > not all UCM CBUS2 commands received |
Moderated by: hendy |
Author | Post | |||||||||
---|---|---|---|---|---|---|---|---|---|---|
richylloyd Member
|
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
|
can you send the cclx file to support@cytech.biz after doing a Scan for modules and saving the file |
|||||||||
tech07 Administrator
|
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
|
Many thanks This does indeed solve my problem - used a 'get counter value' to split cbus commands instead of the 'wait' function. |