Ah! Yes, that broken driver is the problem. I fixed it by switching to "Generic Z-Wave Plus Thermostat" instead, and doing a configure. I must not have done a configure when I tried switching before? Also, the T6 specific driver worked for me before, but probably because I didn't configure it when switching, so it had the old values from whatever the previous driver was.
Thanks, looks like I'm good!
This (re)-regressed from 2.3.3. Would it be possible to just handle List<String> by itself instead of requiring double-wrapped strings? This isn't a common paradigm in any language, I feel.
These are JSON objects. See this Driver Capability List | Hubitat Documentation
Look for Thermostat.
See this post:
Why would you guys change this - it's been the way it was for YEARS?
Suddenly re-implementing in a manner that breaks working apps & dashboards...with such a large installed base; Don't you try to maintain compatibility so that things don't just stop working after an upgrade?
Further - exactly how would I change my code so that it both works with EXISTING non-beta installations, plus the new model?
What was the motivation?
Because it was fundamentally broken, did not conform to the documentation, and there is no supported data object that fits the way it used to be. It was a mistake.
So, faced with the choice of going forward with a mistake that didn't make sense, and getting it right, we chose the latter. The vast majority of our customers use built-in drivers. So these were all updated at the same time as the apps. We did our best to communicate the change needed to user drivers, but obviously that is not a one-and-done thing.
We're sorry for the inconvenience. If you are the author of a user thermostat driver, please fix it. If you are a user of a user thermostat driver that has not been fixed, please contact the author and ask them to fix it. For example code for how it is done in a driver see this:
Please note the key elements:
attribute "supportedThermostatFanModes", "JSON_OBJECT"
attribute "supportedThermostatModes", "JSON_OBJECT"
This is always how these attributes have been defined in the documentation.
This problem came to light when users attempted to use a Custom Attribute in Rule Machine for these attributes it failed. Granted, staring the enemy in the face and knowing that you are the enemy is not where one wants to be. But that's where we were. One of us blinked, and that's why the fix was carried out.
I am in fact the author of the Ecobee Suite.
Your explanation is appreciated. I guess I didn't see your notification that things were changing in this manner.
Sadly, I had implemented the way I had because that was the only way things would work properly with Hubitat dashboards and SmartThings when I first ported this over from my original SmartThings implementation. And FWIW, I'm pretty sure the "old" implementation worked fine with some (older) versions of Hubitat Rule Manager as well.
I will endeavor to update my suite/implementation to accommodate the new way of doing things as soon as I can. Unfortunately, this is/was totally unexpected, so I don't know that I will be able to fix and test my entire suite before you release 2.3.4.* (there are 14 devices and apps that will have to be changed on my side).
Fortunately, I don't have to test the changes on SmartThings any more, as they have totally deprecated Groovy custom devices.
Do you have an estimated timeframe for releasing 2.3.4.*?
Thanks!
It has already been released.
The change to thermostats happened in 2.3.3.
For closure, I have released today an update to my Ecobee Suite that appears to have solved the problem...
Please bare with me as relative newbies with little understanding of drivers and the like for HE.
How can i modify a driver (the popp TRV thermostat mentioned above) to implement a fix in order to avoid having to re-assign this TRV thermostat as "Generic Z-Wave Thermostat", setting the JSON and values, then reverting back to the fault/popp driver?
Is this possible as it has been a reoccurring issue for me.
thanks
Where is the source code available online for that driver?
@mark.cockcroft can advise if needed, but the change should be something like this.
That is, you should replace these lines in def configure()
:
sendEvent(name: "supportedThermostatFanModes", value: ["off"])
...
sendEvent(name: "supportedThermostatModes", value: ["off", "heat"] )
with these:
sendEvent(name: "supportedThermostatFanModes", value: groovy.json.JsonOutput.toJson(["off"]))
sendEvent(name: "supportedThermostatModes", value: groovy.json.JsonOutput.toJson(["off", "heat"]))
Then, click Configure
on the device page.
appreciate your feedback and comments, everyone.
On the assumption that:
this (the author updating) cant be relied upon, is it safe for me to update the existing driver as described above?
Or should i create a new driver with the mods applied?
I note that my current temporary fix (as shown by @bravenel above) requires me to apply
["auto","off","heat","emergency heat","cool"]
rather than
["off","heat"]
as is suggested. Being a novice, i dont want to risk breaking it further, i'm sure you'll appreciate.
again, apologies for my lack of knowledge
You don't need to touch the driver. Just follow the instructions linked above to update the thermostat itself.
That's what i have been doing since you advised me on it.
If i reconfigure the device or sometimes when i do a FW update i have to go through this process again. Not a massive chore now i know how to do it, thanks to your help, it but the unpredictability of it reoccurring motivates me to find a more permanent solution.
Does this fix also work for nest thermostat? I tried your instructions above and it changed back when I switched the driver back to nest.
What is the problem you have with the nest? Show a screenshot of its Current States from the device page.