Posts: 1,255
Threads: 219
Joined: May 2007
Reputation:
0
Hi
The documentation states the DA command can snd a maximum of 24 byte action code strings.
Is there a way to send longer strings; ie multiple DA commands with terminator just on the last?
Regards
Julian
Posts: 3,493
Threads: 476
Joined: Aug 2006
Reputation:
0
Current Comfort firmware limits DA action codes to 24 codes due to memory limitations from Comfort I. However Comfort II is able to handle larger amount of codes in the DA command and in future this restriction will be raised
In the meantime, send separate DA commands
Posts: 1,255
Threads: 219
Joined: May 2007
Reputation:
0
It\'s the send seperate DA commands that is confusing me.
Maybe that\'s OK for some scenarios but as it stands if I read the action code string that is stored in a CCLX file, if it\'s greater than 24 bytes then I cant then execute it by converting to DA format (Hex) and sending.
Only way then is to use \"R!\", but then I\'m reliant on the CCLX being in sync with the config uploaded to Comfort.
Ingo has a complex Response that I\'m trying to support in the Comfort Client and it works fine if sent via \"R!\" (run response number) but I cant execute via \"DA\" because of this 24 byte limit unless you can advise a solution (ie the ability to send in parts)
Are you saying Comfort II raises this limit automatically and that it\'s just the manual is wrong (if so whats the Utra II limit) or does the UCM code need to be changed to \"up\" this limit?
Regards
Julian
Posts: 3,493
Threads: 476
Joined: Aug 2006
Reputation:
0
Comfort firmware has a limit on the number of bytes it accepts for the DA command
I just found that the maximum is 36 bytes in ULTRA 5.145 and above, not 24 so that may solve your problem
Posts: 629
Threads: 62
Joined: Jan 2007
Reputation:
2
As far as I know there is no limit on the size of a response. If a user created a complex response (like me) that is more than 36 bytes, how would you send it in seperate DA commands?
Just for interest, I am running the latest firmware and 36 bytes is not enough.
Ingo.
Posts: 3,493
Threads: 476
Joined: Aug 2006
Reputation:
0
You can just split up the actions into smaller chunks and send out several DA commands. R! will always work, it executes the Response no matter how many actiions are within
How many actions do you have in the response at the most? There has to be a a limit to the DA command so it may be better to use R! for complex responses as long as you make sure you know what Response number it is. Fix the Response in Comfigurator so the number does not change
Posts: 629
Threads: 62
Joined: Jan 2007
Reputation:
2
Ok, here we go. All this is doing is to set the Scullery light ON if the security mode is either in OFF or DAY modes. It also checks to see if the hours are between 17:00 in the afternoon and 06:59 in the morning.
If SecurityMode = SecurityOff Then
If Hours < 7 Then
If Counter Counter215 = 0 Then ! If Light is not already ON then
CBUS On 2 215 ! Set Scullery Light, CBus group 215, ON.
End If
Do SculleryOFF After 1800 Seconds Using Timer61 ! Switch Scullery Light OFF after 30 minutes (1800 seconds)
Else
If Hours >= 17 Then
If Counter Counter215 = 0 Then ! If Light is not already ON then
CBUS On 2 215 ! Set Scullery Light, CBus group 215, ON.
End If
Do SculleryOFF After 1800 Seconds Using Timer61 ! Switch Scullery Light OFF after 30 minutes (1800 seconds)
End If
End If
End If
If SecurityMode = DayMode Then
If Hours < 7 Then
If Counter Counter215 = 0 Then ! If Light is not already ON then
CBUS On 2 215 ! Set Scullery Light, CBus group 215, ON.
End If
Do SculleryOFF After 1800 Seconds Using Timer61 ! Switch Scullery Light OFF after 30 minutes (1800 seconds)
Else
If Hours >= 17 Then
If Counter Counter215 = 0 Then ! If Light is not already ON then
CBUS On 2 215 ! Set Scullery Light, CBus group 215, ON.
End If
Do SculleryOFF After 1800 Seconds Using Timer61 ! Switch Scullery Light OFF after 30 minutes (1800 seconds)
End If
End If
End If
Posts: 6,024
Threads: 880
Joined: Apr 2006
Reputation:
3
That is far too complex to issue using a DA command. You should use R! for this ie Do Response
I also noticed that in the Response below
------------------------------------------------------------
If Hours < 7 Then
If Counter Counter215 = 0 Then ! If Light is not already ON then
CBUS On 2 215 ! Set Scullery Light, CBus group 215, ON.
End If
Do SculleryOFF After 1800 Seconds Using Timer61 ! Switch Scullery Light OFF after 30 minutes (1800 seconds)
Else
....
--------------------------------------------------------
The action Do Scullery Off after 1800 seconds is outside the If Counter 215 loop so it occurs regardless of whether the Scullery light is on. It probably does not make much difference except that if someone switches on the liaght manually after that the light will still switch off when the timer expires
Posts: 629
Threads: 62
Joined: Jan 2007
Reputation:
2
That is designed like that, if someone switches the light on manually it will stay ON only for 30 minutes after the last movement is detected. If you are in/out of the scullery the timer is retriggered and the light stays on. This is just to prevent someone from switching the light on, use the scullery for a minute and forget to turn the light off. If I remember correctly, the SculleryOFF response also checks to see if the light is either ON or OFF before issueing a CBus command.
Posts: 1,255
Threads: 219
Joined: May 2007
Reputation:
0
Chiu
This has all come about because of my Client App and the whether to use R! or DA.
R! has got to be more performant but trouble is knowing if the response number uploaded to Comfort is the same as the version in the CCLX. Fixing the response numbers will help but still doesnt guard against someone changing the response in the CCLX file and forgetting to upload the changes to comfort.
By using DA I was always assured of running the latest action code string (response) in the CCLX which I use (as do other apps including wizcomfort) to config the client capabilities.
Perhaps we could have some sort of checksum that is both stored in the CCLX as a keyword against the response and be able to query the checksum of a response in comfort too. If they are the same then we are pretty sure the definition in the CCLX is the same as comfort and it\'s SAFE to execute in the context we expect.
I know this would need changes to comfigurator and comfort firmware etc but the checksum method would hopefully be quite compact and not need much storage space in comfort. The creation of the checksum would be done by Comfigurator so not much logic needed in UCM etc somewhere to store it etc.
Feasible?
Julian
