The Generic Thermostat integration toggles a heater switch to control the temperature. In many cases this switch is a physical device with a button. It would be useful if the button could turn the thermostat on/off in addition to the heater. This should only work in cases when it wasn’t the thermostat itself which toggled the heater of course, otherwise both the heater and thermostat would turn off once the target temperature is reached.
Here are use cases to help explain: User uses heater button
User wishes to turn the thermostat on/off from within the room with the heater
User pushes the heater switch button, for instance a Sonoff mains plug to a space heater
The heater turns on, since the button works locally
HA detects the unexpected switch state change and toggles the generic thermostat state
User uses thermostat
User wishes to turn the thermostat on/off from away from the room
User uses Lovelace or other interface to toggle the generic thermostat state
Thermostat toggles heater switch
Generic thermostat toggles the heater switch state to reach the target temp
Heater switch state change does not toggle the generic thermostat as it was the thermostat which initiated the heater state change
This FR contradicts the basic operation of a thermostat.
A thermostat is used to govern the operation of the heating (or cooling) device. It’s the temperature differential, between ambient and target, that determines when the device should be turned on/off.
If ambient is equal to target, the thermostat ensures the heating/cooling device is off. If you manually turn on the heater, the thermostat will turn it off to prevent ambient rising above target. That’s the core responsibility of a thermostat, to ensure ambient is equal to target.
You propose to modify that behavior by turning off the thermostat when the heater is manually turned on by a user.
How do you propose to detect when the heater switch was turned on by a user? It can be detected if the heater’s entity is turned on in the UI (via context.user_id) but how will it be informed if the user presses the physical heater switch?
That was not my intention. My explanation may have been unclear.
The request is to have an option to treat the heater switch button as thermostat switch instead. The thermostat should exert full control of the heater to maintain target temperature or turn the heater off when the thermostat is turned off, just like a traditional thermostat on/off button.
Yes, that is the intended behavior in this case. The user who enabled this option should be aware that the button is no longer a heater switch but a thermostat switch, meaning the thermostat may turn the heater off.
I propose turning off the thermostat by pressing the heater button while the thermostat is on (button toggles thermostat). This may or may not be while the heater is on, depending on the room temperature. Pressing the button to toggle the thermostat from on to off while the heater is on would turn everything off. Doing so while the heater is off would briefly turn the heater on before everything turns off.
The major drawback is that the thermostat state user feedback is identical for on and off while the room is at the target temperature. The user should know the prior state before pressing the button.
I initially hoped the devs would find a way, which is why it’s a feature request and not an automation; however, after digging deeper I found this thread which explains a way to distinguish button presses from other triggers. If both parent_id and user_id of the event are null, the state_changed event was triggered by the device button. Given this new information, I can achieve the desired result using an automation as opposed to this feature request.
When the heater switch changes state and the trigger variable’s context.id contains a value but context.parent_id and context.user_id contain null values, then the switch was operated manually. The automation’s action turns off the thermostat if the switch was turned on, otherwise it turns it on if the switch was turned off.
Hi there,
how would you apply this rule to multiple Generic Thermostats?
I tried to modify the code according to what you have suggested here, but I’m stuck at the point where I have to link a switch to the corresponding thermostat (target_fancoil)
I believe something is missing in the condition tho.
Monitoring the behavior I found out the automation was triggered by the service “homeassistant.turn_off” which I suspect happened when the Thermostat reached the target temperature and the system itself toggled the switch.
Here’s how the context object usually behaves depending on who or what was the trigger’s source.
Action
id
parent_id
user_id
Physical
Not Null
Null
Null
Automation
Not Null
Not Null
Null
UI
Not Null
Null
Not Null
If your tests show that the behavior fails to match any of the combinations in the table, or corresponds to an unexpected combination, then it’s potentially an anomaly and something that might need to be reported.
Recently I’m receiving some situations in which the “physical” actually happens to behave as “automation” (i.e. parent_id is not null). That’s weird. Maybe something changed in the recent HA updates.
However, when trying to reproduce each case individually, I still get results based on the table.
Hm… I think Home Assistant sometimes assumes a state change was caused by some automation (while in fact it was not, but indeed the automation was triggered in the same timestamp). I’m adding a 5 seconds delay to the automation state trigger to help circumvent the issue. Not sure if it will help though.