Automation UI needs an option to ignore unexpected triggers when state changes from or to "unavailable" or "unknown"

[fuslwusl]

A checkbox is required in the automation UI to prevent unexpected triggers when state changes from or to “unknown” or “unavailable”.

Example: Toggle light when switch state changes
Using the great UI automation editor you would usually add a Trigger “State” and select the entity “Bathroom light switch” and the Action “Call Service” and select “Light Toggle” with the entity “Bathroom lamp”.
This trigger only works as expected when the state changes from “on” to “off” or “off” to “on”.
But you wouldn’t usually expect that the lamp will also switch on a restart of homeassistant or when the “Bathroom light switch” changes from “unknown” or “unavailable” to “off”.

My suggestion is to add a checkbox that will prevent those unexpected triggers.
This checkbox could be default for new automations and experts can uncheck to trigger on “unknown” or “unavailable” states.

Here is what the UI automation editor will create as yaml:

alias: Toggle light when switch state changes
description: Unexpected behavior because automation will also trigger on state changes from or to "unknown" or "unavailable"
mode: single
trigger:
  - platform: state
    entity_id:
      - binary_sensor.bathroom_light_switch
action:
  - service: light.toggle
    data: {}
    target:
      entity_id: light.bathroom
mode: single

If you want the expected behavior to trigger only on changes between “on” and “off” you need a workaround.

As a workaround in the UI you can make sure that only on/off state changes trigger by adding two triggers:

alias: Toggle light when switch state changes
description: Unexpected behavior because automation will also trigger on state changes from or to "unknown" or "unavailable"
mode: single
trigger:
  - platform: state
    entity_id:
      - binary_sensor.bathroom_light_switch
    from: "off"
    to: "on"
  - platform: state
    entity_id:
      - binary_sensor.bathroom_light_switch
    from: "on"
    to: "off"
action:
  - service: light.toggle
    data: {}
    target:
      entity_id: light.bathroom
mode: single

Another workaround is a condition to check for unwanted changes:

alias: Toggle light when switch state changes
trigger:
  - platform: state
    entity_id:
      - binary_sensor.bathroom_light_switch
condition:
  - "{{ trigger.from_state.state not in ['unknown', 'unavailable'] }}"
  - "{{ trigger.to_state.state not in ['unknown', 'unavailable'] }}"
  - "{{ trigger.from_state.state != trigger.to_state.state}}"
action:
  - service: light.toggle
    data: {}
    target:
      entity_id: light.bathroom
mode: single

A checkbox in the UI to prevent this unexpected behavior will help users to quickly reach their automation goals.

Thanx to the developers for this great work and this great UI editor for automations.
Would be great to see this feature in future releases.

[tom_l]

@fuslwusl

trigger:
  - platform: state
    entity_id:
      - binary_sensor.bathroom_light_switch
    from: "off"
    to: "on"
  - platform: state
    entity_id:
      - binary_sensor.bathroom_light_switch
    from: "on"
    to: "off"

Neither of those will trigger on an unknown or unavailable state. They will only trigger when changing off → on and on → off respectively.

[finity]

Yes, you have it exactly backwards.

the only time it will unexpectedly trigger from a state of unknown or unavailable to off or on is if the from state isn’t specified.

once you specify the from and to states it will only trigger when transitioning between those two defined states and no others.

[CentralCommand (Mike)]

trigger:
  - platform: state
    entity_id:
      - binary_sensor.bathroom_light_switch
    from: ["off", "on"]
    to: ["off", "on"]

This works fine, usually what I use. Or for sensors which aren’t binary:

trigger:
  - platform: state
    entity_id:
      - sensor.some_sensor
    not_from: ["unavailable", "unknown"]
    not_to: ["unavailable", "unknown"]

But still, checkboxes would be nicer.

[fuslwusl]

You are right - this code is the workaround. I changed the code in my example to what you will usually get when using the UI. This is the version that creates the unexpected behavior because a user usually doesn’t think of edge cases like “unknown” or “unavailable” states to trigger automations.

[fuslwusl]

