That is the "accumulator" and will always show as all = Null since they get cleared, ready for the next batch, as the last thing after each Send to Honeywell. I expect to get get questions about what it's for since it appears to never change. You'd only have 1.6 seconds to see the change
If I take out the delays, I assume all of these commands would use the same session info, and I assume instead of 2 calls to each, it would do these in 1 call to each thermostat?
Also, what should we set refresh to if we have more than one? Set them the same or different? If we do a refresh on one, will it get the data for the other and populate it without a refresh on the 2nd thermostat?
The Thermostat Child drivers are intended to be independent. Each button press in a Child Device Info page, or injection via automation, hits the Parent (where all the work is done) with the child's ID. Everything is saved/stored, acted upon, using that ID.
For a single Thermostat home, like me, using this version should benefit from the Accumulation feature only. Even the number of lines of code are quite similar.
~1000 for v1.3.20
~800 for v2.0.3
220 for the child driver.
There's easily 20 more lines of comment in v2.0.3, which also means they are quite similar in impact on the Hub. It's the 2nd thermostat where the big gains occur. Using v1.3.20 would use ~2000 lines of code while v2/0/3 would be ~1240
I have two hubs that are talking to the same Thermostat using the new driver. My Production hub is on a 60min poll cycle while my Development hub is on a 30 min cycle. I have received the dreaded "failed" only once in 12 hours. If I wasn't the developer, I probably would stick with the single driver because I rely on the built in schedule, now that I've got it set to my liking. I have no automations at this time aimed at the Thermostat. That said, I created in my head an automation I'd like to try.
The damn honeywell home new driver is no better .. I hate honeywell... If it wasnt for my integrated redlink therm with steam humidifier .. sensors in the ducts and outdoor temp i would punt them.
I just added code to the honeywell home driver for my two wifi therms in our condos in FL to only put out the error message if it fails on the refresh retry as that one is failing regularly also and i am tired of seeing the error in the logs. I assumed the newer t6 apis would be better. Shame on me. Why dont they invest in some servers to handle the bandwidth or get some decent programmers.
As you might expect, I spent a LOT of time clicking on the new driver's buttons to be sure they worked as expected. Across a 2 hour development session, I'd probably hit Honeywell 200 times. In that time I'd get 3-4 Rejects. I'd always just hit the button again as soon as I got it. It certainly was under a second later, 90%of the time that was good enough, it would make the connection. I remember one time I got rejected twice in a row. For the most part though, Honeywell took the beating I gave.
What I can say is that I saw a pattern in how the fail worked. I think I can exploit that to handle retries better... earlier in the process. But first, I'm listening for issues with what I just barely released
I was going to say I only see about 3-5 failures a day across my two devices. I was wondering if you’re capturing the failures and resubmitting the info again after some sort of cool down time. It seems to be working great for me thus far, but I only use in automations and don’t use the Hubitat thermostat UI To make any changes.
There's code in there for that (that I didn't write, a pull request) that I never saw get used during the new development. It probably solves a problem I don't hit, because I'm such a minor user of the driver. but watching for it, caused me to see the pattern I mentioned above.
I never saw it 'trip' in the few instances when I was rejected during development of the new driver.
log.debug "Scheduling a retry in 5 minutes due to Unauthorized!"
runIn(300,"refreshFromRunin")
I was certainly looking at Scheduled Jobs a lot, but never saw either the message or the runIn. Which is not to say it never happened, just that I never saw it.
I started to research my idea to be more resilient on login failures... I set the driver to poll every 3 mins. Not a single error in 2 hours. Darn Honeywell, so unreliable, they won't even fail in a reasonable time
This is for the IAQ prestige which is the two wire with the EIM.
They make indoor sensors that can be used as a remote to control the thermostat or be agregated.
But like you say since the web login can't see it most likely it can't be done. Although the funny thing is the outdoor sensor is red link as well and it's seen..
However, 0.047% is a very tiny number.
