Is it possible to delay an action until daylight?

Configuration
1

I was thinking of adding an automation for important sensors (e.g. water leak) to make sure that they are functional. Since sometimes there are glitches in the Zigbee network, I figured a “for 8h” (or maybe even “for 2d”) would be reasonable.

Similarly, there’s no point in creating a notification in the middle of the night when it might wake someone up. My understanding, though, is that it’ll trigger only once (8h after the condition starts) which means that if the 8h mark occurs during the night and there is a “daytime only” condition then the action will never get executed.

Is there any way to create a “trigger when state == ‘unavailable’ for 8h or more and it’s between 10am and 8pm” automation?

– Brian

2

Automation with a state trigger with for: '08:00:00' and a time condition, and a time trigger and state condition.


- alias: Notify when sensor unavailable
  initial_state: true
  trigger:
  - platform: state
    entity_id: binary_sensor.whatever
    to: 'unavailable'
    for: '08:00:00'
  - platform: time
    at: '06:00:00'
  condition:
  - condition: time
    after: '06:00:00'
    before: '23:00:00'
  - condition: state
    entity_id: binary_sensor.whatever
    state: 'unavailable'
    for: '08:00:00'
  action:
  ...

Customize the times to your needs of course.

3

Ah, I see. Two “or” triggers (sensor & time) plus the same in a condition. Makes sense. Thanks.

If others are looking at this, not all of those options are available in UI so you’ll have to go to the three-dots menu and “edit as yaml”.

4

Problem: “for” is not accepted in the condition.

Message malformed: extra keys not allowed @ data['condition'][1]['for']

5

“for” is definitely accepted there. Maybe post the YAML of your automation as it exists (with the error) and we can spot what’s wrong.

EDIT: Oops, thought you said numeric_state trigger.

6

I’m creating it through the UI and editing the condition’s YAML. Is it just the UI refusing it?

condition: numeric_state
entity_id: sensor.unavailable_entities
above: '0'
for: 3600
7

Here’s the minimum I could find that shows the error:

- id: '1594600164166'
  alias: Important sensor is unavailable.
  description: ''
  trigger:
  - above: '0'
    entity_id: sensor.unavailable_entities
    for: 08:00:00
    platform: numeric_state
  condition:
  - above: '0'
    condition: numeric_state
    entity_id: sensor.unavailable_entities
    for: 3600
  action:
  - data:
      message: Important device is unavailable.
      title: Home Assistant
    service: notify.brian_hangout

When I do a “check configuration”, it says:

Invalid config for [automation]: [for] is an invalid option for [automation]. Check: automation->condition->0->for. (See /config/configuration.yaml, line 115).

8

You can’t use for: with a numeric state condition. You could make a template binary sensor that’s on when 1 or more entities is unavailable and use that in a state condition though.

9

Ah, you said condition, not trigger. I need to clean my glasses! Sorry, that’s true. You can use it with a state condition, a state trigger, or a numeric_state trigger, but you can’t use it with a numeric_state condition.

10

Got it. Presumably because with a “binary” sensor it can easily look back in the state history to determine whether the “for” is satisfied.

Works now! Thanks.

11

Actually it’s slightly more complicated than that. For triggers, after the criteria is initially met, it monitors the entity/entities for the “for” period to see if they change such that the criteria is no longer met. As long as it continues to be met for the entire period, it triggers.

But for conditions, it doesn’t look at the entity’s history, it only looks at the state’s last_changed field. For state conditions, if the difference between that and the current time is longer than the “for” period, then it knows it must have been in that state for long enough. But for a numeric_state condition, although it could determine that the state hasn’t changed during the period, it’s also possible for the state to have changed, but still met the criteria (e.g., the criteria is above 3, and it changed from 4 to 5.) So it can’t be sure, just by looking at last_changed, whether or not the criteria was or wasn’t met for the entire “for” period. Hence it can’t be done (at least that way.)