False trigger when sensor becomes unavailable

123 · April 7, 2021, 1:58pm

The behavior I described is found in this PR:

github.com/home-assistant/core

Raise ConditionError for numeric_state errors

home-assistant:dev ← amelchio:raise-condition-error

opened 09:22PM - 03 Feb 21 UTC

amelchio

+352 -63

## Proposed change This introduces a `ConditionError` exception for cases whe…re the condition helpers are unable to decide a condition. An example is when an entity is unavailable. The helpers have previously returned `False` in this situation but that is really just an arbitrary guess and a potential silent failure. As a MVP the exception is implemented for the `numeric_state` condition. With this PR, more useful logging becomes available, for example: ``` [homeassistant.components.automation] Error in 'condition' evaluation: Unknown entity sensor.front_door [homeassistant.components.automation] Error in 'condition' evaluation: Attribute 'battery_level' (of entity binary_sensor.front_door) does not exist [homeassistant.components.automation] Error in 'condition' evaluation: Template error: ZeroDivisionError: division by zero [homeassistant.components.automation] Error in 'condition' evaluation: The below entity input_number.temperature_threshold_low is not available [homeassistant.helpers.script] Error in 'choose' evaluation: Entity sensor.front_door_battery_level state 'one-hundred' cannot be processed as a number [homeassistant.helpers.script] Error in 'condition' evaluation: Unknown entity sensor.missing [homeassistant.helpers.script] Error in 'while' evaluation: Unknown entity sensor.front_door_battery_level [homeassistant.helpers.script] Error in 'until' evaluation: Template error: ZeroDivisionError: division by zero [homeassistant.components.homeassistant.triggers.numeric_state] Entity media_player.office state 'paused' cannot be processed as a number ``` This PR is actually a bit of a detour while working on home-assistant/architecture#456. Specifically, we do not want to trigger `numeric_state` when moving from true to unavailable and back to true. However, before this PR we cannot identify unavailable because it just evaluates the condition to false. ## Type of change  - [ ] Dependency upgrade - [ ] Bugfix (non-breaking change which fixes an issue) - [ ] New integration (thank you!) - [x] New feature (which adds functionality to an existing integration) - [ ] Breaking change (fix/feature causing existing functionality to break) - [ ] Code quality improvements to existing code or addition of tests ## Example entry for `configuration.yaml`:  ```yaml # Example configuration.yaml ``` ## Additional information  - This PR fixes or closes issue: - This PR is related to issue: #40331, home-assistant/architecture#456 - Link to documentation pull request: ## Checklist  - [x] The code change is tested and works locally. - [x] Local tests pass. **Your PR cannot be merged unless tests pass** - [x] There is no commented out code in this PR. - [x] I have followed the [development checklist][dev-checklist] - [x] The code has been formatted using Black (`black --fast homeassistant tests`) - [x] Tests have been added to verify that the new code works. If user exposed functionality or configuration variables are added/changed: - [ ] Documentation added/updated for [www.home-assistant.io][docs-repository] If the code communicates with devices, web services, or third-party tools: - [ ] The [manifest file][manifest-docs] has all fields filled out correctly. Updated and included derived files by running: `python3 -m script.hassfest`. - [ ] New or updated dependencies have been added to `requirements_all.txt`. Updated by running `python3 -m script.gen_requirements_all`. - [ ] Untested files have been added to `.coveragerc`. The integration reached or maintains the following [Integration Quality Scale][quality-scale]:  - [ ] No score or internal - [ ] 🥈 Silver - [ ] 🥇 Gold - [ ] 🏆 Platinum  To help with the load of incoming pull requests: - [ ] I have reviewed two other [open pull requests][prs] in this repository. [prs]: https://github.com/home-assistant/core/pulls?q=is%3Aopen+is%3Apr+-author%3A%40me+-draft%3Atrue+-label%3Awaiting-for-upstream+sort%3Acreated-desc+review%3Anone  [dev-checklist]: https://developers.home-assistant.io/docs/en/development_checklist.html [manifest-docs]: https://developers.home-assistant.io/docs/en/creating_integration_manifest.html [quality-scale]: https://developers.home-assistant.io/docs/en/next/integration_quality_scale_index.html [docs-repository]: https://github.com/home-assistant/home-assistant.io

This line:

Specifically, we do not want to trigger numeric_state when moving from true to unavailable and back to true

It was created as a result of this discussion in the Architecture repo:

github.com/home-assistant/architecture

Boolean triggers on startup

opened 10:51PM - 07 Nov 20 UTC

closed 08:11AM - 20 Feb 21 UTC

amelchio

