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.
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.
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
@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.
here is the sensor I set up to calculate the estimated heating time
- name: "Pool Estimate Heat Time"
unique_id: diff_temp
unit_of_measurement: "°C"
state: >
{% set pooltemprise = states('sensor.pool_temp_rise_rate_7day_average') | float(none) %}
{% set poolsettemp = states('sensor.pool1_heaters0_settemp') | float(none) %}
{% set poolcurrenttemp = states('sensor.pool1_temperature') | float(none) %}
{{ (pooltemprise * ((poolsettemp) - (poolcurrenttemp))) | round(1, default=none) }}
starting too get the hang of this
The problem is the template sensors feeding the statistics sensors. We made them go unavailable so the statistics average would not be affected when the template sensors were not measuring.
I could make the two template sensors hold the last value, which will affect the 7 day average. Or hold the statistics average, but again this would be self referential and just reinforce the last calculated average.
How constant are the 7 day averages turning out to be?
The other option is to make two more template sensors that hold the last value of the statistics sensors. These will always display the averages but not affect them.
sounds like the last option is the go…how do you make it hold the last value?
What are your average statistics sensor entity_id’s?
sensor.pool_temp_rise_rate_7day_average
and
sensor.pool_temp_fall_rate_7day_average
- platform: template
sensors:
last_pool_temp_average_fall_rate:
friendly_name: "Last Pool Temp Average Fall Rate"
unit_of_measurement: "°C/h"
icon: thermometer-chevron-down
value_template: >
{% if states('sensor.pool_temp_fall_rate_7day_average') not in ['unavailable', 'unknown', 'none'] %}
{{ states('sensor.pool_temp_fall_rate_7day_average') }}
{% else %}
{{ states('sensor.last_pool_temp_average_fall_rate') }}
{% endif %}
last_pool_temp_average_rise_rate:
friendly_name: "Last Pool Temp Average Rise Rate"
unit_of_measurement: "°C/h"
icon: thermometer-chevron-up
value_template: >
{% if states('sensor.pool_temp_rise_rate_7day_average') not in ['unavailable', 'unknown', 'none'] %}
{{ states('sensor.pool_temp_rise_rate_7day_average') }}
{% else %}
{{ states('sensor.last_pool_temp_average_rise_rate') }}
{% endif %}