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.
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.)
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.
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.
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?
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):
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 ) 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:
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.
Tstat changes from OFF to ON, temp inside is 70* and drops to 50*. Notification would be sent.
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.
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.
) 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).