Shadow / Link groups across applications?

Due to some hardware limitations with devices I have that *only* support the lighting application, I have a need to use logic to "link" a pair of group addresses between two different applications (lighting & HVAC)

The action I need to achieve is trivially simple: - whatever state the lighting group is, the HVAC group must follow it precisely, reliably, and rapidly.

So in logic I need to continually monitor the state of the lighting group and apply the same state to a group in the HVAC application. I need to have response times for the two groups synchronising state in the order of a few seconds (ideally sub-second, but 1-2 seconds would be OK).

At the moment, I believe the requirement only calls for 1-way sync, - i.e. the lighting group will be the "master" in the relationship. External CBUS units on the lighting application will switch the lighting group on/off, and the HVAC group will be required to follow. I don't envisage ever initiating a change to the HVAC group directly by any other means (currently! - although this could change later)...

It shames me to admit that despite previously having a PAC, and now a Wiser, I'm woefully unfamiliar with CBUS logic programming.... I'm now desperately reading as much documentation as I can, but I'd really appreciate a quick-starter if anyone could help with what I imagine will no more than just a couple of lines of code...

TIA

Paul G.

 

I think this would look something like:
newvalue := GetLightingLevel("My Light");
once ( newvalue <> oldvalue) then
begin
SetRealIBSystemIO("HVAC Set-Level", 0, HVACZone1, newvalue);
oldvalue := newvalue;
end;

I'm assuming above that what you really wanted to do was do HVAC related function. If you're not, then you may want to replace the SetRealIBSystemIO with a SetLightingLevel. Can't remember off the top of my head if that permits you to call SetLightingLevel on an HVAC application.

 

1st stab at this...

How's this look as a first stab at coding the described action? - I created a new module which I called "group-sync". I believe this should run continuously and thus constantly sync the state of "Communication Group 1" in the Air conditioning application with the state of group "Thermostat" in the lighting application

Code:

if GetLightingState("Thermostat") = OFF then
       SetCBusState("test", "Air Conditioning", "Communication Group 1", OFF);

if GetLightingState("Thermostat") = ON then
       SetCBusState("test", "Air Conditioning", "Communication Group 1", ON);

No doubt there may be a more efficient way to code this? - anyone care to comment on whether this sample will/won't work as I think it should? - it does compile OK, so the syntax would seem to be correct, but will it actually do what I want i.e. in terms of running continuously and acting to sync the two groups very rapidly?

TIA

Paul G.

 

In practical terms, what I *need* to accomplish, is to remotely turn on/off a CBUS thermostat - which can only be accomplished on the "air conditioning" application - from an older-firmware Neo switch which does not support a secondary application and must stay in the lighting application... Why not just upgrade to a newer Neo you say? - well I might very well do that, but I also need to control the thermostat from my Comfort alarm panel via its CBUS UCM interface, and this definitely only supports the lighting application, and there's not a thing I can do about that as far as I know... - and the Comfort control interface is the more important of the two, since that is where I intend to manage my central heating on/off scheduling times...

Oh, and it's worth mentioning, I don't need to worry about group LEVEL, - only the on/off state...

Cheers.

Paul G.

 

Oops, - Sorry...

I think I may have mis-placed this post in the wrong forum?... - appologies if that is so.... perhaps one of the mods would be kind enough to rule on suitability, and perhaps move the thread to the PICED forum if necessary...

 

Not quite right...

Although it compiles OK, when I try to run that code, it throws the error:

"Error - 14104" - then "Logic run-time error R009 - C-Bus Messages are being sent on every loop"

Which is fairly self-explanatory I suppose, - and was actually what I intended in order to get the best possible synchronisation speed between the two groups... - but I guess CBUS barfs at this much traffic, so clearly I need to reduce it a bit...

IIRC each loop is about 200ms isn't it? - so 5 loops/second... - so if I were to restrict it to sending the messages out only on every 5th loop it would still provide 1-second response times to a change...

Would 1 message every 5 loops be gentle enough not to cause CBUS to throw this error? - [Edit: - yes, no error occurs with 1 message every 5 loops.] that being so, what would people suggest as the best way to code it for 1 message every second? - count 5 loops? - monitor the RTC to see the second change? -use a timer? - what would be most efficient?

