TZ45 ignoring setpoints from ELK

[vc1234]

Hi,
 
I am aware that other folks have similar issues with RCS TZ45 occasionally  ignoring ZWave setpoint commands.  Unfortunately, it is unclear where the breakdown in communication takes place: M1XSLZW, Leviton vrc0p+3, the thermostat itself, or somewhere else.
 
I am also aware of a solution via a rule/output retries, but it looks like a horrible hack. That retry should happen at the protocol level, not in the user code. Anecdotal evidence suggests that micasaverde's Vera does not have that lost setpoint command issue, so it appears that the problem lies not with tz45 but elsewhere.
 
So, any thoughts on the issue, or it is what it is and just live with it ?  I am wondering if other thermos have the same issue with Elk, e.g. the Honeywell YTH8320ZW1007 ?
 
Thanks.

 

[tmbrown97]

for starters, make sure the thermostat isn't running programming of its own - they will override whatever was set last on the Elk.
 
I have a wires RS232 RCS system and even mine misses the occasional command unfortunately...

 

[vc1234]

for starters, make sure the thermostat isn't running programming of its own - they will override whatever was set last on the Elk.

Yes, I made sure that my tz45 is not running any built-in programs. I am almost tempted to buy another zwave controller, like Vera,  to find out where the communication break down occurs.  But even, if I do, then what?  Probably,  neither Elk, nor RCS are likely to be of much help.
 
Your situation is even stranger -- zwave is out of the picture and yet you still experience a similar problem. Unfortunately, error logging is non-existent at either end of the communication channel  to figure out who might be the culprit.

 

[vc1234]

I did some further digging, and still cannot figure out what the culprit is:
 
The rules (the comfort temp 68F, the away temp should be 55F):
---
WHENEVER  Area 1 (Area 1) IS ARMED AWAY
            THEN ACTIVATE Economy Mode (Task 2)
WHENEVER  Economy Mode (Task 2)  IS ACTIVATED
            THEN SET Main (Tstat 1) HEATING DESIRED TEMP TO Econ Temp H (Cust Set 1)
            THEN TURN Output 101 ON FOR 2 MINS
WHENEVER  Output 101 STATE IS TURNED OFF
      AND Main (Tstat 1) HEATING DESIRED TEMP IS ANY VALUE OTHER THAN Econ Temp H (Cust Set 1)
            THEN ACTIVATE Economy Mode (Task 2)
---
 
Elk events collected via a Perl script (armed away 9:55:42):
---
2013-11-11 09:55:41 ThermostatDataReply: thermostat=1, mode=auto (3), fanmode=auto (0), hold=on, currentTemperature=68, coolingSetPoint=80, heatingSetPoint=68
 
..... Arming away:
2013-11-11 09:55:42 OutputChangeUpdate: output=101, state=on
2013-11-11 09:55:42 TaskChangeUpdate: task=2
2013-11-11 09:55:42 ArmingStatusReport:
     Area 1 : armed away with exit timer no alarm active

.... In two minutes:
2013-11-11 09:57:41 OutputChangeUpdate: output=101, state=off
The task was not re-executed and I checked from perl whether the new setpoint was indeed 55F-- and indeed it was:
2013-11-11 09:57:41 *** New heating set point: 55
 
... After some time, the thermo reverted back to 68F
2013-11-11 10:07:14 ThermostatDataReply: thermostat=1, mode=auto (3), fanmode=auto (0), hold=on, currentTemperature=67, coolingSetPoint=80, heatingSetPoint=68
---
 
Not sure whether the thermo itself insisted on the previous setpoint, or Elk did not send any zwave command and used a cached setpoint value rather than querying the thermo both in the rule and in my Perl setpoint query. Interestingly, in my case, inability to  change the setpoint happens, so far, when it goes from high to low but not from low to high.

 

[Madcodger]

