Elk Rules for Thermostat.. Is there a more efficient way to program this?

[SIMKO]

After doing some searching on ways to make my thermostat rule more reliable, this is what I came up with. This is my first somewhat complicated rule so I am sure that there is a more efficient way to do the same thing.

Besides for the fact that it is a little clunky, it also only controls the heating. When summer comes around I will need to rewrite the rules to control the A/C.

Does anyone have any ideas to do this same thing but more efficiently and to also include control for the A/C. The only way I can think of to include A/C control is to check if the thermostat is set to heat or cool when the system is armed or disarmed. Based on if the thermostat is set to heat or cool, it would run different tasks. The amount of rules below would double.

Any help would be appreciated.

WHENEVER  Cabin Home (Area 1) ARM STATE BECOMES ARMED
		    THEN ACTIVATE Economy Mode (Task 2)

WHENEVER  Economy Mode (Task 2)  IS ACTIVATED
		    THEN SET Main (Tstat 1) HEATING DESIRED TEMP TO Away Temp H (Cust Set 3)
		    THEN TURN Output 100 ON FOR 2 MINS
		    THEN SET Addition (Tstat 2) HEATING DESIRED TEMP TO Away Temp H (Cust Set 3)
		    THEN TURN Output 101 ON FOR 2 MINS

WHENEVER  Output 100 STATE IS TURNED OFF
	  AND Main (Tstat 1) HEATING DESIRED TEMP IS ANY VALUE OTHER THAN Away Temp H (Cust Set 3)
		    THEN SET Main (Tstat 1) HEATING DESIRED TEMP TO Away Temp H (Cust Set 3)
		    THEN TURN Output 100 ON FOR 2 MINS

WHENEVER  Output 101 STATE IS TURNED OFF
	  AND Addition (Tstat 2) HEATING DESIRED TEMP IS ANY VALUE OTHER THAN Away Temp H (Cust Set 3)
		    THEN SET Addition (Tstat 2) HEATING DESIRED TEMP TO Away Temp H (Cust Set 3)
		    THEN TURN Output 101 ON FOR 2 MINS

WHENEVER  Cabin Home (Area 1) ARM STATE BECOMES DISARMED
		    THEN ACTIVATE Comfort Mode (Task 3)

WHENEVER  Comfort Mode (Task 3)  IS ACTIVATED
		    THEN SET Main (Tstat 1) HEATING DESIRED TEMP TO Home Temp H (Cust Set 4)
		    THEN TURN Output 102 ON FOR 2 MINS
		    THEN SET Addition (Tstat 2) HEATING DESIRED TEMP TO Home Temp H (Cust Set 4)
		    THEN TURN Output 103 ON FOR 2 MINS

WHENEVER  Output 102 STATE IS TURNED OFF
	  AND Main (Tstat 1) HEATING DESIRED TEMP IS ANY VALUE OTHER THAN Home Temp H (Cust Set 4)
		    THEN SET Main (Tstat 1) HEATING DESIRED TEMP TO Home Temp H (Cust Set 4)
		    THEN TURN Output 102 ON FOR 2 MINS

WHENEVER  Output 103 STATE IS TURNED OFF
	  AND Addition (Tstat 2) HEATING DESIRED TEMP IS ANY VALUE OTHER THAN Home Temp H (Cust Set 4)
		    THEN SET Addition (Tstat 2) HEATING DESIRED TEMP TO Home Temp H (Cust Set 4)
		    THEN TURN Output 103 ON FOR 2 MINS

 

[rsw686]

Are you checking the setting the temp every 2 minutes to prevent somebody from overriding from the thermostat? If so see if your thermostat supports disabling local control. This would cut out half of your program statements.

 

[SIMKO]

Actually the code sets the temperature then turns on an output for 2 mins. After 2 mins it checks the set temp and if it's not what it should be then it resets the temp and starts the output again.

If it checks the set temp after 2 mins and it is correct, then the whole loop comes to an end until the next time the alarm is armed/disarmed.

