I have a number of these z-wave Stelpro thermostats, and every now and then there will be a missed or incomplete event. Last night for example, one thermostat should have changed the set temperature at 21:00. However, I noticed this morning that the temperature was still what it was yesterday afternoon. This effectively meant it “missed” two events (21:00 and 05:30).
I’m a new member to the community, so I can’t post more than one screenshot in a post (apologies for cramming many images into one).
The first screenshot shows the events I see when a normal temperature change occurs. The other screenshots show abnormal event firing in the last 24-hours.
I restarted the hub a few days ago (first time in over a year; restarted for unrelated reasons to this), and for the most part these thermostats (all the same model) work reliably. Occasionally when I notice a particular thermostat isn’t changing temperatures as expected, I’ll go and hit “save” again in the SmartApp (I’m using “rboy : 5-2 Day Thermostat”). I haven’t had any network or hub outages.
I’d appreciate any thoughts on what might be wrong and/or how I can diagnose the issue further. Thanks in advance!
seems like a pretty good problem description. I don’t have an ST solution since we don’t have a perfect cloud-based automation system here.
My WORKAROUND is to set resident time-schedules in the Tstat, with early-times and setpoints that meet typical need - this rarely fails. Then automatically, remotely tweak the setpoints by my personal ridiculous optimized criteria - anticipating that these remote commands may never execute (and maybe that’s for the best).
Thanks @ero4444. I’m still relatively new to the “back-end” of the SmartThings interface, so it’s taking me a little while to understand what is going on in the logs. Appreciate your input & experience around the reliability of scheduled events. When I went back and looked more into the logs, it appears the scheduled events from the Smart App were firing as scheduled (for the most part), but the device itself didn’t always update. Even tonight, a temperature change event fired on-time, the app (classic) displayed the correct (new) set temperature, but the device itself still showed the old temperature.
Two things I noticed. Firstly related to that event, I saw (at least during this most recent failure) that there was a Java timeout exception. There’s a thread in these forums that speak to timeouts; I just haven’t gone through it all yet:
Screenshot of the timeout; I believe the entry at the bottom of the screenshot was the event firing; the last entry at the top of the screenshot was the timeout.
The second thing I noticed in the logs specific to this particular thermostat, was the high-frequency of updates being sent from it. Often times there are many updates per minute, and they seem to be incomplete at that (they don’t contain the set or current temperature). This doesn’t go on all day; there just appear to be chunks of time where a ton of these occur, then “normal” polling behaviors resume.
I’m going to have to educate myself more on the first topic (timeouts) and perhaps debug the Smart App based on some of the comments in the referenced thread, to see if I can eliminate the timeouts. As for the high-frequency of (useless) updates coming from the specific thermostat, I might try reaching out to the manufacturer.
you said java which was disorienting. I never remembered the IDE log refers to java errors. Anyway,
The long-execution-time is an old problem. I thought it was obsoleted, I guess not. I am supposing it is caused by a long smartapp and intermittently high traffic. My first workaround would be 1. initiate in likely NON-peak time. Notice you probably scheduled at 9pm on the dot - pick a time before the dot like 8:58:31pm
Next workaround 2. shorten the smartapp. It should be the first workaround but I am mostly a cut-paste-monkey in groovy.
Regarding the large number of crappy updates, that sucks. Sounds like a firmware or smartapp problem that would be beyond me to fix.
