Avoid writing tons of automations to 'fix' from unavailable?

1

I have a few automation scripts, that rely on zigbee/esphome devices. Sometimes, such a devices sadly becomes unavailable (especially battery powered zigbee devices :frowning: …)

When these do become available, they either cause incorrect automation triggers (state whent from unavailable to ‘heating’ for example, where it was heating before already, or worse, the actuator wasn’t available, during the trigger, and now does something ‘old’.

Of course this can be fixed by writing tons of automations, e.g. ‘if devices becomes available again, check the state again, and see if you where supposed to be triggered on or off’, which basically means we have the normal script with the happy flow (e.g. a thermostat tells a boiler to turn on) but also an unhappy automation (the boiler checks uppon return what the thermostat state was).

Is there any way to avoid all of this, or is this just ‘life’ and the only way to deal with this is writing really good blueprints …?

2

Just be strict in your automation triggers. Instead of

triggers:
  - trigger: state
    entity_id: binary_sensor.foobar
    to: 'on'

Make sure you specify the from state as well.

triggers:
  - trigger: state
    entity_id: binary_sensor.foobar
    from: 'off'
    to: 'on'

For numeric state triggers where you trigger on all states you can use the not_from option:

triggers:
  - trigger: numeric_state
    entity_id: sensor.foobar
    not_from:
      - unavailable
      - unknown
3

Thanks @tom_l

I think the not_from is currently not available in the UI is it? (or it wasn’t on my phone)

But that only helps with half of the problem, and potentially introduces new ones. E.g. the state could be from: off OR from: idle or from: cool (potentially :p) or … well many other states.

The other half is that the actuator becomes available again, still means I have to write a unhappy flow automation …

4

Possibly, I only use YAML.

That is when you use either a list of states

triggers:
  - trigger: numeric_state
    entity_id: sensor.foobar
    from:
      - idle
      - cool
      - etc...

or not_from

I have no idea what you mean by this.