It's basically a check to make sure the command was sent properly to the thermostat.

 

[wuench]

It's good to have those double checks, I have had to add the same thing. If you are using an RCS thermostat sometimes the commands get missed... Since I put in double checks I don't have an issue.

 

[tmbrown97]

That's a really good idea - I need to implement that too... but do the double-checks go get the value from the thermostat or do they just rely on what's cached?

I have a rule that kicks on whenever I turn on the FAN to come behind me 20 minutes later and turn it off; however it misses about 10% of the time because it never "saw" the fan turn on; I was briefly considering finding a serial command that sends a status update and sending that every minute or so... And this is RCS.

For the OP - are you able to send commands to both thermostats that quickly in the first rule? I know with lighting I have to have a break in between successive sends; the panel isn't smart enough to space them out properly.

 

[SIMKO]

The 'double check' checks the value at the thermostat to see if it changed to what it was supposed to. If it didn't, it sends the command again and keeps checking every two minutes until the number is correct, then stops checking.

As far as putting a break between the temp change commands, that may actually be a better way to approach this. It won't be fail-safe like it is now, but I bet I can do it with a lot less code.

What is the best way to put a pause in the rule between each temp change command.

 

[SIMKO]

This is what the code looks like for just the arming state and for only one thermostat. Should be easier to follow.

I'm not taking credit for coming up with this, I found it in a search on the forums here.

I like the double check, but I don't like how much code it takes to implement in my case. Might play around with pauses and see how reliable it is.

The funny thing is that I have other rules without double checks that change temps at certain times and they work flawlessly. But when the changes are made when the system arms/disarms they are only about 60% successful. Maybe it is because the arm/disarm command is being sent across the data bus at the same time the thermostat commands are being sent.

WHENEVER  Cabin Home (Area 1) ARM STATE BECOMES ARMED
            THEN ACTIVATE Economy Mode (Task 2)

WHENEVER  Economy Mode (Task 2)  IS ACTIVATED
            THEN SET Main (Tstat 1) HEATING DESIRED TEMP TO Away Temp H (Cust Set 3)
            THEN TURN Output 100 ON FOR 2 MINS

WHENEVER  Output 100 STATE IS TURNED OFF
      AND Main (Tstat 1) HEATING DESIRED TEMP IS ANY VALUE OTHER THAN Away Temp H (Cust Set 3)
            THEN SET Main (Tstat 1) HEATING DESIRED TEMP TO Away Temp H (Cust Set 3)
            THEN TURN Output 100 ON FOR 2 MINS

 

[SIMKO]

I found the answer to my 'Pause' question. It appears to be very similar to the code for the double check. Rather than using almost the same amount of code to put in pauses, I'll just stick with the double check.

I was just worried that I was using too much code space, I just started playing with this system and I already have 7% of the space full with 5% being used solely for HVAC.

Thanks for the reponses.


http://cocoontech.com/forums/topic/6262-pause-in-an-elk-then-clause/page__hl__+rule%20+pause#entry53933

 

[tmbrown97]

Just FYI - I forget the exact details, but using multiple THEN's and multiple AND's use up extra rule spaces - so whether you have several short rules or just a couple long ones, the net result ends up being the same as far as space usage.

 

[crossbar]

