Hi,
I am writing a thermostat driver. I want to get the dashboard to simply show the up and down arrow with the set point and the heating status. These thermostats, like all thermostats in Québec, are simply heating or not. There's no off, there's no mode, there's no fan, there's no cooling.
I have two issues:
I can't get the arrows to be shown with the thermostat tile
I can't get the other stuff (thermostat mode, fan mode), to not be displayed.
What capability or functions need to be implemented in the drivers to get a tile that looks like just 2 arrows to set the heating point, and display the heating point and whether it is heating or not ?
I have tried setting various capabilities... "Thermostat" shows way too many features that don't exist for this device, I defined increaseHeatSetpoint and decreaseHeatSetpoint commands, they show in the device page, but not on the dashboard tile, and instead, the dashboard tile shows unknown mode and unknown fan mode (it should simply not show them, there's no mode to change).
Your thermostat driver should implement all capabilities and commands required by capability "Thermostat", as defined here: Driver Capability List | Hubitat Documentation. Otherwise, it may not work properly with an app, including Hubitat Dashboard (which may not use all of these commands and attributes, but it's still a good idea).
For a thermostat that only supports heating, you can set the supportedThermostatModes to ["heat"], or maybe ["auto", "off", "heat", "emergency heat"] or something between the two, depending on what the device actually supports. The thermostatMode attribute should be set to one of these, perhaps heat (but off makes sense sometimes for a lot of devices, too; again, not exactly sure what one you are dealing with). The capability requires this, but it's OK to only report or accept a single value if that is what the device actually does.
You do not need to define custom commands like increaseHeatSetpoint. Hubitat Dashboard does not, in general, support custom commands, so adding them to your driver will not change any functionality it provides. You do need setHeatingSetpoint() and even setCoolingSetpoint(), though for the latter, you could just log a message saying that it's not supported or set the heating setpoint or whatever makes sense. These are the commands that Dashboard (or any app) will call, depending on the current thermostat mode.
PS - I'm not sure if Dashboard pays attention to supportedThermostatModes and supportedThermostatFanModes at the moment, though more and more apps are starting to use these and similar attributes in other capabilities. It's possible that, at the moment, it will let you choose cooling mode or anything else the device might not actually support. This might change in the future, but I'd still recommend your driver conform to the capability; you could, for example, write an error or warning to the logs if the user tries to set the thermostat to an invalid state.
For this thermostat, up/down arrows should always be shown (they seem to disappear when it's not heating with another thermostat driver I used), and the fan mode and thermostat modes should never be shown.
Is there any way to accomplish that ?
Is there a public example of code that implements everything that is needed ?
The documentation says what needs to be defined, but there's no examples of how to actually define these things.
Alternatively, is there another capability that I can define which will allow a tile that shows two arrows, up and down, and will call functions in the backend that can change the set point ?
Yes, that's a lot better. I don't understand why it's a lot of tinkering, it should just be the way a thermostat tile behaves if it does not support cooling/fan/modes/...
Also, there is no need for the "off" mode...
The arrows should be displayed regardless of the mode. There is no "on", the way to set it "on" is to increase the degree, and I can't increase the degree without having the arrows.
My thermostat don't have a on/off setting either. This is just a personnal choice I made while making my driver because I find it more convenient (OFF just put the thermostat at is lower setting and ON set it back to original)
You can't stop an app from sending an invalid value; anyone can write one that sends anything. What you have control over is how the driver responds--and setting the attributes for what modes the thermostats support so a well written app shouldn't. (Again, I'm not sure if Dashboard is one of these apps yet, but more and more have been paying attention to this lately, so I'd expect it in the future if not.) You can handle unexpected values for these commands by logging an error, not doing anything at all, or however you want.
I think this happens if the operating state is off (if it's off, it doesn't know whether to set the heating or cooling set point, so what command would it call?). If yours always remains in heating mode, this shouldn't happen. But does the device not support "off" mode? Thermostat mode is different from operating state (cooling, heating, fan only, off, etc., depending on the device).
yes, I figured that. If I just bypass the mode changes so that it internally always stays in "heating" (regardless of whether it is heating or not), then the arrows remain visible. If the thermostat mode becomes "idle", then the arrows disappear and it can't be turned on anymore.
idle should keep the arrows visible, that means I need to always set the thermostat mode as if it were heating, regardless of the mode reported by the thermostat, regardless of whether it is actually heating or not.
now I need to be able to remove the "heat Mode" and "auto Fan Mode" boxes, and just center the two arrows vertically, that would be great. (the "and on" and the "Heat" are also useless information and could be removed, but less annoying than those boxes below).
Depending upon what you are going for, and how you want things, I use a totally different method for some of my thermostats.
I create some virtual switches, and name them {whatever temperature}. Then I use a short rule to set the thermostat to that temperature when the switch is activated. I use the auto-off feature in the switch to turn off after a few seconds. I like seeing the switch light up and then turn off which is why I used switches instead of a button. And switches can be used in Alexa too, so you can just holler "turn on hot tub 99" and she does it.
This method works great for things like my hot tub and garage where I toggle between a couple different temperatures all the time.
It has exactly the same behavior with thermostats imported through HADB using the Generic Component Thermostat driver... and this is part of what has driven me insane about it and drove me to write a custom zigbee driver so I could fix what's broken
