Switch for ignoring "Unavailable" in conditions

Feature Requests
1

Hi,

I have a condition looking like this:

condition: state
entity_id: switch.kellerlueftung_motor
state: 'on'
for: '02:00:00'

So the motor should be turned of after running 2 hours. Unfortunately it often is not, because the sensor is occasionally unavailable due to bad wifi connection.

An action with a delay is another way to get the wanted behavior, but is less reliable, because e.g. if I restart HA in between, the motor is never turned off.

Request:
Add an option for conditions to ignore the “unavailabe” state of a list of defined states.

Something like:

ignore_states: 
  - "unavailable"
  - "foo"
2

Then you should fix that instead of creating a workaround.

The same goes for your automation, when you restart HA in between it will also not work.

3

Quick and dirty solution

trigger:
  platform: template
  value_template: "{{ is_state('switch.kellerlueftung_motor', 'on') or is_state('switch.kellerlueftung_motor', 'unavailable') }}"
  for:
    hours: 2
1 Like
4

I use defined transitions (off to on) to avoid this.

trigger:
  - platform: state
    entity_id: switch.kellerlueftung_motor
    from: 'off'
    to: 'on'
    for:
      hours: 2
5

This doesn’t solve OPs request. OP has the problem that his switch is unavailable sometimes, but he wants to ignore it. Your code will not work for him as it would only teigger when the state is on for 2 hours, but not if it was unavailable inbetween.

6

That doesn’t fix the problem. If you turn the switch on, then it goes unavailable, then becomes available (states go off, on, unavailable, on) then it won’t fire the automation because the state change was unavailable to on, not off to on.

Edit - Ugh, ninja’d :wink:

7

@Burningstone
Even assuming to have a perfect wifi connection is not a realiable way to solve this. Wifi will always have some hickups, by whatever reasons. Unavailability occasionally should not break automations in my opinion, since it can always happen. (in general, not only wifi)

Second, the solution with the condition WOULD work if I restart HA in between, in fact, it already has. It ran more than 2h, but at least turned off eventually. The only thing remaining, which would make it a truly robust solution, is the issue with the unavailable state.

@anon43302295
Thanks, I also found this template solutions, which fixes it, and I will use it. I just think it would be a nice feature to have this states_ignored list for convenience. I think it should be a quite common use case and templating is not for everyone.

1 Like
8

It’s a (little) bit more involved but for this specific case you can also start a timer (instead of using for) when it turns on and have an automation to turn it off when the timer expires. It will also cover the restart scenario if you turn on the timer from any other state to on and check that it’s not already running. So, two automations instead of one.

1 Like
9

Sometimes, this isn’t realistic. For example, my Tesla becomes ‘unavailable’ when it is applying a software update. Because of this, I get false triggers of my automation that detects when it has been plugged/unplugged to/from a charger because I have it just looking for any change of state or when the state changes to “on” or “off”.

What I have been forced to do is create triggers for the state changing from off to on, or from on to off (to filter out transitions from on to unavailable and back to on, say). But then this has a flaw, because it won’t catch a state change that happens while the device is unavailable (for example, the car is on the charger, it goes unavailable for a software update, I take the car off the charger, and then the update finishes. States will be “on”->“unavailable”->“off” and my automation won’t trigger because it never sees “on”->“off”).

This problem reminds me of the problem of “null” in many programming languages, where what it is supposed to mean is that no value is available, but many programs mistakenly use it as a value. It could be argued that available vs unavailable should have been a separate entity, not in the domain of values that a normal state entity would be, and maybe trying to fetch the state of something which is unavailable would throw an exception or something. But, it’s too late to go back and redesign it.

My best idea for a workaround would be the option to either flag an entire entity as unavailable-ignoring (where any trigger using that entity will be based upon value transitions omitting “unavailable”, so “on”->“unavailable”->“off” would be seen as “on”->“off” and “on”->“unavailable”->“on” would be seen as no transition at all), or, instead of flagging an entire entity to work like that, you could flag individual automations or individual triggers to unavailable-ignoring. Maybe something for a WTH feature request.

10

State changes are from one state to another. Your example represents two state-changes and neither is from on to off (which means it won’t activate a State Trigger listening for on → off).

You can create a State Trigger that detects changes to/from unavailable and handle those state-changes as you see fit.

unavailable is a legitimate state value for all entities and represents Home Assistant’s inability to acquire the entity’s actual state at that moment in time (typically due to loss of connectivity). It’s a ‘non-nominal’ state, useful for triggering automations designed to detect operational anomalies.

Another ‘non-nominal’ state value is unknown. It’s typically reported when a state value must be calculated but hasn’t been calculated yet. For example, a Trigger-based Template Sensor will report unknown if it has never been triggered yet.

11

I admit that, in HA, it’s a legitimate state value, but, in type theory, unavailable is describing something different from temperature/humidity/luminosity/etc, and, by using the same entity_id (as, say, the temperature reported by a sensor) for holding unavailable, HA is changing the type of the data. The evidence for this is in all of the lines of code which have to check to see if a state is unavailable or unknown before trying to do any math or quantitative comparison (like > or <) on, what would otherwise be, a numerical state value. Regardless, whether we say that unavailable belongs in state values is a moot point. It’s there, and we have to deal with it. Which brings me to…

I realize that, but what I want is to ignore unavailable for the purposes of recognizing state changes. To illustrate my point, write me a trigger which fires when binary_sensor.car_charger_charging sees either of the following transitions:

  • “off” → “on”
  • “off” → “unavailable” → “on” (user plugged in the car during a software update or the wifi was down, or whatever)

I do not want it to trigger just on “unavailable” → “on” because the charger might have already been charging (i.e. the “unavailable” → “on” might be the last transition in a “on” → “unavailable” → “on” sequence, and I do not want my automation to trigger if the car is already charging) so the prior transition matters.

I know it can be done with a toggle helper and and either two more automations or a single automation with a template, but I think that’s quite a hassle to do for every automation which involves an entity which can experience an unavailable (which means any wired device which could experience a power outage or any non-wired device which could need a battery replaced or any device which becomes unresponsive during a firmware update… which is pretty much everything in my house)

12

It can be done with a single automation and no helpers.

alias: example
trigger:
  - platform: state
    entity_id: binary_sensor.foo
    from: 'off'
    to:
      - 'on'
      - 'unavailable'
condition: []
  - if: "{{ trigger.to_state.state == 'unavailable' }}"
    then:
      - wait_for_trigger:
          - platform: state
            entity_id: binary_sensor.foo
            from: 'unavailable'
            to: 'on'
        timeout:
           minutes: 5
    continue_on_timeout: false
  - ... etc ...
2 Likes
13

I’m probably late to the party, but you can just check if the device is NOT ON. If your device only has two states (on/off) and in some cases “unavailable”, you can simply check if it’s not on