I am running firmware 1.14 and have two thermostats (upstairs and downstairs) and 1 temp sensor, which is located upstairs. I was woken up about 1:30 a.m. last night and it was about 84 degrees in my house. I immediately went to the upstairs thermostat, which was set at 70, and turned it off. I think that it indicated that the temperature was only 70 (even though the app reported it was much higher), but I was pretty groggy so I’m not really sure about that part. The upstairs thermostat was linked to the temperature sensor and I had selected the upstairs set point to be based on the temp sensor only.
After I cooled the house a bit, I did a quick test of the thermostat by raising the set point. The furnace indicated the thermostat was calling for heat by blinking rapidly. I immediately lowered the set point and the furnace turned off. So that appears to be working normally. My only guess is that the temperature sensor stopped reporting the correct temperate or the thermostat just never turned the furnace off. If the thermostat called for heat, but never updated the actual temperature, it seems like that would cause the heat to run continuously. Is any sensor data logged? It would be interesting to know if the thermostat and temp sensor started to diverge dramatically.
It sounds like what may have happened then (since in this case the Temp Sensor had direct control over when the thermostat would turn off the furnace) is that the temp sensor stopped reporting proper temperature values to the Thermostat.
This may be caused by a few things:
Temp Sensor might be mounted in a location where ambient temperature is interrupted. Is it near a window? Is it mounted on a colder exterior surface?
The temp sensor may be experiencing communication failures. Check to make sure there are enough devices on the network that support network wide inclusion and beaming repeating. The Temp Sensor, unlike most devices, must be learned into the panel with the RTS and the panel in their final locations, with the proper communication routes decided during the learn process.
The Thermostat may be experiencing communication issues with Temp Sensor. Again, this would rely on your Z-wave network and the repeating devices.
In general, we would not recommend at this time to use the temp sensor as the only direct method of controlling the Thermostat. Instead, we would recommend using the averaging feature.
With as many bugs that the T2000 still has, I would not put my faith into an accessory zwave temp sensor at this time.
Maybe in a couple years or so. It is just too glitchy at this point. I see it more as a gimmick, now when it can actually be used to automat the opening/closing of zwave registers, and operate optimally without issue or fail, then it will go from gimmick to useful smart tstat sensor.
I think the location for temperature is fine. The thermostat is on an inside wall away from windows. The sensor is in a bedroom and the thermostat is on the wall just outside of the bedroom, so maybe about 5 feet away. I learned the thermostat in on ac power, so it should be repeating. There is at least 1 node that I know for sure that uses NWI between it and the panel, but I could probably find a suitable place to add another one.
At any rate, I agree that, for whatever reasons, it’s just not reliable enough in my system to use alone. It would be a nice feature if it works reliably, but it’s not worth it to me to lose a couple hours of sleep in the middle of the night (not to mention the extra dollars in my gas bill!) I suppose that’s the price of early adoption.
In any event, Surety/your Dealer can check and see if it is repeating or not (learned in on battery or C wire)
Both Tstats on the account show AC, so good there.
I do see some failed messages due to no transmission route which likely correspond to the temp sensor. Have you noticed any other issues with the temp sensor? Malfunction reports, etc?
Thanks Riven, I think I did learn it on only powered by the C wire (no batteries) after reading another thread about that. I wouldn’t mind knowing for sure if Surety wants to check.
Also, does anyway know if the GE products support beaming/NWI? I did a quick search but couldn’t find anything definitive. I have a GE wall outlet about 10 feet from the panel, within 15 feet of the thermostat. I also have a Leviton Vizia RF lamp module between the GE outlet and the thermostat. It seems like I should just add another node close to the thermostat and temp sensor just in case.
Jason, the only problem I noticed was that if I go into the app and select the temp sensor, it will use the temp sensor for a while (whether by itself or averaged), but then at some point within several hours it goes back to relying on the thermostat only. I suppose maybe that should have been a clue? But I have never received any malfunction report.
the only problem I noticed was that if I go into the app and select the temp sensor, it will use the temp sensor for a while (whether by itself or averaged), but then at some point within several hours it goes back to relying on the thermostat only.
That may indicate the thermostat is in fact losing further updates. The temp sensor may be having trouble communicating after going idle. I’ll bring this to ADC and see if any remedies are known.
At this time I would definitely use the averaged temp and not the RTS only to determine current temps.
the only problem I noticed was that if I go into the app and select the temp sensor, it will use the temp sensor for a while (whether by itself or averaged), but then at some point within several hours it goes back to relying on the thermostat only.
This is not an error. This is an expected function of the thermostat caused by an error.
The issue definitely looks to be the RTS losing communication. The T2000 is designed to take over after a couple hours of failed comms with the RTS should you have the RTS set to either provide an average temp or direct control. It looks like the safety feature may need to be a bit more aggressive in this case.
For clarity, have you moved the RTS since learning it into the network? It should not be moved once learned in.
We would like to keep an eye on the function of the RTS, would you mind removing and re-adding that RTS to your network?
I didn’t move the rts after learning it in. I’ll remove it and re-add it to the network tonight. Just to be clear, I should:
exclude the rts
perform a network rediscovery
include the rts
An interesting note, I have a garmin watch with a built in thermometer. I happened to take it off before going to bed. I was able to tell from the temperature history that it started heating up around 11:30pm. I woke up around 1:30am. So that couple hours could have easily been within the “several hours” you described as a safety feature.
A network rediscovery is important for your other devices in the network, yes, and can be performed after removing the RTS.
The RTS itself will not participate in a network rediscovery.
In looking at the history on the account your description makes sense. After speaking to ADC, it sounds like you would have woken up right about the time the thermostat should take over and switch control to itself.
If you often see the RTS being removed as the controlling device after a few hours, that indicates it is losing communication regularly and quickly.
I relearned the temp sensor yesterday morning. It was learned in the exact same spot as before. It worked ok yesterday. Now I’m getting the orange triangle and a message that says “Your thermostat has stopped receiving temperature sensor updates…”.
I know there was an issue reported with firmware 1.13 interpreting 1 way communication windows as a malfunction. Do we know for sure if this was fixed by 1.14? If it was, then maybe I can narrow down the communication issue.
Also, if it is a communication issue, it there any way to tell if it’s a zwave network problem, or a problem with the RTS itself?
Diagnostics available for Z-wave communication are not ideal.
We can determine if issues exist, but any dropped packets do not indicate which device they were intended to reach. Diagnostic counters accrue from the installation date of the panel, so without being able to tie them to a specific device it’s hard to tell if early installation issues caused dropped packets.
I have reset the counters so they will start fresh and any subsequent activity can be more safely assumed.
I do not know for certain that these errors would be cleared and resolved by 1.14. Nothing to that effect was specifically addressed by documentation.
When you received that error, was your RTS no longer connected to the Tstat in the back-end settings? Did you need to select its check box once again?
Next time this occurs, can you take a quick screenshot of the alert message?
I would like to send it to ADC. I am discussing this with their support folks.
I know the error you are seeing, it would just be helpful to send over so nothing gets lost in translation.
It sounds like the same issue as before. The RTS fails status with the TStat and gets pulled from being connected so that the current temp remains accurate.