Have these issues, with thermostats not updating, gotten fixed in newer Elk firmware?  Do Z-Wave thermostats have the same missed commands issues as the wired thermostats?
Seems like commands should never get "missed".   Having to check to make sure a command was implemented is a major hack (in keeping with Elk's MO I guess).
Do Z-wave thermostats update changes made at the thermostat back to the Elk like turning on the Fan.  Does the thermostat need to implement the Association Class to do this asynchronously or does the Elk need to poll (i.e. to get fan status)?
 
Also Is there any way to easily implement a programmable thermostat?  Just to implement a basic 5+2 Heating/Cooling requires at least 16rules (morning,day,evening,night).  And if you want to adjust based on occupancy or vacation.  Then you need to set up an output to check in every rule to see if we are in a different mode (and not keep overriding the vacation settings,etc).   And there is no way to adjust the time that a rule runs either.  You can run a rule based on a Custom Time setting but there is no way to adjust a Custom value in a Whenever rule.  There are convoluted ways to implement with counters and timers but there has got to be better ways to do all this?
 
Looks like controlling Thermostats is just beyond the capabilities of the Elk M1 and needs to be off loaded to another controller (or smart Thermostat).  Which is too bad as this is a primary function of an automated house.

 

[crossbar]

Well it looks like the Elk Thermostat updates issues with Z-wave are fraught with the same issues as the wired, with commands not always updating the thermostat.   I wonder if the Elk just doesn't send the commands sometimes.  Seems like if it happens with the wired thermostats than is must be an ELK issue not a communications issue.  This just quintuples the amount of rules you need to control a thermostat if you have to duplicate or check each command to the thermostat.   This is just not an automation solution.  This thermostat is a CT100.

 

[crossbar]

So now I go to implement checks like the OP and others are using to verity the thermostat gets set.  I figure the best way is to basically set up a "subroutine" that I can set 2 counter to the values of the high and low temp to set into the thermostat.  Then have this "subroutine" query the thermostat check the value and set it if it is not correct.  Well good old ELK killed that Idea.   You can check the set point of a thermostat in an AND rule and compare it to a counter however in the Then rule you can only assign a set point from a custom value not from a counter (what gives).  Then on top of that there is no way to change a custom value from a rule.
 
Ugg. Dead end after dead end.  Ok ok I know I just need to do this stuff in another controller but gosh things like controlling thermostats should be within the realm of the ELK.

 

[vc1234]

That's a really good idea - I need to implement that too... but do the double-checks go get the value from the thermostat or do they just rely on what's cached?
 

 
As I wrote quite a while ago re. an RCS zwave thermo, a single check is quite useless since the value is apparently taken from the cache.  I.e., my check was successfull, but the thermostat actual setting was unchanged.  I also have a message trace that indicates the same.
 
The check, however, may be turn out to be useful if it it is periodic, say, once every 5 min. See, my zwave thermo will eventually update its status and notify the elk controller that the setting is actually not the one the elk thought it was. Such an update happens upon temperature change when the thermo sends a mesage to elk. However, the already ugly double setting logic would become even uglier so I did not bother and just do a double setpoint trick.  Even with the trick, I had two cases in a year when the setting was missed.
 
I do not like the word, but it is pretty 'unacceptable' to have an unreliable thermostat control that can potentially cause a lot of damage due to pipe freezing for example. Likewise, it is pretty 'unacceptable' to have zero diagnostic support  to troubleshoot the issue, either on the elk side or for zwave protocol. I have no idea today where the thermostat communication breakdown occurs -- flying blind, as it were.

 

[vc1234]

but gosh things like controlling thermostats should be within the realm of the ELK.

Apparently not, at least based on my experience.
 
I'd be happy to get a reliable zwave controller in addition to elk just to control my three thermostats, but there is no such animal which is perhaps understandable taking into account the general awfulness of zwave compunded by its non-existent diagnostic tools.
 
Unfortunately, there is no reasonable alternative to wirelessly controlling thermostats and locks. The often mentioned zigbee has the same RF and mesh topology characteristics as its cousin so it, most likely, suffers from the same architectural issues as does zwave.  Plus, as far as I am aware, there is no zigbee-elk module. Also, not sure if zigbee disgnostic toolset situation is any better than that of zwave.

 

[ddennerline]

The hard-wired OmniPro thermostats do not suffer from the same “missed command” problem. If you are 100% sure that M1XSZW is not updating the thermostat, then you can contact Elk technical support. These types of problems can be diagnosed by using a RS-232 splitter – albeit you would have to purchase one.  I have been tempted to purchase an EZ-Tap so I can watch the VRC0P+3 traffic.