Spotty performance with an automation that uses a template as a trigger

Configuration
1

I’m attempting to use an average of three sensor readings for humidity to determine when to turn on a switch (Zooz Zen15) that a dehumidifier is connected to.

I expect the switch to turn on whenever the average reading is updated and about 59, after a four minute delay:

- id: '1574313844600'
  alias: Dehumidifier Turn On - 59+
  initial_state: 'on'
  description: ''
  trigger:
  - above: '59.0'
    entity_id: sensor.house_average_humidity
    platform: numeric_state
  condition: []
  action:
  - delay: 00:04:00
  - device_id: fa101a70712d47ec85e11fa4a28086e9
    domain: switch
    entity_id: switch.dehumidifierswitch_switch
    type: turn_on

The template for sensor.house_average_humidity is:

      house_average_humidity:
        friendly_name: "House Average Humidity"
        unit_of_measurement: '%'
        value_template: "{{ ((float(states.sensor.zooz_zse40_4_in_1_sensor_relative_humidity_3.state) + float(states.sensor.zooz_zse40_4_in_1_sensor_relative_humidity_4.state) + float(states.sensor.zooz_zse40_4_in_1_sensor_relative_humidity_5.state)) / 3) | round(2) }}"

The four minute delay is to allow for the dehumidifier’s cooling off period after a power interruption, should the automation be triggered immediately after an hour. There’s a separate automation that turns the switch off after an hour that works without issue.

The automation as-is will go hours without triggering if left alone, even with plenty of sensor readings- the only way I’ve found that I can force it (without using the “trigger” button) is to turn the automation off and then on, and use States tool to bump up either sensor.house_average_humidity or one of the individual sensors so that the average changes.

A couple of days ago I wanted to keep the dehumidifier from turning on during sleeping hours and had a condition for time, the automation seemed to work as expected with a condition in place, but not without one. As I type I realize I could use a false condition and just a time of 00:00:00 to 23:59:59 to hopefully replicate prior performance, but I guess now I’m curious about why the automation is not working as expected.

Thanks for any info/advice!

2

What do you mean by “the automation isn’t working as expected”? Note that a numeric state trigger will only trigger whenever the state of the entity goes above or below the value you set. If it’s already above or below the threshold you define when you create the automation or turn it on, it won’t trigger.

1 Like
3

Thanks for your reply! I understand that the automation cannot trigger without a change in the numeric state in the entity, but for some reason it does not work unless “forced”, please see a snippet of readings from earlier today:

Capture

At ~2:05 the switch turned off as expected as per the working “off after an hour automation”. Then the entity shows different states, all above the threshold that should trigger it, until ~3:00, when I cheated by turning it on and off and then changing the value using the States tool.

4

Right. After it turned off at 2:05, it never went below 59 and above it again. It was always above 59 after that. The sensor has to go below the threshold and back above it for it to trigger again.

5

That certainly explains why it’s not triggering as written, thank you! Do you have any advice on a solution that would turn the switch back on if the threshold was not met?

6

Create an automation with a state trigger with the entity being the sensor and no to or from. It should also have a numeric state condition checking if the sensor is above 59.

7

Why not let the dehumidifier do its job and run until the humidity drops below 59?

Simply create an automation that turns off the dehumidifier based on a threshold as opposed to a fixed period of time (i.e. when humidity drops below 55, turn off the dehumidifier).

8

Yeah, I’m interested to see why this isn’t what OP is already doing.

9

Like this?

- id: '1574313844600'
  alias: Dehumidifier Turn On - 59+
  description: ''
  trigger:
  - entity_id: sensor.house_average_humidity
    platform: state
  condition:
  - condition: state
    entity_id: sensor.house_average_humidity
    state: '>59'
  action:
  - delay: 00:04:00
  - device_id: fa101a70712d47ec85e11fa4a28086e9
    domain: switch
    entity_id: switch.dehumidifierswitch_switch
    type: turn_on
  initial_state: 'on'
10

Nope. No such thing as that.

11

Because I’ve found that there’s diminishing returns once once the dehumidifier has been running for an hour with it’s current location and the fact that one of the rooms that’s being monitored (kids bedroom) is closed for a few hours during the day.

If left on, the device spends roughly half the time in fan only mode with very marginal improvements in overall humidity levels. My thinking is that by using an average and forcing a max hour runtime it’s making it more efficient while it’s on.

If the device was in a closed room it would certainly work as expected, but I’m trying to use an over-powered dehumidifier to address all of the air in a smaller, one-story house.

I’m open to the possibility that I’m over-thinking it and or incorrectly-thinking too!

12

Thank you!

13

Check here: https://www.home-assistant.io/docs/scripts/conditions/#numeric-state-condition

But yeah, I’d consider what Taras said.

14

It’s also goofing up your automation because, as explained, it must re-cross the threshold in order to trigger again.

15

Have a look at this solution and see if it can be adapted for your needs. The requirement was to keep the humidity within a given range.

16

Thank you both so much- it makes sense now that I have a better understanding of how the threshold works, I thought it should be checking to see if the value “was” above a certain number, rather than “going” above that number (at least, that’s my amateur approach to thinking about it).

I’ve changed it so the dehumidifier does it’s job as suggested, dropping the average humidity below the threshold before turning off as suggested and it’s working as expected.

Taras- the link you posted to your write up looks great for version 2.0 of my setup; now that I have it working flawlessly I can’t wait to play with (break) it some more.

Thanks again!