Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

User interface controls need more smarts #5491

Closed
Duoxilian opened this issue Jan 21, 2017 · 2 comments
Closed

User interface controls need more smarts #5491

Duoxilian opened this issue Jan 21, 2017 · 2 comments

Comments

@Duoxilian
Copy link
Contributor

Duoxilian commented Jan 21, 2017

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:

  1. If the user changes the selector (a) will trigger and change the operation_mode
  2. If something changes the operation_mode, (b) will trigger and update the selector

However, what really happens is this:

  1. If the user changes the selector, (a) will change the operation mode. Consequentially, (b) will trigger and again update the selector.
  2. 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.

@tboyce021
Copy link
Contributor

tboyce021 commented Jan 24, 2017

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.

@Duoxilian
Copy link
Contributor Author

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.

@home-assistant home-assistant locked and limited conversation to collaborators Apr 30, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants