Trigger numeric state has changed xx over time

Hi

I have a humidity sensor I want to use in the bathroom, along with light and speaker control.

My use case is:
I have a PIR sensor which controls the light/speaker. It does not capture any movement when I am showering. That is why I bought a humidity sensor.
I have a binary_sensor called “Shower”, which is on if the humidity is above 60%.
The binary_sensor is pretty fast in regestring that the shower is running, because the humidity rises fast.
My problem is in triggering when we are not using the shower anymore. The humidity changes slower, meaning that the binary_sensor will turn off almost 10-20 minutes after we actually went out of the shower.

Question: Is it possible to trigger an automation, if a numeric state has changed -15% over the last 5 minutes etc? and how? I am all out of ideas.

Without knowing more about how the humidity behaves during and after a shower, as reported by the humidity sensor, I’d be tempted to try something like this. Have an input_boolean that gets turned on when the humidity rises above 60%. Then have it turned off when the humidity lowers below some higher threshold (70%? 75%?) depending on how the humidity drops after the shower is stopped. Then use the state of that input_boolean to control the light & speaker.

The tricky part of this is only changing the input_boolean when the humidity goes from 60% or lower to higher than 60%, and when the humidity goes from above the upper threshold to below it. Basically you need hysteresis. Unfortunately the numer_state trigger by itself can’t do this (even though the docs imply it can.)

I think the following may be a start in the right direction.

input_boolean:
  showering:
    initial: off

automation:
  - alias: Showering
    trigger:
      platform: state
      entity_id: sensor.humidity
    condition:
      condition: template
      value_template: >
        {{ trigger.from_state.state | float <= 60 and
           trigger.to_state.state | float > 60 or
           trigger.from_state.state | float >= XX and
           trigger.to_state.state | float < XX }}
    action:
      service_template: >
        {% if trigger.from_state.state | float <= 60 %}
          input_boolean.turn_on
        {% else %}
          input_boolean.turn_off
        {% endif %}
      entity_id: input_boolean.showering

Of course replace XX with whatever upper threshold you think is appropriate. You could even use an input_number to control the upper threshold if necessary.

That could work perfect for me. Will give it a try tomorrow. Thanks a lot!

It worked as intended! Thank you.
I have found out that the upper value needs to be dynamic, as it depends on who is taking a shower -_-

I have tried this:

  {{ trigger.from_state.state | float <= 70 and
 trigger.to_state.state | float > 70 or
 trigger.from_state.state | float >= (states.variable.i_bad_1_sal_variabel.state - 10) | float and
 trigger.to_state.state | float < (states.variable.i_bad_1_sal_variabel.state - 10) | float}}

and other variations. I just cant figure out how to make this comparison

I believe all states are strings, even for entities from the variables domain. Therefore you should convert to float before subtracting 10, not after. I.e.:

{{ trigger.from_state.state|float <= 70 and
   trigger.to_state.state|float > 70 or
   trigger.from_state.state|float >= states('variable.i_bad_1_sal_variabel')|float - 10 and
   trigger.to_state.state|float < states('variable.i_bad_1_sal_variabel')|float - 10 }}

To make it a bit more readable you could do this:

{% set upper = states('variable.i_bad_1_sal_variabel')|float - 10 %}
{{ trigger.from_state.state|float <= 70 and
   trigger.to_state.state|float > 70 or
   trigger.from_state.state|float >= upper and
   trigger.to_state.state|float < upper }}

Dude… you are the best! Thank you so much, my evening is saved :stuck_out_tongue:

1 Like

Just for the record, it seems I was confused about how the numeric_state trigger actually works. Ignore what I said about the docs being wrong. It may be possible to do this with the numeric_state trigger. But, if it’s working for you now, might not be worth changing.