Odd issue with potential of dire consequences.

[Krumpy]

I have noticed that recently for whatever reason my HVAC system either goes into a fault state or definitely loses power. In this condition, all of my t-stats (RCS TR-40's) that are connected to the ELK via RS485 lose power and I have no heat.

I have confirmed that the ELK returns a 00 for current temp but it appears that your plug in discounts that as a valid value and does not set that value to the HS devices.

I would greatly appreciate if you would review the temp parsing routine and update the plugin such that it does report a 00 as a temp such to allow us to create a trigger in HS to send an alert as no heat in -30 degree outside temps could cause major issues for me. Of course I will add additional fail safe hardware/software to address this, but in general it would be nice if the plugin passed the value through.

This is what the ELK sent in raw data:
13TR01110006877000007
13TR0211000707700000D
13TR03110006579000006

This is what the plugin reported in debug mode:
12/5/2015 9:27:48 AM UltraM1G Debug Entered ProcessReceived() function with a string '13TR01110006877000007'
12/5/2015 9:27:48 AM UltraM1G Debug Entered ProcessCommand() subroutine.
12/5/2015 9:27:48 AM UltraM1G Debug Processing response [TR]
12/5/2015 9:27:48 AM UltraM1G Debug Entered ProcessReceived() function with a string '13TR0211000707700000D'
12/5/2015 9:27:48 AM UltraM1G Debug Entered ProcessCommand() subroutine.
12/5/2015 9:27:48 AM UltraM1G Debug Processing response [TR]
12/5/2015 9:27:49 AM UltraM1G Debug Entered ProcessReceived() function with a string '13TR03110006579000006'
12/5/2015 9:27:49 AM UltraM1G Debug Entered ProcessCommand() subroutine.
12/5/2015 9:27:49 AM UltraM1G Debug Processing response [TR]

After I reset the power on the HVAC system, the ELK then returned the proper temp:
13TR011106668770000FB
13TR02110677077000000
13TR031106665790000FA

Plugin:
12/5/2015 9:30:48 AM UltraM1G Debug Entered ProcessReceived() function with a string '13TR011106668770000FB'
12/5/2015 9:30:48 AM UltraM1G Debug Entered ProcessCommand() subroutine.
12/5/2015 9:30:49 AM UltraM1G Debug Processing response [TR]
12/5/2015 9:30:49 AM UltraM1G Debug Entered ProcessReceived() function with a string '13TR02110677077000000'
12/5/2015 9:30:49 AM UltraM1G Debug Entered ProcessCommand() subroutine.
12/5/2015 9:30:49 AM UltraM1G Debug Processing response [TR]
12/5/2015 9:30:49 AM UltraM1G Debug Entered ProcessReceived() function with a string '13TR031106665790000FA'
12/5/2015 9:30:49 AM UltraM1G Debug Entered ProcessCommand() subroutine.

Thoughts?

[Krumpy]

I can reproduce the symptoms by powering off my HVAC system which then powers off the tstats as they are connected to the same low voltage circuit.

So this issue applies to anyone which encounters a power loss to their HVAC system when their t-stats are integrated into the ELK, and is using this plugin to get the info. It will not show the correct tstat info once power is lost even though the ELK reports 00 for temperature for each tstat.

[Krumpy]

The original problem was a bad electrical switch. Replaced it and electrical problem should be fixed. Believe it or not but the switch was actually cracked.

I still think that we would want the plugin to pass through the value that comes from the ELK instead of ignoring it as a bad value. 104 of you have read this thread and no one has replied.

Am I truly the only person that thinks that this is a worthwhile change? Consider this, if for some reason your breaker for the tstat or HVAC system tripped then you would have no knowledge that your HVAC system is out of service and would have no heat to protect the house from freezing temps even though the ELK is continously sending notices that it could not communicate to the tstats.

Of course this is not something that I want to fault the plugin, but a simple change in the parsing routine of the plugin could help save us from damage in this situation. All we need it to do is pass through the 00 degree value that the elk is sending such that we can write a trigger to do something to alert us.

Unfortunately, I tried writing a ELK RP rule for < 55 degrees (00 should be less than 55 degrees, right) and it did not trigger.

[Ultrajones]

I am very hesitant to update the plug-in to pass a 0 value to the HomeSeer device. This would cause issue with any HomeSeer event that triggers when the temperature is less than n.

When this issue occurred in your home, did the Elk M1 log anything to the logs?

Regards,
Ultrajones

[reidfo]

I'm talking out of turn here because I don't have either an Elk or these thermostats, but isn't 0 a valid temp?

[Ultrajones]

I'm talking out of turn here because I don't have either an Elk or these thermostats, but isn't 0 a valid temp?

No, the Elk documentation states that 00 is invalid.

[srodgers]

I have a RCS TR-16 connected via ELK M1g and Ultra's plugin. Back in the summer i had a problem where the 24vac fuse would blow killing power to the AC. It did this several time when it rained heavy. It did this while I was on vacation and the funny thing is the Elk continue to report the last temp it had before the thermostat lost power. It did not report a 0 or 00. but rather the last temp before it had lost power. When I would check the temp via HSTouch or eK M1 keypad app it always showed the house to be at the set point. When I got home I found out how hot the house actually was.

My solution was to wire up a few RIB to the 24vac power and control lines so I could monitor the 24vac power, call for compressor, fan heat etc. I use these in a few events to alert me if the AC is not heating or cooling correctly.

Not sure if this is related to your problem but it seems my Elk /TR-16 just reports the last temp even when the T-stat looses power.

Does you thermostat show up in HSTouch Designer? Mine does not. That has frustrated me since changing to HS3 from HS2 where it all worked great.

[Krumpy]

Ultrajones,

You have to be one of the most professional plugin developers on this site. Thank you for creating all of the professional software that you have written. For reference I have three RCS TR-40's connected to the ELK via RS485. HomeSeer allows me to get status of all three t-stat zones via Ultra's plugin with the exception of when the t-stats fail due to 24 volt HVAC power loss. I am using the last version of HS2 and am in process of migrating to HS3. To the best of my knowledge, the issue is represented in both HS2 or HS3 versions of this plugin.

In this case I beg to differ in your interpretation of the meaning of the value "00". You are correct that the ELK serial protocol states that "00" is an invalid value, but my interpretation here is that the panel is communicating a serious error in regards to the temperature. In my case, it is a result of a catastrophic failure of the HVAC system as all thermostats are no longer in communication with the panel. Where I differ as well in your interpretation is that HomeSeer and the UltraM1G plugin should communicate and allow us as home owners to do something constructive rather than ignore the invalid value. I mean, ultimately I am using your plugin and HomeSeer as the mechanism to communicate to the panel and do something constructive in terms of home automation. How can I automate my home if a significant value (loss of thermostat) is being ignored or thrown out. That to me is the whole point of having this software such that I can trap events or messages in a user friendly manner and then decide what to do. But this ultimately gets to a point beyond your software as well.

In terms of your question. The ELK sent notification of an invalid temperature out the serial port to the plugin, but did not log an event in its (ELK) log. Your plugin did not log anything as well. Logging a catastrophic system failure in my opinion is a start but not enough in terms of automation. There needs to be event trigger notification or something that allow us to constructively handle a serious failure notification. I have created a ELK rule to in attempts of triggering and sending notification if temp is less than 50 degrees but that didn't work either.

If passing the 00 as a temp is problematic for HomeSeer, how about creating a event trigger for "Invalid Temperature"? But yet, I do have a problem with the temperature showing a incorrect last value when in reality the temp could be significantly less. The hardware and software is of little value if it does not represent the correct value, or notify of a serious system failure. This is my perspective from both a systems management point of view as well as a user experience point of view. My wife is extremely annoyed that the temp showed as 70 degrees while the house was actually 60 degrees, and obviously cold.

I beg you to reconsider to either pass the value through or allow us to perform some event trigger functionality such that we can send communication. I will also contact ELK Support as well as I agree that their event trigger functionality should allow us to implement a trigger that would allow us to define sending a "Freeze" warning to the Alarm company.

Thank you for your consideration to improve this software where the ELK automation panel failed.

[Krumpy]

I'm talking out of turn here because I don't have either an Elk or these thermostats, but isn't 0 a valid temp?

Thank you for responding. Please see my post above.

[Krumpy]

I am working with ELK to address this issue. At present, the beta version of the XSP firmware that I have reports the temp as "01" instead of "00".

While this causes this plugin to report a 1 degree temp which then allows me to create a event trigger in Homeseer, it currently does not yet allow me to write a ELK rule to send notification. More to come.

Kudos to ELK Tech and Development team to step up and update their solution to address this.