Using input_text in trigger state

Configuration
21

if your problem is that you get messages too often, you have various scenarios to change that:

  • change the triggering entities
  • change the criteria for the calculation of temps (main template)
  • change the conditions under which the main template should further be limited

the latter could be:
frequency: change the time between messages
rule out too small changes: change the difference delta to be larger than simply any change at all (like now)
rule out attribute changes to trigger the automation (my set of 3 )

Hope this helps.

an example for the frequency could be:

      - condition: template
        value_template: >
          {{ (as_timestamp(now()) - 
              as_timestamp(state_attr('automation.notify_indoor_temperature','last_triggered')) 
              | default(0) | int > 180) }}

and as said, use it in the action block.

22

@Mariusthvdb, thanks for help i really appreciate it.

My goal is getting messages only when temperature enter new interval.
This is already done in my first message in this topic. And works exactly like i need. But it require one automation for each temperature sensor. 10 sensors - 10 identical automation. If I decide to change something in automation i need to change it in 10 places. Configuration is ugly.

That’s why I thinked there is better way - templating identical sensor automation. On first though idea with conditions was good. But as the result I must fight multiple unneeded notification.

Second variant working with multiple entities - platform: numeric_state. Only problem - below/above doesn’t accept values from variables or states.

Ok. I think I’ll open a feature request for accepting values from other entities in below/above option.

Once more - thanks for help.

23

The reason you’re ‘fighting’ multiple notifications is because of the way you created the condition … which effectively does nothing and accepts any value.

You’ve already described the kind of condition you need:

You want a condition that checks if the temperature crosses one of the two thresholds (temp_low or temp_high). That means it must check if the value’s previous state (trigger.from_state.state) to its current state (trigger.to_state.state) crossed a threshold.

There are two thresholds creating three ranges:

    1    |     2    |    3
---------|----------|---------
         |          |
        low        high

We are only interested when the value crosses a threshold into a different range:

Entering range 1: to_state < low and from_state >= low

Entering range 2: to_state >= low and from_state < low

Entering range 2: to_state <= high and from_state > high

Entering range 3: to_state > high and from_state <= high

Here is the condition:

  condition:
    condition: or
    conditions:  
      - condition: template
        value_template: >
          {{ trigger.to_state.state|float   <  states('input_number.outdoor_temperature_low')|float and 
             trigger.from_state.state|float >= states('input_number.outdoor_temperature_low')|float }}
      - condition: template
        value_template: >
          {{ trigger.to_state.state|float   >= states('input_number.outdoor_temperature_low')|float and 
             trigger.from_state.state|float <  states('input_number.outdoor_temperature_low')|float }}
      - condition: template
        value_template: >
          {{ trigger.to_state.state|float   <= states('input_number.outdoor_temperature_high')|float and 
             trigger.from_state.state|float >  states('input_number.outdoor_temperature_high')|float }}
      - condition: template
        value_template: >
          {{ trigger.to_state.state|float   >  states('input_number.outdoor_temperature_high')|float and 
             trigger.from_state.state|float <= states('input_number.outdoor_temperature_high')|float }}

Alternately, this version which uses a single Template Condition and is far more legible:

  condition:
    - condition: template
      value_template: >
        {% set to_state = trigger.to_state.state|float %}
        {% set from_state = trigger.from_state.state|float %}
        {% set low = states('input_number.outdoor_temperature_low')|float %}
        {% set high = states('input_number.outdoor_temperature_high')|float %}
        {{ (to_state <  low  and from_state >= low) or
           (to_state >= low  and from_state <  low) or
           (to_state <= high and from_state >  high) or
           (to_state >  high and from_state <= high) }}
1 Like
24

no feature request is necessary, you can do all that using the variables of trigger.to_state.state (and trigger.from_state.state)

Add that to the original condition of @123 for the various extra limitations, and your set to go.

edit

wait, I now see Taras post above (responded to the email before…)
start with that, and you’ll see no feature request is necessary.

you’ll still get too many messages, but you can easily narrow those down, using what I described earlier.

things like

condition: template
value_template: >
  {{(trigger.to_state.state|int - trigger.from_state.state|int)|abs >= 1}}

etcetc

25

@123, amazing!

I forgot I can compare to/from state with temperature margins I have configured.
That’s much better.

  1. It’s very compact
  2. easy to read
  3. no bad notification when I change temperature margins as temperature sensors doen’t change its state.

I have added unavailable state in template. Hasn’t powered off a sensor to check, but manually setting sensor status to unavailable works like it should.

# Notify outdoor temperature sensors changes
- alias: "Notify Outdoor Temperature"
  initial_state: on
  trigger:
    - platform: state
      entity_id:
        - sensor.outside_temperature
  condition:
    - condition: template
      value_template: >
        {% set to_state = trigger.to_state.state|float %}
        {% set from_state = trigger.from_state.state|float %}
        {% set low = states('input_number.outdoor_temperature_low')|float %}
        {% set high = states('input_number.outdoor_temperature_high')|float %}
        {{ (to_state <  low  and from_state >= low) or
           (to_state >= low  and from_state <  low) or
           (to_state <= high and from_state >  high) or
           (to_state >  high and from_state <= high) or
           (to_state == unavailable) }}
  action:
    - service: notify.hedgehog57
      data_template:
        message: >-
          {% set emoji = "sensor."+trigger.to_state.entity_id.split('.')[-1]+"_emoji" -%}
          {{ states(emoji) }} {{ trigger.to_state.name }}: {{ trigger.to_state.state }}{{ state_attr(trigger.to_state.entity_id, 'unit_of_measurement') }}

@Mariusthvdb, thanks You too. I still don’t understand why I will have too many messages. ATM i will receive a message when margins are passed for 0.1 degree. It’s acceptable. I will not receive new messages about this sensor until it will pass margin in other direction. Many messages will be generated if temperature will slightly change around a margin.

As I understand You propose to notify only when state pass margin for more than 1 degree, right? Good Idea. In case of flood messages I will add Your code to automation.

About FR I was told earlier. For this automation it is not needed, You’re right. But it’s strange that from/to can use templates but below/above can not.

Now I need to check all my automations with this new knowledge about conditions.

Thanks to all! Hope it was interesting and instructive not only for me.

1 Like
26

Glad to hear that it works for you and you like it.

Please mark my post as the Solution so that other users, with a similar question, can easily find the answer. Only you, the author of this topic, can mark the Solution. It will automatically appears as a link under your first post, thereby making it easier for others to find it (and a checkmark will appear next to the topic’s title). Thanks.