How to implement STATE-based (as oppposed to EVENT-based) automation?

Configuration
21

As @fantangelo alludes the issue could just be timing, but I would address it a little differently:

...
condition:
  - or:
      - condition: time
        after: "09:00:00"
        before: "23:00:00"
      - condition: trigger
        id: time_off
action:
....
22

Thanks, guys, looks like @fantangelo’s solution might be what I need, as per this: leaving the before clause at 23:00:00, the automation will ignore the time_off event. By making it 23:00:01 I ensure that the time_off trigger is no longer ignored, hence the “Turn Off Dehumidifier” action gets performed. And that only happens once until 9:00 AM. Anyway, I will see what happens tonight, and report back.

Many thanks, again!

23

Alright, guys, here I am reporting back: things work fine … except that once in a while the automation just does not go through, and here’s a screenshot of the trace:

Screenshot from 2024-05-03 23-04-46
Screenshot from 2024-05-03 23-04-461337×587 38.9 KB

Just to remind you, the automation YAML code is this:

alias: MideaDehumidifier
description: ""
trigger:
  - platform: time_pattern
    minutes: /1
  - platform: time
    at: "23:00:00"
    id: time_off
condition:
  - condition: time
    after: "09:00:00"
    before: "23:00:40"
action:
  - if:
      - condition: trigger
        id:
          - time_off
    then:
      - type: turn_off
        device_id: <50>
        entity_id: <25>
        domain: humidifier
    else:
      - if:
          - condition: numeric_state
            entity_id: sensor.meter_plus_7ea4_humidity
            above: 50
        then:
          - type: turn_on
            device_id: <50>
            entity_id: <25>
            domain: humidifier
        else:
          - type: turn_off
            device_id: <50>
            entity_id: <25>
            domain: humidifier
mode: single

What could be going wrong? :thinking:

24

It’s working exactly how you configured it. It triggers every minute and at 23:00:00. That means it attempts to trigger twice at the exact same time at 23:00:00. Which one of the two simultaneous trigger events is processed first may not always be the same. While the automation is busy processing the first trigger event, it blocks the second trigger event because the automation’s mode is single.

Reference

Script Modes

Changing the value of mode to queued will prevent blocking (meaning that while busy processing actions for the first trigger, it queues the second trigger) but it can potentially cause undesirable behavior. Here’s what I mean:

Imagine a scenario where the humidity is above 50 at 23:00:00 and then the Time Trigger is processed first and then immediately followed by the Time Pattern Trigger. The initial trigger results in turning off the humidifier. The subsequent trigger results in turning the humidifier back on. The humidifier is left on overnight.

I still recommend you use the Generic Hygrostat integration.

2 Likes
25

Thanks. Just to keep things simpler, I yanked out all that time_off trigger stuff, and made a separate automation that kills both basement dehumidifiers at 11:00 PM. It’s as simple as that. Now the state of both dehumidifiers is checked every minute between 9:00 AM and 11:00 PM and acted accordingly based on the humidity level, while the second independent automation simply turns them off at 11:00 PM.

And yes, I plan to look into the Generic Hygrostat asap.

Many thanks for your input!