State 'unavailable' complicates (shelly) automations

Configuration
1

Good morning from someone who’s bedroom lights turned on last night at 3:50 o’clock. But let me explain:

I have various Shelly switches throughout the house and I have learned that for a switch, there are generally 3 states to be considered in automations:

  • on
  • off
  • unavailable

‘Unavailable’ will happen from time to time due to wifi stability. It’s short but it will still trigger something if I do my automations like that:

Using Device → Turned On (or Off):

type: turned_on
platform: device
device_id: cf732....
entity_id: binary_sensor.bedroom_shelly_switch
domain: binary_sensor

Using state:

platform: state
entity_id:
  - binary_sensor.bedroom_shelly_switch
to: "on"

Or even using state without options (most elegant):

platform: state
entity_id:
  - binary_sensor.bedroom_shelly_switch

But unfortunately all these will trigger when the switch comes back from ‘unavailable’ and not only when changing between ‘on’ and ‘off’.

So I have to do all triggers like that:

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

And usually another one for on → off.

My question is, is there an elegant way to ignore that ‘unavailable’ state?

Thanks,
Kai

1 Like
2

Hi. I have something similar and use this to exclude unavailable state:

condition:
  - condition: template
    value_template: >-
      {{ trigger.from_state.state | float(default=8) >= 8.5 and
      trigger.from_state.state != "unavailable" }}

The numbers are for temperature, and the "trigger.from_state.state != "unavailable" with "!=" means that it should not trigger if state.from.state is unavailable.

1 Like
3

Ah, nice! So I could just filter “unavailable” for trigger.from_state and trigger.to_state and then I could even use the shortest form:

trigger:
  - platform: state
    entity_id:
      - binary_sensor.bedroom_shelly_switch
condition:
  - condition: template
    value_template: >-
      {{ trigger.to_state.state != "unavailable" and
      trigger.from_state.state != "unavailable" }}
4

Yup. You can look at the tracing menu and use several different variables for other types of automations as well.

1 Like
5

unavailable and unknown are legitimate state values. They’re not what one would call nominal states like on or off because they report problems encountered while attempting to communicate with the device.

If you don’t want to to trigger on state-changes to/from non-nominal states, simply constrain the State Trigger to listen for nominal states. In other words, exactly in the way shown in your example:

platform: state
entity_id: binary_sensor.bedroom_shelly_switch
from: "off"
to: "on"

You can also use not_from or not_to (for situations where you want to be very specific):

platform: state
entity_id: binary_sensor.bedroom_shelly_switch
not_from: "unavailable"

Reference: State Trigger

I wouldn’t use the Template Condition example you posted (employing the trigger variable to check the binary_sensor’s previous and current states) simply because it’s a long-winded way of achieving what a State Trigger’s to and from options do very concisely.

1 Like
6

Interesting - I didn’t know “not_from” and “not_to” so far. My most often wanted usecase is to capture when the switch is being toggled and so I would need 2 triggers (which I want to avoid):

# trigger1
platform: state
entity_id: binary_sensor.bedroom_shelly_switch
from: "off"
to: "on"

# trigger2
platform: state
entity_id: binary_sensor.bedroom_shelly_switch
from: "on"
to: "off"

But given the not-condition I could probably do this:

platform: state
entity_id: binary_sensor.bedroom_shelly_switch
not_from: "unavailable"
not_to: "unavailable"

…in only one trigger which would be the cleanest way (if it works).

7

I’ve used various variables in templates before but it never occurred to m e that the trace provides a convenient list of available variables. Will use that! :+1:t3:

8

In my automations, here’s I achieve it with one State Trigger:

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

It triggers exclusively for state-changes on → off and off → on.

You can write it like this to make the desired state-changes clearer but the order of the items in the list isn’t critical.

platform: state
entity_id: binary_sensor.bedroom_shelly_switch
from:
  - "off"
  - "on"
to:
  - "on"
  - "off"
1 Like
9

Damn it - you can put a list there?? Awesome. That will come in handy at other places! Thx!
Now if only the graphical editor would support it (but it doesn’t support “not_from” and “not_to” as well, so that doesn’t matter)

10

Refer to the second example (showing the use of a list) in the documentation for State Trigger.

For future reference, the Automation Editor, in visual mode, is meant for novices. It’s been improved a great deal but it doesn’t offer access to all features available in Home Assistant’s scripting language. I imagine what is/isn’t shown in visual mode may be driven by a desire to avoid overwhelming the user with too many choices and to display only the most common features (i.e. don’t display advanced scripting features).

1 Like