Thermostat scheduler unable to set fan or mode

[gd02]

First noticed in 2.3.4.115, but still happening in 2.3.4.116.

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)

[gd02]

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.

[bravenel]

This is most likely caused by a faulty driver. What type thermostat is this? What driver? Please post a screenshot of the Current States from the thermostat device page.

If this is in fact the problem, it is easy to fix.

[gd02]

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.

[bravenel]

That driver is out of date, and its author should update it.

The supportedThermostatModes and supportedThermostatFanModes attributes have bad values. For each, the individual words need to be in quotes. To fix it follow these steps:

Temporarily change the driver to Virtual Thermostat, hit Save Device. Then put this string in the command box for setSupportedThermostatModes

["auto","off","heat","emergency heat","cool"]

and hit the command button. Then put this string in the setSupportedThermostatFanModes command box:

["on","auto","circulate"]

and again hit the command button for that.

Then change your driver back, and hit Save Device. That will fix it.

[gd02]

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!

[interrobang]

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.

Thermostat tile kaput?

2.3.3.123 (just released) has dashboard tile logic that's more tolerant of mode and fan mode enum values.

[bravenel]

@interrobang

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.

[bravenel]

See this post:

[DEPRECATED] Universal Ecobee Suite, Version 1.8.01

An exemplar of how to do this correctly can be found in the public repo Virtual Thermostat driver:

[storageanarchy]

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?

[bravenel]

@storageanarchy

Why would you guys change this - it's been the way it was for YEARS?

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:

hubitat/HubitatPublic/blob/master/examples/drivers/virtualThermostat.groovy

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.

[storageanarchy]

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!

[bravenel]

@storageanarchy

Do you have an estimated timeframe for releasing 2.3.4.*?

It has already been released.

The change to thermostats happened in 2.3.3.

[storageanarchy]

For closure, I have released today an update to my Ecobee Suite that appears to have solved the problem...

[DEPRECATED] Universal Ecobee Suite, Version 1.8.01

EcoBee Suite Updated December 12, 2022 at 1:30pm EST Again my apologies for the silence. My wife & I have been travelling & RVing a lot this last 9 months or so, and I haven't had much time for my coding hobby. Fixes & enhancements: Added rudimentary support for the fanSpeed setting. Current value is reported in the attribute fanSpeed, and there is a new command setFanSpeed(speed) where 'speed' is one of ('low', 'medium', 'high', 'optimized'). Note that this only does anything if your HVAC a…

[UkSub]

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

[tomw]

@UkSub

the popp TRV thermostat mentioned above

Where is the source code available online for that driver?

[UkSub]

@tomw

Where is the source code available online for that driver?

https://raw.githubusercontent.com/Mark-C-uk/Hubitat/master/Danfoss%20Living%20Connect%20and%20POPP%20Radiator%20Thermostat

[tomw]

@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.

[bravenel]

Thermostat scheduler unable to set fan or mode

That driver is out of date, and its author should update it. The supportedThermostatModes and supportedThermostatFanModes attributes have bad values. For each, the individual words need to be in quotes. To fix it follow these steps: Temporarily change the driver to Virtual Thermostat, hit Save Device. Then put this string in the command box for setSupportedThermostatModes ["auto","off","heat","emergency heat","cool"] and hit the command button. Then put this string in the setSupportedThe…

[UkSub]

appreciate your feedback and comments, everyone.

On the assumption that:

@Thermostat scheduler unable to set fan or mode

That driver is out of date, and its author should update it.

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