Elk not always controlling TR16 thermostat

[Madcodger]

All,

About three weeks ago, I switched from an RCSTX16B X10 thermostat, controlled by HomeSeer, to a RCS TR16 (RS485) thermostat controlled by my Elk M1G. The X10 stat was basically fine - maybe two problems in two years, but I wanted to move HVAC over to the most reliable thing in my system, my Elk. So... you can understand my concern when I find that the Elk doesn't appear to be fully reliable at sending commands to the new stat via Rules. In fact, it looks like it's missed about 6 or more cycles in the past three weeks, including a cold house this morning.

I would have thought it was the stat itself, BUT when I change things via the M1 plugin and HomeSeer, the commands go through fine (I'm not using HomeSeer to control the stat regularly, but can change the temp when I like via the UltraM1G plugin). And, my system of using Elk Rules has worked well MOST of the time, but not EVERY time. The biggest concern, though, is that when I check the Elk log after one of these incidents, there's just nothing there in terms of the stat. No communication with the stat appears to have been attempted, which is troubling as it implies a problem with the Elk or its handling of Rules rather than line interference, etc.

Have I stumbled upon some known flaw? Is there some test for diagnosis? I switched to this setup to obtain the most reliable system I could find that was still part of my automation system, and yet it's proving to be much less reliable than my old X10 stat system controlled by HomeSeer.

Anyone have any ideas on this one?

Thanks,

Joe

 

[sharby]

All,

About three weeks ago, I switched from an RCSTX16B X10 thermostat, controlled by HomeSeer, to a RCS TR16 (RS485) thermostat controlled by my Elk M1G. The X10 stat was basically fine - maybe two problems in two years, but I wanted to move HVAC over to the most reliable thing in my system, my Elk. So... you can understand my concern when I find that the Elk doesn't appear to be fully reliable at sending commands to the new stat via Rules. In fact, it looks like it's missed about 6 or more cycles in the past three weeks, including a cold house this morning.

I would have thought it was the stat itself, BUT when I change things via the M1 plugin and HomeSeer, the commands go through fine (I'm not using HomeSeer to control the stat regularly, but can change the temp when I like via the UltraM1G plugin). And, my system of using Elk Rules has worked well MOST of the time, but not EVERY time. The biggest concern, though, is that when I check the Elk log after one of these incidents, there's just nothing there in terms of the stat. No communication with the stat appears to have been attempted, which is troubling as it implies a problem with the Elk or its handling of Rules rather than line interference, etc.

Have I stumbled upon some known flaw? Is there some test for diagnosis? I switched to this setup to obtain the most reliable system I could find that was still part of my automation system, and yet it's proving to be much less reliable than my old X10 stat system controlled by HomeSeer.

Anyone have any ideas on this one?

Thanks

Joe

Joe,

I'm using my Aprilaire 8870s with ELK and have certain firing problems as well. In my case, ELK upgrades, reboots, or changes result in a temperature discrepancy between my stats and ELK. What I did to further pinpoint my issue(s) was to interface ELK M1G with Powerhome that logs temperature and better details then the Elk logs. As a matter of fact, I have NO debug logging options with ELK "out of the box" except to telnet to the M1EXP (Ethernet module) and translate the commands that ELK is shooting over the main bus. I hope this hopes you isolate the root cause.


-=*Sharby*=-

 

[Madcodger]

All,

About three weeks ago, I switched from an RCSTX16B X10 thermostat, controlled by HomeSeer, to a RCS TR16 (RS485) thermostat controlled by my Elk M1G. The X10 stat was basically fine - maybe two problems in two years, but I wanted to move HVAC over to the most reliable thing in my system, my Elk. So... you can understand my concern when I find that the Elk doesn't appear to be fully reliable at sending commands to the new stat via Rules. In fact, it looks like it's missed about 6 or more cycles in the past three weeks, including a cold house this morning.

I would have thought it was the stat itself, BUT when I change things via the M1 plugin and HomeSeer, the commands go through fine (I'm not using HomeSeer to control the stat regularly, but can change the temp when I like via the UltraM1G plugin). And, my system of using Elk Rules has worked well MOST of the time, but not EVERY time. The biggest concern, though, is that when I check the Elk log after one of these incidents, there's just nothing there in terms of the stat. No communication with the stat appears to have been attempted, which is troubling as it implies a problem with the Elk or its handling of Rules rather than line interference, etc.

Have I stumbled upon some known flaw? Is there some test for diagnosis? I switched to this setup to obtain the most reliable system I could find that was still part of my automation system, and yet it's proving to be much less reliable than my old X10 stat system controlled by HomeSeer.

Anyone have any ideas on this one?

Thanks

Joe

Joe,

I'm using my Aprilaire 8870s with ELK and have certain firing problems as well. In my case, ELK upgrades, reboots, or changes result in a temperature discrepancy between my stats and ELK. What I did to further pinpoint my issue(s) was to interface ELK M1G with Powerhome that logs temperature and better details then the Elk logs. As a matter of fact, I have NO debug logging options with ELK "out of the box" except to telnet to the M1EXP (Ethernet module) and translate the commands that ELK is shooting over the main bus. I hope this hopes you isolate the root cause.


-=*Sharby*=-

Thanks, Sharby. It does help. I also just noticed, as you point out, that the Elk doesn't report stat changes in the log, even when it accurately fires an Elk rule. Thus, very hard to debug. I'm really hoping Spanky can weigh in on this, as it's a major problem if the Elk is missing HVAC Rule- based changes. Very unlike anything else for the unit, as it's otherwise been rock solid. It sort of defeats my purpose in moving HVAC control to the Elk. I'm happy to run diagnostics if the Elk folks can suggest any.

 

[johnnynine]

I've noticed on MANY occasions that my "HAI" thermostats don't get updated by the Elk. So maybe this is a broader issue.

 

[gcimmino]

Given how hard this could be to troubleshoot, it would be nice if Elk could add some debugging/logging capabilities.

I often wonder how failures of a stat to respond to a command from the XSP are handled, or if a read is done of a setpoint to ensure the "write" was successful.

 

[dlamb]

Thank you for reporting this. We have a thermostat set up on the bench here at ELK. I do some testing to see if I can reproduce the problem of missed commands.

To help in my troubleshooting, I'm going to use a rule to resend the command if a stat setting did not get processed the first time. Plus it will send an email, which I'll use as a time/date stamp (log) to indicate any day the first rule did not get processed. Example:

WHENEVER THE TIME IS 11:00 PM
THEN SET Don's(Tstat 1) HEAT DESIRED TEMP TO 65 DEG. F. (18 DEG. C.)
THEN TURN CheckStat (Out17) ON FOR 30 SECS

WHENEVER CheckStat (Out17) STATE IS TURNED OFF
AND Don's (Tstat 1) HEATING DESIRED TEMP IS ANY VALUE OTHER THAN 65 DEG. F. (18 DEG. C.)
THEN SET Don's (Tstat 1) HEATING DESIRED TEMP TO 65 DEG. F. (18 DEG. C.)
THEN SEND EMAIL MESSAGE 1 TO [email protected] (Email 1)

I'll also use a similar pair of rules to raise the setpoint in the morning.
Regards,

 

[johnnynine]

To give a little more detail on what I usually see:

I have a rule that when I set the alarm I activate the HVAC Economy Task, which sets the setpoitns on 2 thermostats. Sometimes during the day I will remotely check the thermostat values via CQC and they will be incorrect. Usually after reactivating the HVAC Economy Task remotely via CQC the thermostats will show the correct setpoints within a few seconds, however I have seen it where I would need to activate the task more than once.

 

[Black Magic]

I've had to workaround this problem by doing a forced resync every 5 minutes or so. Essentially, I just have a rule to set the thermostats to values in custom counters. This way the thermostats stay in sync with what the Elk main boards thinks they are set at.

 

[ultrajones]

I have seen this issue as well when controlling my HAI thermostat from the Elk M1. As a test, I sent a command to the Elk M1 to turn my thermostat on. The Elk M1 responded indicating the command was successful (as indicated in bold in the TR response). My thermostat fan turned on.

11/26/2007 6:58:59 PM Info Device: UltraM1G Plugin Thermostat 01 [HAI] Fan (`3) Value set to 1
11/26/2007 6:58:59 PM UltraM1G Debug Entered SetIO() subroutine.
11/26/2007 6:58:59 PM UltraM1G Debug Entered ControlThermostat() function.
11/26/2007 6:58:59 PM UltraM1G Debug ControlThermostat() is setting thermostat 01, element 2 to 01.
11/26/2007 6:58:59 PM UltraM1G Debug Sending command: 'ts0101200' to Elk M1, attempt # 1
11/26/2007 6:58:59 PM UltraM1G Debug Entered SendToM1G() function.
11/26/2007 6:58:59 PM UltraM1G Debug Sending ts0101200 to M1G via Ethernet.
11/26/2007 6:58:59 PM UltraM1G Debug Waiting for the M1 to respond with 'TR' for up to 1.5 seconds...
11/26/2007 6:59:00 PM UltraM1G Debug Entered ProcessReceived() function with a string '13TR011016868760000FA'

I then sent a command to turned the fan off, and the Elk M1 responded indicating the command was successful (as indicated in bold in the TR response). However, my thermostat fan never turned off. I had to send the command again before the thermostat fan turned off.

11/26/2007 6:59:14 PM Info Device: UltraM1G Plugin Thermostat 01 [HAI] Fan (`3) Value set to 0
11/26/2007 6:59:14 PM UltraM1G Debug Entered SetIO() subroutine.
11/26/2007 6:59:14 PM UltraM1G Debug Entered ControlThermostat() function.
11/26/2007 6:59:14 PM UltraM1G Debug ControlThermostat() is setting thermostat 01, element 2 to 00.
11/26/2007 6:59:14 PM UltraM1G Debug Sending command: 'ts0100200' to Elk M1, attempt # 1
11/26/2007 6:59:14 PM UltraM1G Debug Entered SendToM1G() function.
11/26/2007 6:59:14 PM UltraM1G Debug Sending ts0100200 to M1G via Ethernet.
11/26/2007 6:59:14 PM UltraM1G Debug Waiting for the M1 to respond with 'TR' for up to 1.5 seconds...
11/26/2007 6:59:14 PM UltraM1G Debug Entered ProcessReceived() function with a string '13TR011006868760000FB'

Regards,
Ultrajones

 

[Helheim]

I have the same issue with a RCS TR40.

All,

About three weeks ago, I switched from an RCSTX16B X10 thermostat, controlled by HomeSeer, to a RCS TR16 (RS485) thermostat controlled by my Elk M1G. The X10 stat was basically fine - maybe two problems in two years, but I wanted to move HVAC over to the most reliable thing in my system, my Elk. So... you can understand my concern when I find that the Elk doesn't appear to be fully reliable at sending commands to the new stat via Rules. In fact, it looks like it's missed about 6 or more cycles in the past three weeks, including a cold house this morning.

 

[Mike]

I had reported a similar issue with the Elk and HAI thermostats probably about a year ago. What seemed to help and was recommended at the time was having it send a HEAT ON before changing the temperature.

However: I noticed the same thing recently when the cold season came up with it missing the on sequence a few days a week.

What I did was to update all the firmware (I think I did everything except the Insteon XSP because I did not want to relink) and then also change the rules so that there were not two different rules firing using the same time value (i.e. 6:00AM). I changed them so alternates were a minute off (6:01AM). This was similar to an Insteon work around from awhile back.

This was not too long ago and I, nor my wife have noticed a misfire but it really isn't conclusive (especially since last season I thought I had it licked with the HEAT ON settings).

Hope this helps.

 

[Madcodger]

Don -

Thanks for commenting and testing. One of the many reasons I really like Elk - great support, including that provided on this board. Please let me know if there's anything I can do to help otherwise, and feel free to PM me if needed. You guys probably have my other contact info on file as well.

Also note that I do have one condition attached to these rules, other than the times and days of the week: Output 29 has to be OFF. This is because I have a separate set of rules that, if F5 on the Master BR keypad is pressed, Output 29 will turn on. That, in turn, puts the house into a vacation mode and holds the temp at 55 degrees until F6 on that same keypad is pressed. This allows one-touch control of vacation mode, and is easy for me to also set remotely if we forget and are a thousand or more miles away when we remember (gotta love home automation...). However, b/c the rule does fire normally a majority of the time, I don't think this condition is an issue.

All - Thanks for chiming in with variations of the problem and potential solutions. I have very few Elk rules set up (maybe 10 or 12, including 5 for the stat alone, and the rest just for reporting various alarm conditions via email) so I don't think it's simultaneous rules in my case. Most of my non-essential control is handled by Homeseer.

 

[adamwh]

For what it's worth, I installed a HAI thermostat about a week and a half ago. I've seen it miss rules-based set-point changes at least 4 times so far. The rules are simple "at this exact time activate task," one in the morning and one in the evening. I know the rule is firing because it also announces the task; it just doesn't seem to make it to the thermostat. Triggering the task from the keypad seems a little more reliable but I have no real evidence of that. All firmwares are up to date.

 

[Spanky]

We are looking into what could be happening.

Thanks for the input.

 

[Mike]

As an update, mine failed this morning, so the firmware/attempts to work around rules that fired at the same time do not appear to be related at all.