Note that I have considered the possibility of only sending out a message when the lighting group *changes* - but I rejected that since it would allow them to get out of sync if someone inadvertently switched the air conditioning group directly... - which I don't want to allow to happen... although I suppose another approach might be to have code monitoring both groups for changes, and then re-synchronising them according to the status of the lighting group which I've deemed is "the master"... Hmmm..... food for thought.... - Perhaps even better would be to *allow* either group to change, and then to synchronise the *other* group to match, - then I don't have to send any commands out to CBUS unless & until either group changes state, I don't have to worry about keeping a master/slave relationship, and thus can allow "users" to work with either group (which permits using the thermostat's on-board on/off switch). All in all seems like a better approach methinks...


TIA

Paul G.

 

Would this be better?

In the Initialization section I perform an initial sync FROM the HVAC group TO the Lighting group - i.e. I treat the actual state of the CBUS thermostat as authoritive, and change the lighting group to match...

Then In a module called group-sync I have:

Code:

{ Block 1 - Monitor changes to the Thermostat group directly, and synchronise them over to the lighting group... }
if HasChanged (GetCBusState("test", "Air Conditioning", "Communication Group 1")) then
begin
  SetLightingState("Thermostat", GetCBusState("test", "Air Conditioning", "Communication Group 1"));
end;

{ Block 2 - Monitor changes to the lighting group , and synchronise them over to the thermostat... }
if HasChanged (GetLightingState("Thermostat")) then
begin
  SetCBusState("test", "Air Conditioning", "Communication Group 1", GetLightingState("Thermostat"));
end;

Was wondering whether there'd be any difference in behaviour if I used ONCE rather than IF, but I see the CIS logic guide recommends using IF in preference to ONCE....

I *Think* this code should allow the status of either group to change, and the corresponding group in the other application should always then update to match....

I think I see a slight oddity here in that it looks to me like a part of the code might actually re-trigger itself... - e.g. If the HVAC group changes state, the 1st code block triggers to change the lighting group to match... which then presumably would trigger the 2nd code block which I guess might re-apply the same config back to the HVAC group? - but since the state wouldn't actually *change* again (since they'd both be the same now), - I assume this wouldn't result in an endless loop type scenario where each group change initiated by the code just retriggered the module to run again?.... - might this be a reason to use ONCE instead of IF???

TIA

Paul G.

 

Seems to work acceptably well...

In test mode at least, with a couple of CBUS buttons and a couple of level indicators on the project workspace to allow me to "switch" either group and see the level of both groups, it certainly seems like each group follows the other with about a half-second ish delay and no matter what combination of presses & states I tried, I couldn't make them go out of sync...

Lets hope it works as well for real when I upload it to the Wiser unit...

It's amazing how just writing out the thought processes here in the forum forces one towards the answer...

Paul G.

 

One thing that might catch you is that it will take a couple of minutes after uploading a project to the Wiser before the Logic kicks off so you'll need to be patient with it.

 

Aye, there's the rub

Nothing is ever straightforward in the CBUS world is it...

Despite the fact that this small piece of code does *Exactly* what I need, despite the fact that the logic engine lets me write it, compile it, and run it, PICED *Won't* allow me to upload it to Wiser...

As soon as I try to transfer the project I get the error in the attached screenie (see "Project Status" section in red)...

If I click on the show errors button, I get the following:

Code:

Project Error Report : pgordon1.ctd
Critical Errors
Critical Errors must be corrected before use.

Critical Error 309 : Project uses invalid Application numbers (172).

--------------------------------------------------------------------------

Error Details
Refer to the Help file for more details.

Critical Error 309
CAUSE : An invalid C-Bus Application has been used for lighting control. Valid Applications are 1 - 127, 136, 202 and 203 (01 - 7F, 88, CA, CB hexadecimal).
SOLUTION : Remove the use of this Application. Refer to the Project Summary for details of where the Applications are used. When complete, save the Project, close then re-start the PICED software and re-open the Project.

So it's basically saying that I cannot use application 172 - "Air Conditioning" - which is precisely the whole point of the excercise!!!

So now I have to ask; - how the **** am I supposed to remotely control this thermostat from Comfort??!?!? - the Minder Pro unit is effectively the same hardware as comfort rebadged isn't it? - how does this integration between Minder Pro & other CBUS applications occur? - this *MUST* be possible surely???

Can I remove that (to my mind) utterly pointless restriction on using application 172 and get PICED to let me transfer the project regardless?

This is getting so depressingly familiar....

Hope someone can suggest a solution, or this thermostat unit will be an UTTER FAIL and will have to go back....

Here's hoping....

Paul G.

 

The SetCBusState command can only be used when setting values on lighting-compatible Applications. The HVAC Application is a very different beast and as such you need to tell the Wiser that you want to generate a specific HVAC message. Because the messages and rules around the HVAC Application are very different to basic lighting functions, a specific logic engine message must be used. The appropriate logic engine command to disable your HVAC zone would probably be:

Code:

