I've been using this and it's great, so thanks for publishing, but I think I found a couple of small bugs in the response handling:
In the handling of result.tempunits, in the else branch the variable tempunits is not in scope for the call to sendEvent(), and I think the value should be state.tempunits for that call.
In the handling of result.spacetemp, I believe the line that compares device.currentState().value to spacetemp.toString() should compare to temp.toString() instead -- there is no variable called spacetemp in that scope, there is result.spacetemp and the local temp.
In the handling of result.hum, the comparison of device.currentState().value to mode should be a comparison to state.humidity.toString() or result.hum.toString(), as mode is not defined in this scope.
The temperatureScale attribute wasn't being published by MakerAPI, so I added to the metadata.definition:
He did the same in the Vera community some time ago. "Withdrawing" probably doesn't have any teeth.
I wrote the Venstar driver for Vera, so it's no problem for me to write a new one for Hubitat, which I will gladly publish under the MIT License, I was just looking for the path of least resistance. What a coincidence to run across the same person, and the same behavior, in that search.
This driver is completely new and offered under the MIT License. All feedback welcome. This is my first driver for Hubitat, hopefully the first of many.
Operationally I think it's close enough to the previous driver that it wouldn't be much of an issue to switch for most people. The supported capabilities are kind of obvious, no magic there.
Still on my to-do list: child devices for extra sensors, runtime stats query and reporting.
Shout out/thank you to @VeloWulf for the discussion and jump start on Digest authentication. This driver supports basic and digest authentication (older thermostat firmware may only have basic). Still some details there I'd like to smooth out, but what's there works reliably (well, for the one data point that is me ).
I'll give it a try. My actual driver is working ok, so no need to change it but I think your work worth a try and a feedback.
In my case, I use Celsius on a geothermal unit and with an external temp sensor... with a T5800. Is your driver made for it ?
I haven't tested the T5800 (and I don't have one). If it supports Wi-Fi and the same local API as the T7850/7900/8850/8900, it's probably OK. The driver currently doesn't create child devices for external sensors, so if you rely on that, I'd hold off.
not obligatory. in the T5800, the external sensor is managed by the thermostat itself like the internal sensor (the variable in the api is the same). It's just that the value harvested and stored in the (same) variable is internal or external (or even both).
OK. I've just updated (now version 21270) with some improvements to handling of certain request errors, and configurable units (override system/hub units). I also added the commonly-seen support code for the T2000. Reviewing all the docs, I see no reason this driver would not work with the T5800/6800/5900/6900, and hopefully now T2000 as well.
Sorry, I forgot to update my header comment before checking in. I'm still working on my build procedures for this platform. If you scroll further down, to about line 179, it should show 21270.
I just found this awesome driver and installed it. I have two T5900's. Everything works as expected except from a dashboard thermostat tile. I can set the fan mode to AUTO, but cannot set it to ON. This functionality works from the device menu.
Thanks for letting me know. Seems like the dashboard puts some extra spaces in the command arguments for whatever reason, but that's easy to work around. New version is up.
I just noticed that in the logs there are INFO entries that say "Upper Thermostat: Number of active stages is now null". These appear every time the stat is polled. What is cause of this? Any way to make it stop?
).