That is exactly the reason why a checkbox in the UI to prevent unexpected triggers will be very useful. So users do not have to edit yaml to just get the expected behavior. I updated the UI example - there you can see that UI created rules will trigger in situations the user doesn’t expect.

[123 (Taras)]

@fuslwusl

in situations the user doesn’t expect.

unavailable and unknown are legitimate values for a binary_sensor (and other entities) just as much as on and off. They indicate non-nominal behavior.

[fuslwusl]

@CentralCommand

trigger:
  - platform: state
    entity_id:
      - binary_sensor.bathroom_light_switch
    from: ["off", "on"]
    to: ["off", "on"]

This works fine, usually what I use. Or for sensors which aren’t binary:

trigger:
  - platform: state
    entity_id:
      - sensor.some_sensor
    not_from: ["unavailable", "unknown"]
    not_to: ["unavailable", "unknown"]

But still, checkboxes would be nicer.

I tried [“off”, “on”] like you wrote in the UI - the result was this:

    from: "[\"off\", \"on\"]"
    to: "[\"off\", \"on\"]"

Then I tired [‘off’, ‘on’] and this worked - the result was this:

from:
  - "off"
  - "on"
to:
  - "off"
  - "on"

So the UI editor creates the correct code but i think when you have to exclude edge cases with a very simple trigger and you also have to care what kind of quotation marks to use - this is not what a regular user needs. Of course a developer is able to get the right solution - but automation should be as easy as possible and get results you usually expect.

Nearly all my rules could be done in the UI if there was a checkbox to ignore these unexpected states in the automation builder UI.

[fuslwusl]

@123

@fuslwusl

in situations the user doesn’t expect.

unavailable and unknown are legitimate values for a binary_sensor (and other entities) just as much as on and off. They indicate non-nominal behavior.

Of course there are cases you want to trigger on state “unavailable” or “unknown” - but I think the regular use case is:
“when i press a button do something”
And you should not have to spend more time on finding ways to prevent the system from triggering on “internal” states.

In the UI there is no easy way to trigger only on state change between on or off - what is the regular use case in my opinion. For this you need workarounds that require yaml code or duplicate triggers both set with the UI fields from and to set the correct way.

It will be very helpful for all users when this kind of often used trigger can be done with a lot less clicking and duplication and without yaml.

Adding multiple states in the from and to fields could possibly be a first step to avoid yaml and duplicate triggers.

[123 (Taras)]

@fuslwusl

the regular use case is:
“when i press a button do something”

That’s why Device Triggers/Conditions/Actions were invented. They were specifically created for use (indirectly) by novices who wish to create an automation for a device. After making selections from a menu it generates an automation (containing Device Triggers/Conditions/Actions).

@fuslwusl

finding ways to prevent the system from triggering on “internal” states.

unknown, unavailable aren’t “internal” ; you’re making a distinction where none exists.

on, off, unknown, unavailable are all legitimate states for a binary_sensor (and input_boolean)

@fuslwusl

In the UI there is no easy way to trigger only on state change between on or off

If you mean the Automation Editor does not currently provide a visual means of selecting more than one state for the from or to options then I agree. Currently, it’s limited to selecting one value from a dropdown list (see image above). Ideally it should permit selecting multiple values from the list.

[CentralCommand (Mike)]

@123

unknown, unavailable aren’t “internal” ; you’re making a distinction where none exists.

I don’t actually agree. I think “internal” is the wrong word but I think the author’s point is valid personally. It’s not that you shouldn’t be able to see when entities are in these states or write automations for them, its that you’re writing an entirely different set of automations to handle them. Or at least an entirely different path through the action piece of your automation if you prefer to make fewer larger automations then many smaller ones.

I mean if I look at my own automations I have this kind of logic everywhere:

@CentralCommand

trigger:
  - platform: state
    entity_id:
      - binary_sensor.bathroom_light_switch
    from: ["off", "on"]
    to: ["off", "on"]

This works fine, usually what I use. Or for sensors which aren’t binary:

trigger:
  - platform: state
    entity_id:
      - sensor.some_sensor
    not_from: ["unavailable", "unknown"]
    not_to: ["unavailable", "unknown"]

