Inverted sensors for those that go to unavailable on reboot? Or different solution available?

Share your Projects!
1

So when i reboot HA, i have various (zigbee) sensors that start. For example, i have a aqara door sensor and an automation that checks if the front door is closed (closed is the trigger).

This automation (and others) seem to run when i restart. They are all zigbee sensors and the problem is they go to unavailable, then back to the old state and the automation kicks off as a result.

Now i saw this discussion about creating inverse sensors (i have below problem as well with the rain sensor (it also uses a aqara sensor) and it going to unavailable upon restart for a while), and i was wondering if i should create these inverted sensors for the other zigbee sensors as well.

Continuing the discussion from :umbrella: DIY Zigbee rain gauge:

I hope i’m making sense. Although rather then creating inverted sensors, maybe i need to change the trigger ? I guess what’s happening is that the sensor goes to unavailable, then back to the previous state (closed) and the automation runs.

Any help with this would be greatly liked :slight_smile:

2

I guess the solution for aqara zigbee sensors is to add this as a condition:

condition:
  - condition: template
    value_template: '{{ trigger.from_state.state != ''unavailable'' }}'

and for something like the quoted post an inverted sensor ?
Is that about right? The value_template condition still feels like a hack though, but i guess if my automation only triggers on state ‘closed’ and it’s coming from state ‘unavailable’ after a reboot for example, then i guess it’s correct… (but maybe there should be a button in HA somewhere to not start automations if coming from state unavailable).

3

This is happening probably because you only have to state in your automations.

Consider also adding from or even not_from.
So you will have more control over your automation conditions.

Here is an example that is in the docs…

automation:
  trigger:
    - platform: state
      entity_id: vacuum.test
      not_from:
        - "unknown"
        - "unavailable"
      to: "on"
4

I’m currently using device to trigger ‘front door closed’. So i suppose the better way would be to use state instead? That does seem to fix a lot of things indeed.

I have a battery percentage check which does the same:

type: battery_level
platform: device
device_id: 29021cd60603cca66305b701486454b8
entity_id: sensor.doorbell_battery_percentage
domain: sensor
below: 
above: 10

Could i use above: 10 in addition to below:10 to make sure it has to be above 10, and thus never triggers after a reboot? I added:

  - condition: template
    value_template: '{{ trigger.from_state.state != ''unavailable'' }}'

But i guess it never went unavailable. The other alternative i can think off is setting a condition to make sure the battery is above 10 before running it. All seems way hackier then i want to. Using state seems like a elegant solution.

5

Another alternative (what I use), would be to use a condition template for HA uptime.

condition:
  - condition: template
    value_template: >-
      {{ ((as_timestamp(now()) -
      as_timestamp(states.sensor.hassos_uptime.last_changed)) >= 5) }}
6

Oh that’s smart, i like that. That will come in handy.

7

I don’t seem to have that sensor. Where could i create or make a similar sensor ?

8
1 Like
9

Wonderful, thank you!

1 Like
10

Question: I’m using this condition now after setting up the uptime integration:

Would this be a condition of having to run for more then one minute before running the automation?