SetBoolIBSystemIO("HVAC Zone Enabled", x, y, false);

where
x = zone group
y = zone number (I think this is 1 in your case, based on previous posts)
false or true depending upon whether you want the zone enabled or disabled

You should be able to just replace your logic statements that are trying to enable/disable the thermostat zone with the statement above. Let us know how this goes.

 

Many thanks!

I'll give that a go... - looks like I have plenty to play with over the Christmas break... - in addition to whatever new toys Santa brings me...

I also now have another potential means of skinning this cat... - it looks like I *may* actually be able to send commands from Comfort on the other application after all... - further research required, and it may need me to upgrade my CBUS UCM to the latest hardware - in order to support the latest firmware - in order to fix the time-sync issues - in order that I can re-enable the use of other applications on the UCM... (phew)...

Out of interest, given what you described above, I'm curious how it's seemingly so simple to do this from a key-input unit (switch groups on/off on application 172 that is)... - literally just set "Air conditioning" as the secondary application, then assign group address 001 to a key, and Bob's yer aunty's live-in lover... - from a key on a Saturn, I can turn the t-stat on/off... - and yet to do it from Wiser is such a more complicated feat?...

I'm also curious how/why the logic appears to "work" when I test it in PICED... - I can *see* the group in the air conditioning application change state... - does that not imply that the logic engine in PICED doesn't follow the same rules/formatting as the one in Wiser?

I ask these questions purely in the persuit of knowledge!

Cheers.

Paul G.

 

Hmmm...

I haven't had a chance to try the suggested code yet, but I knew I'd seen some other posts that kind of suggest the opposite of what you're saying here... - at least from a novice end-users perception.. consider this point from another thread:

Which really does make it sound as if the operation is a fairly straightforward one of sending a "lighting-style" (direct quote!) message just using the appropriate application and group addresses... - and indeed this exactly how it does appear to function when using a key-input unit with a secondary application... I have saturns that send on/off commands to "Communication Group 01" - which is group address 001 in application 172... So I suggest that it's therefore not such a numpty assumption on my part to assume that the mechanism to do it from a Wiser ought to be consistent with that?...

I'm *hoping* that with the requisite firmware update applied to my Comfort-CBUS UCM interface, I will be able to transmit the apprioriate command out directly in the same way... - In comfort comfigurator code this would equate to:

Code:

Cbus On 2 1 0 172

Where it's hopefully fairly obvious the command is ON, the "2" is the UCM ID, the "1" is the group address, and the "172" is the application address...

which further reduced to comfort action codes would be:

Code:

197,18,1,121,0,172,255, 255

*IF* this works as required, then I don't actually have any need to implement the group-mirroring methodology that kicked this topic off...

Paul G.

 

Just looking at implementing this in the project... can I seek clarification...

What *exactly* is the value to be specified for "x=zone group" derived from? - i.e. what is its relationship to the settings in toolkit that I've configured for the t-stat? - to put it plainly, how do I know what value I should use? and where in toolkit do I look to find out? the only values I've needed to be concerned with up to this point are the application number (i.e. 172 or AC hex) and the group address of the communication group - which is as you correctly indicated 1 in my case....


Cheers..

Paul G.

 

The HVAC command to switch a Zone Group on and off uses the same command format as a lighting on/off command. This was done so that regular key switches could be used to control the HVAC power by simply putting them onto the HVAC Application. This is a bit of a hack, but it is a pragmatic solution to the problem.

The logic engine, however, understands the HVAC Application and supports it fully. There is no need to use hacks to control HVAC from logic. In fact, it won't allow you to pretend that the HVAC Application is just a lighting Application and do these hacks. For this reason, you do need to use the In-built System IO variables for controlling HVAC from logic, as Newman suggested (although he gave an example for switching a zone, not the zone group).

The Zone Group number used in the code:

Code:

SetBoolIBSystemIO("HVAC Zone Group State", ZoneGroupNumber, State);

is the number given to the Zone Group in ToolKit.

 

Thanks Darren. I had mistakenly suggested controlling the Zone, not the Zone Group, as you say. I guess that's what you get for looking at this sort of thing late at night.

The 'State' parameter for the Zone Group command is either 'true' or 'false'.

 

OK, I think I've got it...

Thanks for the explanation, - it does make it clear to me why the difference is there... - it's a shame though that the logic engine won't support *both* methods of control... it might be a "hack" but it's simple, it works, it's the method that I believe most users would assume to be correct, and it's consistent with how control is excercised from every and any other (non-logic) CBUS unit.... - why not allow both and let the comissioning engineer / end user decide for themselves?