Which is functional I guess but wouldn’t it be nice to reduce the boilerplate? It’s certainly more common for me to want to ignore transitions to and from these states then use them. When I use them is isolated to a select few extremely generic automations that tell me when specific entities have entered one of these states. They only cause problems in a vast majority of mine.

Also I think the biggest selling point here personally is startup. If you have entities which don’t restore state (like MQTT for example, to pick a common one) then these states create frustration. Because those entities restore to unknown and then transition to a valid state next time they receive an update from their integration. This form of unknown state is truly internal IMO and shouldn’t trigger automations. There is absolutely nothing wrong with the entity. The integration did not receive invalid input or lose contact with a device or anything that would require attention. It’s simply a technical detail of how HA startup works.

Perhaps if it was changed how the first transition after startup worked for entities which don’t restore state that would be fine. Since generally in other cases when an entity transitions to unavailable or unknown a user probably wants to know about it so a logged error could be helpful.

[123 (Taras)]

@CentralCommand

wouldn’t it be nice to reduce the boilerplate?

The YAML version of the automation represents exactly how the automation should behave so it must contain the desired states to be monitored (or ignored). The FR’s proposed checkbox can’t override this requirement (without employing a significant change described below). At best the checkbox can serve to make the Automation Editor automatically populate the automation’s trigger with the appropriate state values. However, those values will appear in YAML and, because the UI reflects what’s in YAML, in the UI as well. So in this approach, there’s no reduction of “boilerplate” and only an improvement in “ease of use”.

To completely hide the “non-nominal” states from view, the checkbox would need to set some sort of new option, perhaps nominal: true where the default is false, that effectively makes the State Trigger employ only the entity’s “nominal” state values (i.e. on and off).

Examples

Currently, this State Trigger will trigger when there’s a state-change from several states to several other states (including changes to attribute values).

  - platform: state
    entity_id: binary_sensor.whatever

Currently, this State Trigger will trigger when there’s a state-change from several states to several other states (but not changes to attribute values).

  - platform: state
    entity_id: binary_sensor.whatever
    to:

Currently, this State Trigger will trigger from a state-change from several states to exclusively on.

  - platform: state
    entity_id: binary_sensor.whatever
    to: 'on'

Proposal: this State Trigger triggers only from off to on or on to off (but not changes to attributes).

  - platform: state
    entity_id: binary_sensor.whatever
    to:
    nominal: true

Proposal: this State Trigger triggers only from off to on.

  - platform: state
    entity_id: binary_sensor.whatever
    to: 'on'
    nominal: true

However, this represents a significant change in how Home Assistant converts automations defined in YAML into python. In other words, the conversion of the trigger definition must now take into account the nominal option and it requires an understanding of what represent a given entity’s nominal values. I’m not sure if there’s even an internal library of valid entity values let alone the nominal ones. Although something must exists somewhere because the revised Automation Editor now displays a dropdown of valid values (but it may only be a resource available to the frontend; I don’t know).

Long story short, I would support the concept of a nomimal option but whoever attempts to implement it would probably need to run it by the development team (in Architecture/Discussions) because it’s a non-trivial change to Home Assistant.

[fuslwusl]

Thanx for your great explanations!
Your nominal setting is exactly what i meant with checkbox.
But the direction of homeassistant goes more and more towards UI so the generated yaml code doesn’t have to be more readable.

Mike posted this yaml way of ignoring state changes from and to “unavailable” and “unknown”:

trigger:
  - platform: state
    entity_id:
      - sensor.some_sensor
    not_from: ["unavailable", "unknown"]
    not_to: ["unavailable", "unknown"]

Adding a checkbox for example named Ignore states “unavailable” or “unknown” in the UI could be used to just add the following yaml code:

    not_from: ["unavailable", "unknown"]
    not_to: ["unavailable", "unknown"]

If exactly this code is found in yaml it could be shown in the UI as Ignore states “unavailable” or "unknown"
This would not require changes of the yaml structure.

What do you guys think of this solution?

[123 (Taras)]

@fuslwusl

