{"action":"created","issue":{"url":"https://api.github.com/repos/home-assistant/home-assistant/issues/5491","repository_url":"https://api.github.com/repos/home-assistant/home-assistant","labels_url":"https://api.github.com/repos/home-assistant/home-assistant/issues/5491/labels{/name}","comments_url":"https://api.github.com/repos/home-assistant/home-assistant/issues/5491/comments","events_url":"https://api.github.com/repos/home-assistant/home-assistant/issues/5491/events","html_url":"https://github.com/home-assistant/home-assistant/issues/5491","id":202345067,"number":5491,"title":"User interface controls need more smarts","user":{"login":"Duoxilian","id":24535446,"avatar_url":"https://avatars.githubusercontent.com/u/24535446?v=3","gravatar_id":"","url":"https://api.github.com/users/Duoxilian","html_url":"https://github.com/Duoxilian","followers_url":"https://api.github.com/users/Duoxilian/followers","following_url":"https://api.github.com/users/Duoxilian/following{/other_user}","gists_url":"https://api.github.com/users/Duoxilian/gists{/gist_id}","starred_url":"https://api.github.com/users/Duoxilian/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/Duoxilian/subscriptions","organizations_url":"https://api.github.com/users/Duoxilian/orgs","repos_url":"https://api.github.com/users/Duoxilian/repos","events_url":"https://api.github.com/users/Duoxilian/events{/privacy}","received_events_url":"https://api.github.com/users/Duoxilian/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":1,"created_at":"2017-01-21T22:49:57Z","updated_at":"2017-01-25T03:38:52Z","closed_at":null,"body":"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:\r\n\r\na. There is an automation which triggers on a change to input_select.thermo_operation and which performs a service changing the climate accordingly.\r\nb. There is an automation which triggers on sensor.thermo_operation_mode and which updates the frontend switch to match the detected operation mode.\r\n\r\nThe intent is the following:\r\n1. If the user changes the selector (a) will trigger and change the operation_mode\r\n2. If something changes the operation_mode, (b) will trigger and update the selector\r\n\r\nHowever, what really happens is this:\r\n1. If the user changes the selector, (a) will change the operation mode. Consequentially, (b) will trigger and again update the selector.\r\n2. 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.\r\n\r\nAs 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.\r\n\r\nSo 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.\r\n\r\nIt 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.\r\n\r\nThe 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."},"comment":{"url":"https://api.github.com/repos/home-assistant/home-assistant/issues/comments/275010760","html_url":"https://github.com/home-assistant/home-assistant/issues/5491#issuecomment-275010760","issue_url":"https://api.github.com/repos/home-assistant/home-assistant/issues/5491","id":275010760,"user":{"login":"Duoxilian","id":24535446,"avatar_url":"https://avatars.githubusercontent.com/u/24535446?v=3","gravatar_id":"","url":"https://api.github.com/users/Duoxilian","html_url":"https://github.com/Duoxilian","followers_url":"https://api.github.com/users/Duoxilian/followers","following_url":"https://api.github.com/users/Duoxilian/following{/other_user}","gists_url":"https://api.github.com/users/Duoxilian/gists{/gist_id}","starred_url":"https://api.github.com/users/Duoxilian/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/Duoxilian/subscriptions","organizations_url":"https://api.github.com/users/Duoxilian/orgs","repos_url":"https://api.github.com/users/Duoxilian/repos","events_url":"https://api.github.com/users/Duoxilian/events{/privacy}","received_events_url":"https://api.github.com/users/Duoxilian/received_events","type":"User","site_admin":false},"created_at":"2017-01-25T03:38:52Z","updated_at":"2017-01-25T03:38:52Z","body":"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."}}
{"actor":{"display_login":"Duoxilian"}}