## Context Inspired by https://github.com/home-assistant/core/issues/40331 I …would like to discuss the startup behaviour of `numeric_state` and `template` triggers. These two triggers are a bit special because they do not directly represent events but rather a Boolean value. They trigger when the Boolean value turns true. So what happens if the value is already true at startup? Nothing currently happens _at startup_ because automations are disabled at startup. However, once the first relevant state change happens, the trigger is evaluated. If it is still true, _then_ it fires. This is the example from the issue. ```yaml - alias: 'Switch on lights at night' trigger: - platform: numeric_state entity_id: sun.sun value_template: "{{ state.attributes.elevation }}" below: 3.0 action: - service: switch.turn_on entity_id: group.plugs_auto ``` If Home Assistant is restarted at night, this will turn on the lights maybe half an hour later (because `sun.sun` rarely updates during the night). That is generally unexpected and undesired. Here is another example that will fire the first time light brightness is changed after startup (if the light is on during the restart); ```yaml - alias: 'Log office light turning on' trigger: - platform: template value_template: '{{ states("light.office") == "on" }}' action: - service: system_log.write data: message: 'The office light is now on' ``` After that first firing, brightness changes will never again affect the template. ## Proposal I propose that these two triggers should only fire when going from false to true. They should not fire if already true at startup. They should not fire if going from true to unavailable and back to true. Full disclosure: I actually implemented the current behavior for `numeric_state` (in https://github.com/home-assistant/core/pull/10125). I was in doubt about how to handle it back then and I now think I did it the wrong way around (even though everybody agreed with me). ## Consequences The main potential benefit is that lights and other stuff would no longer toggle for every restart. This is a breaking change but I struggle to think of examples where the current behavior is desirable (please help). One situation is testing though: when implementing the above automation it is nice that one does not have to wait for the next sunset to see that it works. If one really wants the current behavior it can be implemented with a `homeassistant` start trigger combined with a condition. CC: @aaronwolen @Tom7320 @stefanroelofs (from the mentioned issues)

However, I think it was superseded by another PR:

github.com/home-assistant/core

Don't raise on known non-matching states in numeric state condition

home-assistant:dev ← home-assistant:frenck-2021-0784

opened 03:41PM - 04 Mar 21 UTC

frenck

+48 -106

## Proposed change  The numeric state condition should not raise on unavailable or unknown states. These are known states defined in our model. It are valid states, the entity exists as well, just not a matching one (for whatever reason). Introduced in #45923 ## Case 1 **Senario before this PR:** - Entity available, condition matches -> trigger - Entity becomes unavailable - Entity becomes available again -> condition matches -> NO trigger **Senario after:** - Entity available, condition matches -> trigger - Entity becomes unavailable - Entity becomes available again -> condition matches -> trigger The difference is in the trigger after the state becomes known or available again. It would trigger if it matches at that point. The main reason: We don't know the state in between and should not assume that either. ## Case 2 **Senario before this PR:** - Home Assistant starts up, does not have a known state yet (battery-powered?) - Entity becomes available again -> condition matches -> NO trigger **Senario after:** - Home Assistant starts up, does not have a known state yet (battery-powered?) - Entity becomes available again -> condition matches -> trigger The difference is in the trigger after the state becomes known or available again. It would trigger if it matches at that point. The main reason: We don't know the state in between and should not assume that either. ## Case 3 A condition can be unavailable/unknown at any time. This is part of our core state engine model. If an entity becomes unavailable/unknown, the numeric state condition would never match. **Situation before this change:** An warning is logged. ![image](https://user-images.githubusercontent.com/195327/109988795-2cd06f80-7d08-11eb-8b4e-769a77a532e9.png) **Situation after:** The condition doesn't match and returns `False`, not log is made. The reasoning for this; is that it is a valid and known state that never matches. It is not up to automation to log/warn about known states that never match. If we want warnings/alerts/logs about devices being in an unknown or unavailable state, that should be handled by something else (e.g., the state engine, not automations). See: #47368 As a final word; even if the created situation is the wanted one (which I highly doubt), it should have been marked as breaking change. As this changes the behavior. ## Type of change  - [ ] Dependency upgrade - [x] Bugfix (non-breaking change which fixes an issue) - [ ] New integration (thank you!) - [ ] New feature (which adds functionality to an existing integration) - [ ] Breaking change (fix/feature causing existing functionality to break) - [ ] Code quality improvements to existing code or addition of tests ## Additional information  - This PR fixes or closes issue: fixes #47368 - This PR is related to issue: - Link to documentation pull request: ## Checklist  - [x] The code change is tested and works locally. - [x] Local tests pass. **Your PR cannot be merged unless tests pass** - [x] There is no commented out code in this PR. - [x] I have followed the [development checklist][dev-checklist] - [x] The code has been formatted using Black (`black --fast homeassistant tests`) - [x] Tests have been added to verify that the new code works. If user exposed functionality or configuration variables are added/changed: - [ ] Documentation added/updated for [www.home-assistant.io][docs-repository] If the code communicates with devices, web services, or third-party tools: - [ ] The [manifest file][manifest-docs] has all fields filled out correctly. Updated and included derived files by running: `python3 -m script.hassfest`. - [ ] New or updated dependencies have been added to `requirements_all.txt`. Updated by running `python3 -m script.gen_requirements_all`. - [ ] Untested files have been added to `.coveragerc`. The integration reached or maintains the following [Integration Quality Scale][quality-scale]:  - [x] No score or internal - [ ] 🥈 Silver - [ ] 🥇 Gold - [ ] 🏆 Platinum  To help with the load of incoming pull requests: - [x] I have reviewed two other [open pull requests][prs] in this repository. [prs]: https://github.com/home-assistant/core/pulls?q=is%3Aopen+is%3Apr+-author%3A%40me+-draft%3Atrue+-label%3Awaiting-for-upstream+sort%3Acreated-desc+review%3Anone  [dev-checklist]: https://developers.home-assistant.io/docs/en/development_checklist.html [manifest-docs]: https://developers.home-assistant.io/docs/en/creating_integration_manifest.html [quality-scale]: https://developers.home-assistant.io/docs/en/next/integration_quality_scale_index.html [docs-repository]: https://github.com/home-assistant/home-assistant.io

It appears to introduce the behavior you observed:

Entity available, condition matches → trigger

Entity becomes unavailable

Entity becomes available again → condition matches → trigger