First noticed in 18.104.22.168, but still happening in 22.214.171.124.
In thermostat scheduler, I can change the fan and mode in manual, but in schedule, I can no longer change the fan or mode for any of the schedule periods, or away. When I click one of them, I get a busy spinner in the top right for a second, and then nothing. Not sure when it last was working, but I only created the thermostat schedules a couple months ago, and it worked fine then.
I've tried rebooting the hub, and restarting my browser.
(By the way, trying to change the mode from Auto to Heat, since Homekit doesn't seem to work with Auto thermostats - Edit: which seems to be working now, either because of .116, or because I changed the thermostat driver to Generic Z Wave Thermostat)
Tried removing the schedules and re-creating. Still can't set fan or mode in the schedules.
Tried removing the app, and adding the app again, then re-creating. I still can't set fan or mode in the schedule section.
Tried in Safari too - previously just Chrome. Neither work.
It's a Honeywell T6 Pro, and I've tried the "Generic Z-Wave Thermostat" which doesn't work at all - can't even use the device to set the setpoint. "Generic Z-Wave Plus Thermostat" does seem to control the thermostat, but doesn't work as indicated in scheduling. Also, the user installed "Advanced Honeywell T6 Pro Thermostat" controls it fine, and is what I had been using until I was trying to work around the homekit auto mode issue, and was working fine in scheduler last I tried, a month or two ago. But, changing back to that driver now, still doesn't work in scheduler. Also, note that I can change the fan and mode in the Manual section of the scheduler, just not in the schedule section.
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!
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?
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:
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.
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.*?
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.
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.