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

I know how to implement automations based on some parameter transition (aka event-based), but unfortunately those kind of triggers are not very useful. Say you need your basement dehumidifier to be ON when the humidity is above 50, say. Merely designing an “above” trigger to turn the dehumidifier on when the humidity crosses the 50 threshold upwards ain’t gonna do it: what if there is a power outage that turns the humidifier off? If the humidity stays constant above 50, this automation will never turn the dehumidifier on after the power has been restored, so your basement could be stuck in humidity in the 80s for the rest of the day until the humidity goes below 50 and then comes back above 50.

In short, I need to build an automation that checks the humidity every minute, say, and triggers the dehumidifier ON if above 50, and off if below 50.

Can this be done with HA automations? :thinking:

1 Like

You can literally just do exactly that. Trigger is time based and fires every minute, condition is your humidity level, etc.

2 Likes

Trigger on home assistant start event also and you will get it working as intended.

1 Like

And even better for your specific use-case:

3 Likes

Thanks guys! Here’s some quasi-pseudo-code of the automation:

IF 9:00AM < time < 11:00PM
   Trigger every minute of every hour
   IF humidity > 50
      switch dehumidifier ON
   ELSE
      switch dehumidifier OFF
   ENDIF
ELSE
   switch dehumidifier OFF
ENDIF

What would this look like in YAML? :thinking:

Something like this? (I agree with others, every minute is excessive and the hygrostat would be a better option).

trigger:
  - platform: time_pattern
    minutes: /1
condition:
  - condition: time
    after: "09:00:00"
    before: "23:00:00"
action:
  - if:
      - condition: numeric_state
        entity_id: sensor.indoor_average_humidity
        above: 50
    then:
      - service: switch.turn_on
        target:
          entity_id: switch.<your switch>
    else:
      - service: switch.turn_off
        target:
          entity_id:
            - switch.<your switch>
1 Like

(this is kind of minor but isn’t every minute excessive? you might also want to build in some hysteresis, so I feel the generic hygrostat might be solving all those nuances for you, thought I’ve never used it myself)

Thanks. I am guessing that I have to write a second automation for the upper-level ELSE, where I turn the dehumidifier OFF during the night, right?

Outside of the time period 09:00-23:00? You can just add a time trigger of 23:00 and use a trigger id and an if block to accomplish that.

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:00"
action:
  - if:
      - condition: trigger
        id:
          - time_off
    then:
      - service: switch.turn_off
        target:
          entity_id: switch.<your switch>
    else:
      - if:
          - condition: numeric_state
            entity_id: sensor.indoor_average_humidity
            above: 50
        then:
          - service: switch.turn_on
            target:
              entity_id: switch.<your switch>
        else:
          - service: switch.turn_off
            target:
              entity_id:
                - switch.<your switch>
1 Like

Trigger on:

  1. Above 50
  2. HA startup
  3. Dehumidifier turns off

Condition:

  1. Above 50
  2. Dehumidifier off

Action:

  1. Turn on dehumidifier
3 Likes

If you believe that then you have misunderstood how to use “event-based” triggers. The failure scenarios described in your first post can be mitigated by a proper combination of triggers. In other words, it should detect more than one “event” to make it more fault-tolerant. There’s no need to revert to periodic polling (which is an inefficient use of resources in an event-based system like Home Assistant).

Nevertheless, what you’re requesting is trivial to implement with the Generic Hygrostat integration and an automation that limits its operation to the desired hours. It provides the added benefit of allowing for the humidity level to be controllable via the UI.

Effectively, this is the same kind of request by users who attempt to create an automation to control a heater (the solution is to use the Generic Thermostat integration).


NOTE

You may wish to peruse the following topic which demonstrates how to make an automation more fault-tolerant.

1 Like

Thanks. Prima facie, I find it impossible to predict what could go wrong, though I will attempt to study the issue further, when I can afford the time. For now, I will take the easy way out, and see how that goes.

Thanks again. I will have to devote some time to studying this Hygrostat integration.

I suggest your investment of time will provide you with better returns if you implement the Generic Hygrostat integration. After that, a simple automation can control when it is enabled/disabled.

I believe the generic hygrostat has the same bug as generic thermostat.
It will govern the humidity but not the device.

I noticed this when the room was warm and it allowed be to turn on the switch to the radiators, in my opinion the code should switch off the device in such cases.
I assume the hygrostat has the same issue since the code is probably based on each other.

@code-in-progress: Followed your instructions, and things work fine … except that the device does not get turned off @11PM. What am I doing wrong? Here’s the code:

alias: HisenseDehumidifier
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:00"
action:
  - if:
      - condition: trigger
        id:
          - time_off
    then:
      - service: switch.turn_off
        metadata: {}
        data: {}
        target:
          device_id: <some ID>
    else:
      - if:
          - condition: numeric_state
            entity_id: sensor.meter_plus_e84f_humidity
            above: 50
        then:
          - service: switch.turn_on
            metadata: {}
            data: {}
            target:
              device_id: <some ID>
        else:
          - service: switch.turn_off
            metadata: {}
            data: {}
            target:
              device_id: <some ID>
mode: single

What does the automation trace show?

1 Like

In addition to what @Tinkerer said, I suspect it might be using the device id versus the entity id. I would try it with entity_id: <your entity> and see if that works. There is very little confidence that the device id is actually correct (I avoid using them at all and favor entities).

EDIT: Never respond to forum posts on a Monday morning before you’ve had coffee. :coffee:

change

before: "23:00:00"

to

before: "23:00:01"
1 Like

I said nothing. :zipper_mouth_face:

omg… lmao. Sorry!!! Monday morning pre-coffee… that’s my excuse. :smiley:

2 Likes