Anyway, that's an option for the future perhaps? - for right now I have to work within the confines of what the system allows me to do today... If I understand you, the "zone group" is the "Communication Group" in Toolkit yes? - since I have nothing else in toolkit apart from the communication group and the plant relay group, and I *know* about the warnings about not touching the plant group!

So looking at the attached screengrab of Toolkit, my logic statement should be:

Code:

SetBoolIBSystemIO("HVAC Zone Group State", 001, GetLightingState("Thermostat"));

(does it matter if I use "001" or "01"?). The result of the GetLightingState function is a boolean value so that should be OK...

Thanks for the help with all this so far, - FYI I've just typed up a summary of all my experiences getting this working and condensed all the lessons I've learned from this process into a basic commissioning guide for a system like mine - simple UK based gas fired central heating system with a single boiler to control the heating only... I'll upload it to the forum later today in case it might be of use / help to others in the same position...

 

Update...

I've just changed the code in my logic module to:

Code:

{ Monitor changes to the Thermostat zone group, and synchronise them over to the lighting group... }
if HasChanged (GetBoolIBSystemIO("HVAC Zone Group State", 01)) then
begin
  SetLightingState("Thermostat", (GetBoolIBSystemIO("HVAC Zone Group State", 01)));
end;

{ Monitor changes to the lighting group , and synchronise them over to the thermostat zone group... }
if HasChanged (GetLightingState("Thermostat")) then
begin
       SetBoolIBSystemIO("HVAC Zone Group State", 01, GetLightingState("Thermostat"));
end;

Which compiles OK, but when I test it in the PICED workspace (screengrabs below) it doesn't *appear* to work as before when I was (incorrectly) using the SetCBUSState command to switch the zone group... - I'm not able to test it on my live network yet, so perhaps it's just a "foible" of trying to test this offline?
What happens is that if I switch either group in PICED, then IT changes (I see level change between 0% - 100%) but the other group does not follow it - I see its level stay the same on the workpsace, thus the two groups appear to be out of sync....
The components I have used are:
2 level indicators, monitoring the levels of the two groups in question (Lighting application, thermostat group) and (Air Conditioning application, communication Group 1)
2 buttons set to on/off function of the same two groups, so the "CG01" button is doing a 'lighting style' on/off of Communication Group 1
The button labelled "Thermostat" is merely switching the lighting group and I presume that is trigerring the "HasChanged" logic monitoring that group (it used to), and is thus issuing the SetBoolIBSystemIO command, - but this doesn't get reflected in the level indicator displaying that level NOR on the state indicator on the CG01 button itself...

I'm thinking that this must be related to the ability of PICED to simulate the presence of the thermostat?... - If I go into Project > C-Bus applications > HVAC Manager there are no zone groups present... if I add one, and try to give it the exact same properties as I have configured in Toolkit, most of the properties shown aren't editable - which looks like a Wiser limitation due to its incomplete support for the HVAC application?...

TBH, I'm pretty far out of my depth at this point... can anyone suggest what I need to do to configure this up so I can test properly in PICED whilst offline from my CBUS network....

Oh, and one other thing, even after making these changes, saving, exiting, re-opening, etc. for the life of me I still cannot get PICED to stop throwing that error 309 - invalid application used for lighting control (172)... - I have removed EVERY single line of code and EVERY other module apart from the above.... I cannot fathom why & where it thinks I'm doing that... - I am never using a lighting command (at least not in my logic code) to operate with anything in the HVAC app... got any thoughts? - is the "HasChanged" function permitted in that manner? - is that what's causing that error? - if so, how best to monitor that systemIO value for state changes? - or is it just because I've got those level & button components placed on the workspace?

Cheers.

Paul G.

 

My guide document

As promised, here's a quick guide I knocked up as I've worked through the process of setting up my central heating boiler to be controlled by a CBUS Thermostat unit. It's quite a steep learning curve figuring out the programming of these thermostats, so I offer this in the hope that it might be of some small assistance to anyone subsequently finding themselves in the same situation, and, like me, initially overwhelmed by the many options & permutations available...

I started out on this task knowing *absolutely nothing* about the Thermostat units, or the HVAC application that it uses, so this really is a very basic guide that covers what I hope should be everything anyone would need to know and do to get it up & running in an environment similar to mine.

If anyone more expert in these matters notices anything I've got wrong, then please let me know & I'll make the appropriate corrections.

Cheers.

Paul G.

 

In the best spirit of working things out for oneself, the answer to this question appears to have been the presence of one or more of those components on the PICED workspace... - having deleted the CG01 button and the level monitor showing the level of the HVAC zone group, I no longer get an error 309... - hurrah!

Paul G