Automation trigger: Dropping Temperature

I have an Ecobee tstat with entity: 630.climate

One attribute of 630.climate is current_temperature.

I made the automation below, but it would be much more useful if the trigger included a condition that the current temperature is lower than the temperature it was 10 minutes earlier (even better would be that the current temp is lower than it was 10 minutes earlier and the temp 10 minutes earlier is lower than it was 10 minutes before that). That way, I can be notified is the boiler is truly not doing its job.

All I have now (thanks for the great history of threads here) is the ability to send a notification when the boiler has been running for x minutes conditioned on the temperature being below a threshold.

Thank you.

alias: 630-furnace-running-and-cold
description: ""
trigger:
  - platform: state
    entity_id:
      - binary_sensor.630_heat_graph_binary
    to: "on"
    for:
      hours: 0
      minutes: 10
      seconds: 0
condition:
  - condition: numeric_state
    entity_id: climate.630
    attribute: current_temperature
    below: 65
action:

  - service: notify.notifier_name
    data:
      message: >
        630:  Furnace running for
        {% set x = 'binary_sensor.630_heat_graph_binary' %}
        {{ (as_timestamp(now()) - as_timestamp(states[x].last_changed | default(0)) | int ) | timestamp_custom("%Hh %Mm", false)}}
        and temperature is {{
        states("sensor.630_ecobee_temperature") }} degrees
     
mode: single

I suggest you consider using the Trend integration to create a binary sensor that indicates a decreasing temperature trend. Then your automation can use a simple State Condition to test if the Trend Binary Sensor is on.

The Trend integration offers several parameters (min/max samples, duration, gradient) to calculate trend. It may take a bit of experimentation, selecting the optimal combination of parameter values, to report the trend you want.

The Trend integration allows for the creation of Helpers, right?

I installed and tried to create a helper based on climate.630, but received:

ā€œUser input malformed: Entity climate.630 belongs to domain climate, expected [ā€˜sensorā€™] for dictionary value @ data[ā€˜entity_idā€™]ā€

I would rather not have to use a template to create a sensor for the attribute ā€œcurrent_temperatureā€ under ā€œclimate.630ā€ because I have many of these climate.* entities.

Am I on the right track here?

Thank you.

Then you wonā€™t be able to use the Trend integration and will have to invent another way to calculate the trend of the current_temperature value. However, you will discover that reporting a computed value typically involves the use of a Template Sensor and you have already rejected that option.

This post might help (also using a template, though).

Note that you may run into issues with entity IDs starting with a digit. Nothing inherently wrong with that, but you should be aware of the potential pitfalls. More here:

Me inventing another way is an absolute impossibility: I have a hugely difficult time just recreating or putting to use what others have figured out.

If the Trend helper is the only (or the easiest) way to get a trend, and it requires a sensor value, can I create the sensor in automation (sort of, on the fly), so I donā€™t have yet another 30+ template sensors in my configuration.yaml file for me to wonder about their origin and purpose in 6 months when Iā€™m troubleshooting stuff?

(I know, thereā€™s a lot to digest there, if you so choose ā€” which I wouldnā€™t advise.)

No.

YAML allows comments.

1 Like

That I knowā€¦

I also know that I could use a separate sensors.yaml but the fear of screwing it up and spending 2 days pulling my hair out trying to fix it has kept me from doing this.

I believe I read that we canā€™t start slow and have some sensors defined in configuration.yaml and also include a separate sensors.yaml file.

you can do that by using packages:

I went ahead and created a sensor in configuration.yaml:

  - platform: template
    sensors:
      630_ecobee_temp:
        friendly_name: "630 Ecobee Temperature"
        unit_of_measurement: ""
        value_template: "{{ state_attr('climate.630', 'current_temperature') }}"

Created a Trend helper:

But the Trend help is a binary device and I donā€™t understand how to associate ā€˜onā€™ or ā€˜offā€™ with a dropping state value for ā€˜630_ecobee_tempā€™

I see in the Trend integration docs discussion of adding to configuration.yaml something like:

binary_sensor:
  - platform: trend
    sensors:
      temp_falling:
        entity_id: sensor.outside_temperature
        sample_duration: 7200
        max_samples: 120
        min_samples: 20
        min_gradient: -0.0008
        device_class: cold

      temp_rising:
        entity_id: sensor.outside_temperature
        sample_duration: 7200
        max_samples: 120
        min_samples: 20
        min_gradient: 0.0008
        device_class: heat

Is this correct? Do I need to add a sensor created from climate as well as a Trend helper as well as a binary_sensor with -platform: trend?

Why did you choose to configure it using legacy format?

Thatā€™s the old way of configuring a Template Sensor as opposed to the new, ā€œmodernā€ way which is described at the very beginning of the Template integrationā€™s documentation.

Why did you set the value of unit_of_measurement to be an empty string?

No.

There are two methods for creating/configuring a Trend Binary Sensor, via YAML or via the UI. Choose one; I suggest YAML.

Because my configuration.yaml is a mess.

I removed the sensor from the old way and added the following:

template:
  - sensor:
      - name: "630_ecobee_temperature"
        unit_of_measurement: "Ā°F"
        value_template: "{{ state_attr('climate.630', 'current_temperature') }}"

