You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Let's consider the climate component as an example. There is an attribute "operation_mode" (let's assume we have a sensor detecting that with entity id "sensor.thermo_operation_mode"). Typically a user will have a frontend switch that allows to change this mode into different states "away", "home", "off", etc. (let's assume this has entity id "input_select.thermo_operation"). This is usually done in the following way:
a. There is an automation which triggers on a change to input_select.thermo_operation and which performs a service changing the climate accordingly.
b. There is an automation which triggers on sensor.thermo_operation_mode and which updates the frontend switch to match the detected operation mode.
The intent is the following:
If the user changes the selector (a) will trigger and change the operation_mode
If something changes the operation_mode, (b) will trigger and update the selector
However, what really happens is this:
If the user changes the selector, (a) will change the operation mode. Consequentially, (b) will trigger and again update the selector.
If the thermostat gets changed outside of HASS, or if some automation changes the thermostat, (b) will detect it and update the selector. Consequentially, (a) will trigger and try to change the operation mode again.
As you can see, both scenarios involve two redundant service executions. Now most of the time, these won't matter, as they are merely redundant. But what if the service executed was such that every execution of the service has a side effect? It would be wrong to perform the redundant executions.
So to do this automation right, what options do we have? We could, in all automations that change operation mode also update the state of the input selector. However, this is bad for two reasons: For one, now the automation would have to know what user interface elements exist, which is horrible. And secondly, this would not work with external changes to operation mode, e.g., when the user changes the thermostat directly.
It seems to me that the best way would be to have an input element which can both initiate a service and monitor the state of something, but these two activities should be independent. Then the input selector could reflect the state of for example operation_mode, but changing the input selector according to the observed state would not in turn trigger the action associated with actually changing the selector in the user interface.
The basic problem to be resolved is that the state of the selector can be changed for multiple reasons, but only some of these state changes should trigger the associated service.
The text was updated successfully, but these errors were encountered:
You can also add conditions to (a) and (b) so that they don't actually trigger unless states('input_select.thermo_operation') != states('sensor.thermo_operation_mode'). This way, the operation mode doesn't get changed when the input_select changes if it's currently in the mode selected and the input_select won't update when the mode changes if it's already showing the correct value.
Thanks. When I put this note together, I thought that putting these extra conditions on the actions was awkward, but you are right, it is not that clumsy. It requires sometimes larger value templates (if the action is based on a complicated template), but so be it. Appreciate the suggestion.
Let's consider the climate component as an example. There is an attribute "operation_mode" (let's assume we have a sensor detecting that with entity id "sensor.thermo_operation_mode"). Typically a user will have a frontend switch that allows to change this mode into different states "away", "home", "off", etc. (let's assume this has entity id "input_select.thermo_operation"). This is usually done in the following way:
a. There is an automation which triggers on a change to input_select.thermo_operation and which performs a service changing the climate accordingly.
b. There is an automation which triggers on sensor.thermo_operation_mode and which updates the frontend switch to match the detected operation mode.
The intent is the following:
However, what really happens is this:
As you can see, both scenarios involve two redundant service executions. Now most of the time, these won't matter, as they are merely redundant. But what if the service executed was such that every execution of the service has a side effect? It would be wrong to perform the redundant executions.
So to do this automation right, what options do we have? We could, in all automations that change operation mode also update the state of the input selector. However, this is bad for two reasons: For one, now the automation would have to know what user interface elements exist, which is horrible. And secondly, this would not work with external changes to operation mode, e.g., when the user changes the thermostat directly.
It seems to me that the best way would be to have an input element which can both initiate a service and monitor the state of something, but these two activities should be independent. Then the input selector could reflect the state of for example operation_mode, but changing the input selector according to the observed state would not in turn trigger the action associated with actually changing the selector in the user interface.
The basic problem to be resolved is that the state of the selector can be changed for multiple reasons, but only some of these state changes should trigger the associated service.
The text was updated successfully, but these errors were encountered: