See this post:
1 Like
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!
1 Like
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...
1 Like
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.
With my nest everything works fine from the device page. When I try to setup thermostat scheduler if I try change mode or fan mode I get a green circle in upper right and nothing happens. Also the dashboard tile works fine to adjust temp up/down but if you click to change mode or fan mode it does nothing and then the tile is locked (temperature doesn't work either) until a browser refresh. It has been this way for about a year.
This screenshot is after I tried your fix above.
The driver needs to be updated.
supportedThermostatFanModes must be ["auto","on"]
supportedThermostatModes must be ["heat","cool","auto","off"]
Until those fixes are made to the driver, apps will throw errors with this thermostat. An easy fix for some drivers was to temporarily change the device type to Virtual Thermostat, and enter the correct strings for setSupportedThermostatFanModes and setSupportedThermostatModes, entering the strings shown just above. If that was done, and the thermostat reverted to what you posted, then there is no option but to fix the driver.
I updated the google sdm api and that fixed it thanks.