Is this correct?

Good to hear itā€™s UI OR yaml. I made a Trend help in the UI. I thought maybe it would create yaml code in configuration.yaml, but I donā€™t see it.

Do I understand correctly that instead of using the UI I could add the following to configuration.yaml:

binary_sensor:
  - platform: trend
    sensors:
      630_temp_falling:
        entity_id: sensor.630_ecobee_temperature
        sample_duration: 7200
        max_samples: 120
        min_samples: 20
        min_gradient: -0.0008
        device_class: cold

I assume this code creates a binary sensor named 630_temp_falling based on the sensor 630_ecobee_temperature and using the min_gradient paramater to determine the binary state of 630_temp_falling? That is, 630_temp_falling is set ā€˜onā€™ based on the dropping state value of 630_ecobee_temperate as per the gradient?

Update:

I got the binary_sensor named ā€œ630_temp_fallingā€ working with the following code (I didnā€™t have a section in configuration.yaml for binary_sensor, so now I do):

binary_sensor:
  - platform: trend
    sensors:
      630_temp_falling:
        entity_id: sensor.630_ecobee_temperature
        sample_duration: 2400
        max_samples: 30
        min_samples: 2
        min_gradient: -0.0001
        device_class: cold

And, sensor ā€œ630_ecobee_temperatureā€ is now created in configuraiton.yaml like this:

template:
  - sensor:
      - name: "630_ecobee_temperature"
        unit_of_measurement: "Ā°F"
        value_template: "{{ state_attr('climate.630', 'current_temperature') }}"

And the automation is:

alias: 630-furnace-running-and-cold
description: ""
trigger:
  - platform: state
    entity_id:
      - binary_sensor.630_heat_graph_binary
    to: "on"
    for:
      hours: 0
      minutes: 10
      seconds: 0
condition:
  - condition: numeric_state
    entity_id: climate.630
    attribute: current_temperature
    below: 65
  - condition: state
    entity_id: binary_sensor.630_temp_falling
    state: "on"
action:
  - service: notify.notifier_name
    data:
      message: >
        630:  Furnace running for {% set x =
        'binary_sensor.630_heat_graph_binary' %} {{ (as_timestamp(now()) -
        as_timestamp(states[x].last_changed | default(0)) | int ) |
        timestamp_custom("%Hh %Mm", false)}} and temperature is {{
        states("sensor.630_ecobee_temperature") }} degrees
mode: single

I think the problem now is that the automation is only triggered when the binary_sensor.630_heat_graph_binary state CHANGES to ON.

What I need is for the automation to run not when it changes, but when it has been on for 10 minutes (regardless of when it was last off).

That automation should trigger if it has been on for ten minutes ā€” at that time, it was last off ten minutes before.

What is it doing; and what do you want it to do?

Thatā€™s exactly how a State Trigger works when you use its for option.

The moment the Trend Binary Sensor turns on the State Trigger starts an internal 10-minute timer.

  • If the Trend Binary Sensorā€™s state remains on throughout the 10-minute countdown, when the countdown expires the trigger is fired.

  • If the Trend Binary Sensorā€™s state changes from on to off at any point during 10-minute countdown, the countdown is reset and the trigger is not fired.

If you recall what I originally wrote here the idea was to use the Trend Binary Sensor in a State Condition. The assumption was you would be something else to trigger the automation and then it would check if the Trend Binary Sensor was on (which is configured to indicate the temperature has been decreasing for at least the past 10 minutes).

You used the Trend Binary Sensor in a State Trigger with for set to 10 minutes. Therefore it will trigger 10 minutes the state of the Trend Binary Sensor changes from off to on. In other words, 10 minutes after the first detection of a decreasing trend. That seems to comply with your stated requirement:

If it doesnā€™t, please describe the requirement again with additional details.

This is a lot to digest ā€“ I hope Iā€™ve done so correctly.

My goal for the automation is to send a notification when (1) the thermostat is calling for heat, and (2) when the temperature in the house is below 65* F, and (3) when the temperature in the house is falling by X*/hour.

I think we (well, you :wink: ) have accomplished this except for the situation where the tstat is calling for heat for an extended period of time (i.e., binary_sensor.630_heat_graph_binary does not change from OFF to ON).

For example:

  1. Tstat changes from not calling for heat to calling for heat (i.e., OFF to ON), temp inside is 60* and drops to 50*. Notification would be sent.

  2. Tstat changes from OFF to ON, temp inside is 70* and drops to 50*. Notification would be sent.

  3. Tstat changes from OFF to ON. Temp inside is 70* and remains at 70* for 3 hours. Then (furnace fails; window is left open; etc.) and temp drops to 50*. I donā€™t know if notification would be sent because the conditions occurred 3 hours after the trigger.

  4. Tstat changes from OFF to ON. Temp drops from 70 to 50. Notification sent at 00:00. 4 hours later and tstat never changes back from ON to OFF (i.e., it continues to call for heat) and heat drops to 35*. Another notification is not sent. I would like to be notified if the temp-dropping condition persists.

Please fix this.

itā€™s state: not value_template:

Great catch! Thank you very much.

1 Like