Adding a checkbox for example named Ignore states “unavailable” or “unknown” in the UI could be used to just add the following yaml code:

    not_from: ["unavailable", "unknown"]
    not_to: ["unavailable", "unknown"]

Currently there’s no support for the not_to and not_from options in visual mode. If you add them in YAML mode and then switch to visual mode, they will remain displayed as YAML. So it’s more than just adding a checkbox, it’s also adding support for displaying more options in visual mode (something the developers have tried to limit in order to save screen space and avoid overwhelming a novice user with a myriad of options).

A workable alternative is what I described earlier: provide support for multiple selections in dropdown menus so the user can select multiple values for from and to.

The Automation Editor in visual mode is simply a “YAML generator”. Whatever you select from various dropdown menus is just a means to produce YAML because that’s what is ultimately stored and converted into python. Visual mode doesn’t have a visual representation for all of Home Assistant’s scripting language features. What it cannot display, using some sort of UI widget, is displayed as YAML.

Historically, the Automation Editor has received few improvements and I attribute that to a lack of interest from developers … and it can be a thankless task. The recent improvements made are the most significant in many years. I call them improvements but some users have been vocal in their dislike for them, going as far as to attack the individuals responsible for the changes. I doubt that kind of feedback attracts more developers to work on the Automation Editor.

[fuslwusl]

@123

A workable alternative is what I described earlier: provide support for multiple selections in dropdown menus so the user can select multiple values for from and to.

Thanx for your feedback! I think multiple values separated with comma in those dropdowns would help a lot. The best solution would be a multiselect dropdown with autocomplete to allow easy selection of multiple entries very quickly. Here is an example: JQuery Form With Autocomplete and MultiSelect

I really hope that a developer integrates such a great feature. This would make the UI automation editor even better.

[fuslwusl]

@123

Historically, the Automation Editor has received few improvements and I attribute that to a lack of interest from developers … and it can be a thankless task. The recent improvements made are the most significant in many years. I call them improvements but some users have been vocal in their dislike for them, going as far as to attack the individuals responsible for the changes. I doubt that kind of feedback attracts more developers to work on the Automation Editor.

I am still very impressed of these great new features of the UI editor and the last updates. Nearly all my rules are built with it and only some special stuff had to be edited in yaml. I like it a lot that you can change the view of parts of the automation to yaml mode and leave the rest UI editable. What a great concept! I cannot understand that someone doesn’t like this great automation editor. I am so much faster in creating new rules than with creating yaml and you never run into annoying yaml problems with options and correct hierarchy. Of course there are still many features on the wish list - but the last update were a big jump in the right direction and i hope this will go on. For complicated rules a user has the possibility to switch to yaml anytime.
Thanx a lot to all developers of this great editor!!! Keep on this direction.

[fuslwusl]

@123

That’s why Device Triggers/Conditions/Actions were invented. They were specifically created for use (indirectly) by novices who wish to create an automation for a device. After making selections from a menu it generates an automation (containing Device Triggers/Conditions/Actions).

Thanx for this info - I didn’t know that this was possible.

[wernervriel (werner)]

This morning a woke up to soon because the light turned on. This was because the switch wend to unavaible.

So yes i like to see this option in it.
my switch has 3options one press, double press and long press.
hope whit next part of the code it wont happen again

• “{{ trigger.from_state.state not in [‘unknown’, ‘unavailable’] }}”
• “{{ trigger.to_state.state not in [‘unknown’, ‘unavailable’] }}”
• “{{ trigger.from_state.state != trigger.to_state.state}}”

[diletone]

I have put together a system to support a fully automated grow tent. Lighting is a huge factor in the overall yield, specifically the absense of it. I recently lost an entire harvest due to this issue causing the growlights to come on randomly in the middle of the night. Because they are in a tent, the issue went unnoticed for a week. Needless to say I too think this is a no brainer.

[hassiopi]

I ran into a similar problem when using a helper button to trigger the garage door opener button (controlled by a shelly1 relay). The button is stateless, so I can’t check for “on/off”. But when I disabled the button, it triggered the automation so the garage door opens or closes. How to I check for a “valid” button press?