I’d like to make a sensor that calculates how fast an tank of water heats up when heater is on) and how fast it cools when heater is off. Ideally averaged over some period of time…like the last 7 days.
Not sure even where to start with this one.
The derivative integration will give you the rate of change. Then you can use the statistics integration to get averages over x days.
@petro Cool so something like this?
sensor:
- platform: derivative
source: sensor.pool1_temperature
name: Temperature change per hour
round: 1
unit_time: h
time_window: "168:00"
how would I isolate to create 2 sensors for only when heater is on? and a second for when only heater is off?
1 Like
You could feed the derivative to two template sensors:
template:
- sensor:
- name: Pool Heat Rate
unit_of_measurement: "°C/h"
icon: thermometer-chevron-up
state: "{{ states('sensor.temperature_change_per_hour') if is_state('switch.your_heater', 'on') else 'unavailable' }}"
- name: Pool Cool Rate
unit_of_measurement: "°C/h"
icon: thermometer-chevron-down
state: "{{ states('sensor.temperature_change_per_hour') if is_state('switch.your_heater', 'off') else 'unavailable' }}"
Feed these two sensors to statistics sensors to calculate the averages.
The reason for setting the sensor states to ‘unavailable’ when not in use is to prevent contaminating the statistics sensor average (like would happen if you set them to 0).
spoke too soon…dont think it is working…the sensors fed respond to current state of the heater…rather than historical…if I turn the heater off…then unavailable swaps to the other card
not sure if it worked…will it just start recording from now? as it has come in at 0.0000…or should it have loaded the past week of data? or does it start again from a restart?
###
- platform: derivative
source: sensor.pool1_temperature
name: Pool Temperature change per hour
unit_time: h
time_window: "168:00"
- platform: template
sensors:
pool_temp_rise_rate:
friendly_name: "Pool Temp Rise Rate"
value_template: >-
state: "{{ states('sensor.pool_temperature_change_per_hour') if is_state('sensor.pool1_channels4_mode', 'On') else 'unavailable' }}"
pool_temp_fall_rate:
friendly_name: "Pool Temp Fall Rate"
value_template: >-
state: "{{ states('sensor.pool_temperature_change_per_hour') if is_state('sensor.pool1_channels4_mode', 'Off') else 'unavailable' }}"
1 Like
Yes. Template sensors do not look at the past data.
Ok…thats good to know.
the sensor available is still switching cards depending on if the heater pump is on or off…have I implemented it wrong? because it seems to just be showing the ‘sensor.pool_temperature_change_per_hour’ data…on the card dependent on the state…rather then the data itself being filtered to show the different rates of change…not sure i described that well 
You asked for two sensors, one that shows the heating rate, one that shows the cooling rate. That’s what I gave you, in the new template integration format. What you implemented in the legacy template platform instead is not correct. If you want to use that platform do this:
- platform: template
sensors:
pool_temp_rise_rate:
friendly_name: "Pool Temp Rise Rate"
value_template: >
{{ states('sensor.pool_temperature_change_per_hour') if is_state('sensor.pool1_channels4_mode', 'On') else 'unavailable' }}
pool_temp_fall_rate:
friendly_name: "Pool Temp Fall Rate"
value_template: >
{{ states('sensor.pool_temperature_change_per_hour') if is_state('sensor.pool1_channels4_mode', 'Off') else 'unavailable' }}
@tom_l thank you…had no idea there was a legacy vs new platform…not sure I understand the difference…just didn’t work when i added it got some error…so modified it to try and be same but look like my others…lots to learn…thank you…where can i learn about the new integration format vs legacy? and do I need to go and change the old stuff to new? or just add with the new integration format?
thanks again…
No. At least not now.
the legacy style template sensors still work and there has been no deprecation announcement for them.
1 Like
There are advantages though, they do support new features (like state_class) without having to resort to customize.
Hi @tom_l
the ‘if is_state’ pump-on or off really does seem to just filter whether to show the data from the derivative.
If pump is on the pool rise entity shows a negative number at the moment (should be basically zero as pump has been off except a few very short moments to test what occurs
if the pump is turned off…it just swaps what card is showing the derivative data to the Temp Fall Rate card
Yes. That is what you wanted. A sensor for heating and a sensor for cooling.
You still have to feed these sensors to the statistics sensor as I said:
And as petro suggested.
1 Like
ok…gotcha. I misinterpreted how this would work
Thank you @tom_l for the patience
got there end got it working. I reworked it a little
Set the derivative sensor to 0.5 hours (to give me rate per hour, but measured in the same time periods - 30 min blocks as the electricity is billed and triggers pump switching). then fed the statistics with the two sensors you provided…and used an average over 168 hours to get my 7day average.
Hopefully I can now use these to estimate how much the pool will cool and how long it will take to heat. and then use that to select the best hours to heat based on electricity prices.
below is how I’ve implemented…appears to be working
#
- platform: derivative
source: sensor.pool1_temperature
name: Pool Temperature change per hour
unit_time: h
time_window: "0.5"
#
- platform: statistics
name: "Pool Temp Fall Rate 7Day Average"
entity_id: sensor.pool_temp_fall_rate
state_characteristic: mean
max_age:
hours: 168
- platform: statistics
name: "Pool Temp Rise Rate 7Day Average"
entity_id: sensor.pool_temp_rise_rate
state_characteristic: mean
max_age:
hours: 168
###
- platform: template
sensors:
pool_temp_rise_rate:
friendly_name: "Pool Temp Rise Rate"
value_template: >
{{ states('sensor.pool_temperature_change_per_hour') if is_state('sensor.pool1_channels4_mode', 'On') else 'unavailable' }}
pool_temp_fall_rate:
friendly_name: "Pool Temp Fall Rate"
value_template: >
{{ states('sensor.pool_temperature_change_per_hour') if is_state('sensor.pool1_channels4_mode', 'Off') else 'unavailable' }}
Great. It’s generally polite to mark the post that helped you get to your solution. Not your own, unless it was significantly different.
oh sorry…was thinking more about the solution being packaged up in one spot/post…rather then how I got there. will amend
1 Like
@tom_l is there a way to make the output of the statistics persistent when the pump switches on and off? as at the moment I get the 7 day average rate, but only on the rise sensor when pump is on and only on the fall sensor when the pump is off…otherwise I get unavailable.
I’d like to use the average rise rate, when it is currently unavailable, to estimate number of hours to heat the pool and then use that to select the energy the best energy rate possible. Buying at inexpensive times.
the reason to bother with the 7 day average and estimation is that the performance of a heat pump is very variable on climate conditions.
example: if the pool is 29c and the 7day average says I need 4hours to achieve set temp…then the condition for turning on the pump will be that the price of electricity is within the 4 (or maybe 5 for insurance) best hours based on the forecast price.
maybe I need to set something static to get the pump on each day at a “good” rate and then it would be available and dynamic once on - changing to better hours as it had less gap to making the desired temp.
Nice, this is going to work for household HVAC as well, to see how the cooling/ heating needs to perform.
I.e. It could calculate the optimal hours to run the A/C to keep the house at a steady temp with variable electricity pricing.