Thanks very much for taking the time to post that @del13r. I’m still thinking about this. It must be great to see as much production used as possible. Looking back, my bad, rainy day production tends to be soaked up pretty completely by the normal background use in my house, and, given I have a small water tank for the size of the household, it does still worry me a bit. It will all be down to whatever mitigating procedures are put in place by whatever system I’d use really. Although, granted, the number of days that are likely to be a problem are very small.
After I changed my electricity retailer, I am now on a rolling 28 day bill whereas previously I was on quarterly.
I have figured out how to add 28 days to the reset date once the current bill is finished and the reset is triggered.
I have added
- service: input_datetime.set_datetime
target:
entity_id: input_datetime.de_monthly
data:
datetime: '{{ now().date() + timedelta(days=28) }}'
to my existing Meter Reset automation so that it now looks like this
alias: Monthly Meter Reset
description: ''
trigger:
- platform: time
at: input_datetime.de_monthly
condition: []
action:
- service: utility_meter.reset
target:
entity_id:
- utility_meter.monthly_energy
- utility_meter.monthly_energy_export
- service: notify.notify
data:
message: monthly meter reset
- service: input_datetime.set_datetime
target:
entity_id: input_datetime.de_monthly
data:
datetime: '{{ now().date() + timedelta(days=28) }}'
mode: single
Nice. It is much appreciated that you keep us all up to date.
I have also updated the same code in my Time of use seasons (seasons defined by the power company which effects what months have peak rates charged).
The reason why I am doing this automation is so I won’t have to remember to update the date/time helper manually myself.
In this case, I will be adding a year onto the existing helper.
Here is how I tested it and know ahead of time if it will work or not.
First I checked my logic
I went to developer tools / template /
{{ now().date() }}
result was 2021-12-09
Then I did this template
{{ now().date() + timedelta(days=365) }}
and result was 2022-12-09
Then I went to my 4 automations (1 for each season) and updated them to look like this one for example where peak tariffs are not charged for 2 months from April 1 onwards so that is why this automation disables 2 peak tariff related automations from running.
alias: TOU Autumn
description: ''
trigger:
- platform: time
at: input_datetime.autumn_tou
condition: []
action:
- service: automation.turn_off
target:
entity_id:
- automation.tariff_peak
- automation.tariff_offpeak_weekday
- service: input_datetime.set_datetime
target:
entity_id: input_datetime.autumn_tou
data:
datetime: '{{ now().date() + timedelta(days=365) }}'
mode: single
I have also ditched the 5 hour pool pump timer in favour of a history_stats sensor.
I found that if I rebooted Home Assistant, the timer status would be forgotten.
This new history_stats sensor records how long the pool pump has run for the last 24 hours from right now.
- platform: history_stats
name: Pool Pump Duration 24H
entity_id: sensor.pool_pump_switch_time_based
state: "on"
type: time
end: "{{ now() }}"
duration:
hours: 24
As I just set it up today, the sensor has not recorded enough data yet, but effectively this is what it looks like
And then I can use logic in my automations to decide to make up for poor solar generation in the last 24 hours that prevented the pool pump from running long enough in the day.
This logic for example will return a true condition if the pool pump has run for less than 5 hours in the last 24 hours.
{{ states('sensor.pool_pump_duration_24h') | float < 5 }}
Those are both very imaginative solutions. The use of the history_stats sensor is much neater than the timer. Didn’t know that sensor existed either, but then almost everything you come up with is news to me!
1 Like
Here is my pool pump automation.
alias: Pool Pump on 2am
description: ''
trigger:
- platform: time
at: '02:00:00'
condition:
- condition: or
conditions:
- condition: template
value_template: '{{ states(''sensor.solcast_forecast_today'') | float < 30 }}'
- condition: template
value_template: '{{ states(''sensor.pool_pump_duration_24h'') | float < 5 }}'
action:
- service: switch.turn_on
target:
entity_id: switch.sonoff_MACADDRESS
- service: notify.notify
data_template:
message: >-
Pool Pump on. Solar forecast {{ states('sensor.solcast_forecast_today')
| int }} kWh, pump ran for {{ states('sensor.pool_pump_duration_24h') }}
H / 24 H
mode: single
Here is what the message would look like if either condition was true when the trigger time occured.
Pool Pump on. Solar forecast 21 kWh, pump ran for 1.47 H / 24 H
Nice and simple. Love it! I’d like to do something similar, but I’m still trying to get my head around controller a pool sweep, chlorinator and heat pump as well, all for a different number of hours. I’m sure it’s doable, but needs some thought…
EDIT: What’s turning the pump off after 5 hours of total running using this method?
Well, when she sun is shining, I’m happy for the pool pump to run as long as it can as long as there is enough solar power to run it for free to maximise my self consumption.
I have 2 possible triggers.
Both have a condition that the pump has to be running first and the sun has to be above the horizon.
1st trigger is to shut off at 7am as that’s when power gets slightly more expensive and that’s exactly 5 hours from 2am.
the other trigger is when power amount being imported from the grid goes above 100watts for 5 mins while the sun is up.
alias: Pool Pump Off 7am or grid import
description: ''
trigger:
- platform: numeric_state
entity_id: sensor.grid_import_power
for: '00:05:00'
above: '100'
- platform: time
at: '07:00:00'
condition:
- condition: state
entity_id: switch.sonoff_MACADDRESS
state: 'on'
- condition: state
entity_id: sun.sun
state: above_horizon
- condition: time
after: '07:00:00'
action:
- service: switch.turn_off
target:
entity_id: switch.sonoff_MACADDRESS
- service: notify.notify
data_template:
message: >-
Pool Pump Off {{ states('sensor.net_power') }} Watts and {{
states('weather.home') }}
mode: single
What if the pump ran for 4 hours during the day? Will the automation then run it for another 5 hours from 2-7am? I think your original timer method would have only run the pump for 1 hour at 2am.
Also, if the 7am trigger is fulfilled, why doesn’t the “after 7am” condition stop the pump turning off? Or is it that by the time it evaluates that condition it’s a tick after 7am?
Yeah there are many ways this can be used.
1st way is to use a rolling 24 hour counter from now() like I have done so I can see the value continually go up and down as use increases or decreases throughout the day.
The second way is to evaluate the last 24 hours from midnight. This means it only evaluates and updates the value and graph once a day and effectively reports how long it ran for yesterday.
Yesterday: ends today at 00:00, lasts 24 hours.
end: "{{ now().replace(hour=0, minute=0, second=0) }}"
duration:
hours: 24
I could have just as easily used that method in my code but instead chose to go for a sensor that goes up and down for better visibility.
As long as I have this as a condition, it will choose to either run or not run the automation depending if it has run for 5 hours in the last 24 hours.
- condition: template
value_template: '{{ states(''sensor.pool_pump_duration_24h'') | float < 5 }}'
This could also be used as a trigger so that as soon as it dips below 5 hours, it will turn on. I didn’t want to use it that way though.
What prompted me to do this was that I found the solar forecast would start strong and then drop dramatically after my 2am trigger and then the window to cheaply run the pool pump had closed for the day if it was a crappy weather day. I found the performance of that last 24 hours was more reliable so that why I made the 2 conditions into an OR statement. The OR statement means that to only need 1 condition to be true so that even if the solarforcast gets worse after 2am, I can still make up for it if was a crap weather day yesterday.
Thanks for all the detail. I’m not sure that sheds any light on my previous concerns though:
It would seem that, if you had a mediocre weather day, but the pump still ran for, say, 4 hours, then at 2am the automation runs the pump for another 5 hours until 7am, when you could really only run it for an hour. I’m probably missing something basic!
And I still don’t understand how the “after 7am” condition works when the automation is triggered at 7am.
Very much appreciate all the explaining you’re doing!
Ah now I get where you are coming from.
Yeah I think that was just a choice I made to commit to a full 5 hours at 2am because of how unreliable the timer was. if I had rebooted HA the day before while the timer was running, the timer would not resume on reboot, so this was my old way of ignoring that when I used the timer.
I’ve only set the history stats sensor up 2 days ago, so all I have to do now is modify the automation that stops the pool pump and add a trigger to turn off when duration over last 24 hours (greater than) > 5 and remove the after 7am condition and the sun above horizon condition and it will stop after 5 hours in the last 24 any time of day.
That was there as I wanted to force the full 5 hours from 2am to 7am.
I’m still evaluating what works for me.
I suppose I’d rather have the minimum 5 hours in 1 hit rather than small blocks through the day on a poor weather day that may not even reach the full 5 hours.
I think I understand what you mean. I think I originally had after 6:58am and while the sun is above horizon to stop the grid import > 100w for 5 mins stopping the pump before 7am as the solar panels aren’t generating a lot of power at that time.
I have possibly confused things by covering 2 triggers in the same automation and then also having multiple conditions. Some conditions are meant to stop the grid import from triggering the stop. Other conditions are to force the full 5 hours.
I’m no authority on how to do it right. Just tinkering and fine tuning as I go. I only got home assistant in June 2021 and have just been thinking about things I want to automate and then testing possible solutions. It’s always a work in progress so to speak. But as I get more experience, the less I have to tinker and the more it can look after itself.
Once I have the pool automation sorted successfully, I’ll post it up again
Great. We’re on the same page now. I’ve had HA for only a couple of months, so still SO MUCH to learn. But every example you post has taught me something, and even whole platforms I didn’t know existed. HA is mind-blowingly flexible, and I haven’t even started adding all the other stuff I have (blinds, lights, fans etc) to it yet. They were all in Homekit/Homebridge, but I reckon HA is the go for everything now, with probably the Homekit bridge so I can use Siri for some actions.
BTW, how have you found Oziee’s Solcast integration? I’m still using the REST sensor implementation.
When I first found it, it was unstable and I felt like a beta tester in the beginning. But since the latest version, it has been rock solid since 10 nov so a month now and have been happy with it.
1 Like
That’s the thing. Being able to visualise and then articulate what you want solved and then being able to research and test a solution. That’s how I’ve learnt - out of desperation 
For example, I only found that history statistics sensor after looking at this in my energy dashboard
and wondering if I could reference that value in an automation. Did some googling which led me to history statistics.
Essentially I did change direction from wanting kWh in last 24 hours to now wanting just how long state was on for in last 24 hours which ended up being better
I’ll have to give it another try. I only tried it early on. The REST-based method has a lot more sensors I think, but most I don’t need. It would be nice to have the forecast integrated with Energy.
Yeh, that’s a really interesting one. Could be very useful! Now we just have to get the stupid situation with Envoy firmware sorted out!
1 Like