FWIW, when I used a serial RCS in previous house I also had many missed commands from Elk. As I recall I resolved it by having all programs (Rules) send commands twice, with a short wait in between (2-5 seconds, but don't specifically recall). Cut errors to essentially nothing. No idea why, but it's a simple fix you might want to try.

 

[vc1234]

FWIW, when I used a serial RCS in previous house I also had many missed commands from Elk. As I recall I resolved it by having all programs (Rules) send commands twice, with a short wait in between (2-5 seconds, but don't specifically recall). Cut errors to essentially nothing. No idea why, but it's a simple fix you might want to try.

Thanks. Do you happen to know whether the RCS was ignoring the comands or Elk was not sending ?

 

[tmbrown97]

I'm not sure exactly where the breakdown was in my situation, but what I was doing was having the M1 watch for when I turn the Fan on manually so that it could set a timer to turn it back off... more often than I liked I'd find the fan running continuously and the M1 thinking it wasn't - unfortunately I don't know if the M1 never saw the fan status change, or if it did and subsequently sent the Off command and assumed it went through - but the tstat never got it.

 

[Madcodger]

I don't know for certain but suspected the stat, or something in the communication between the two. Either way, that pretty much resolved it all. Sold that house over 3 years ago and still talk to new owner whom I introduced to home automation. Not an enthusiast like us and I pulled the "high maintenance" stuff before selling but left the Elk, an ISY and that stat. All seems fine.

 

[vc1234]

I don't know for certain but suspected the stat, or something in the communication between the two. Either way, that pretty much resolved it all. Sold that house over 3 years ago and still talk to new owner whom I introduced to home automation. Not an enthusiast like us and I pulled the "high maintenance" stuff before selling but left the Elk, an ISY and that stat. All seems fine.

Thanks !
 
Just out of curiosity, what thermostat if any you are using with your current system and if it's an elk installation do you still need to use a double setpoint trick ?

 

[Madcodger]

Well, despite having both an Elk and ISY I've gone "heretic" and installed a Nest (Gen 2). Have been very happy with it for about a year or more. Paid for itself by very efficiently controlling my heat pump (very smart about when to use backup heat, or better yet avoiding it more often). Easily accessible remotely, and very reliable.

Many get hung up on the fact that remote (or even in-house) communication via browser must go through Nest's servers. I think I've been unable to access it maybe twice, for a few minutes. Otherwise rock solid and more reliable than the serial stat by a longshot. They do not charge for access. It doesn't talk to the Elk or ISY but they also recently opened up the API so we'll see what happens from developers. If past history is an indication some will now comment on how terrible their comm policies are, but it has been a great device for me.

I will note, however, that when I turn on the fan only it runs much slower than when blowing heat. Must look into why, as I just recently tried it, for just a few hours, with no attempts yet at figuring out why. And I thought it was a single stage blower...

 

[wuench]

I have the same issue with my serial RCS stat Madcodger mentioned and also implemented the retry to fix it, which worked.   I remember seeing others mention other tstat brands and Elk misses here.  IMHO, It really doesn't matter which side is dropping, the problem is that the implementation by Elk is unreliable.  In the real world signals get dropped.  The Elk should either make sure there is a confirmation (if one is sent) or query to verify the change occurred.  And have a way to notify if it doesn't.   Unreliability in lights would be one thing, but unreliability in HVAC is unacceptable as real damage can result from frozen pipes, etc.
 
Luckily the Elk has a powerful enough rule engine to do this yourself.  You can either do blind retries, or send a query to verify and continue to update until it takes and if it doesn't notify that it failed, etc.

 

[vc1234]

 Unreliability in lights would be one thing, but unreliability in HVAC is unacceptable as real damage can result from frozen pipes, etc.

I could not agree more...
 

Luckily the Elk has a powerful enough rule engine to do this yourself.  You can either do blind retries, or send a query to verify and continue to update until it takes and if it doesn't notify that it failed, etc.

Unfortunately, the query to verify did not work for me. As can be seen from the trace I provided earlier, the query confirmed the new setpoint, two minutes after the initial command was issued, and yet at some point afterwards the thermostat started using the previous setpoint.  Now, for three days in a row, I could not reproduce: in fact, now when I arm the system away, I stand beside the thermostat and make sure visually that a new setpoint was set/not set.  then I quickly exit the house, in time not to trigger the alarm

 

[vc1234]

I have the same issue with my serial RCS stat Madcodger mentioned and also implemented the retry to fix i

Today, I managed to catch the new setpoint loss situation -- interestingly, Elk 'thought'(according to eKeypad and my perl script)  that the new setpoint was in effect while the thermostat displayed the old setpoint.  That probably means that querying for the current setpoint returns a cached value rather than the actual one.
 
I'll try blind retries without a delay first and see if it works.