Adjusting Reserve to manage charging to avoid Peak ToU Tariff

[BJReplay]

Now that we're getting close to winter, my control algorithm is working hard, and for the first time, I'm seeing what it is doing tracked on the Powerwall Dashboard.

P.S. I've been quiet on this forum as I've been away for six weeks - only just back from a road trip in WA (Western Australia, not Washington State in the USA).

This chart shows the algorithm setting the reserve to 30% (27% after accounting for the 5% hidden reserve) at the end of Peak at 9pm last night) which was the calculated reserve required to avoid needing to charge to reach the end of peak today, based on the expected insolation today, and the expected consumption from sunrise through to end of peak.

In other words, if the battery had 30% charge at sunrise, and the insolation was as forecast, it should get through to the end of peak with 5% remaining.

However, things never go to plan, do they?

This morning was particularly foggy, so the forecast insolation had reduced and the Solcast forecast knew this by 7am, so the control algorithm had already decided by 7am that forecast insolation wasn't going to cut it. The shortfall was such that the required charge had increased to 33%, and this forced the Powerwall to start charging.

Throughout the morning, you can see the impact of updated forecasts changing the required charge level, until 10:25, when another increase forces charging again.

Note that the forecast insolation line is the latest forecast - it would be interesting to show the evolution of forecasts, but that's an exercise for another day.

Consumption estimates are based on the same time last year - the two weeks prior to the current day and the two weeks ahead of the current day, as well as the last two weeks of this year (so, in a way, very crude machine learning - same time last year adjusted for recent experience). It's very simple, but actually all you need, as it turns out, and a lot simpler than complex ML or AI. For example, today it is using consumption from 30 April 2022 to 27 May 2022, as well as 29 April 2023 to 12 May 2023.

For the sake of load (household consumption) forecasting, it breaks it down into three periods: Sunrise to start of Peak, Peak ToU, and Off-Peak to Sunrise. The reason for that is that it plans to either standby or discharge overnight (depending on capacity and forecast insolation) with a tendency to standby in winter and discharge in summer, and needs to consider all load during solar hours to know whether the insolation will be enough to charge the battery enough to see the household load through to the end of peak, including load before peak and during peak.

Anyway, in summary, the process works well, rarely over-charges (so doesn't spend a lot on grid energy that is unnecessary), and extremely rarely under-charges (so very rarely has to spend on Peak ToU rates).

On my (distant) to do list is considering whether I can use the history in Powerwall Dashboard InfluxDB instead of my Azure SQL Server database as the source for historical consumption data, and thus whether the charging prediction can be brought into the Powerwall Dashboard tools universe.

[jasonacox]

On my (distant) to do list is considering whether I can use the history in Powerwall Dashboard InfluxDB instead of my Azure SQL Server database as the source for historical consumption data, and thus whether the charging prediction can be brought into the Powerwall Dashboard tools universe.

I'll 👍 that. 😂

This is awesome @BJReplay - thanks for sharing!

[OzBrown]

I have just found this Project, which I am really enjoying, got it up and running today. The reason I was looking for a way to control the Powerwall Reserve on a Time bases, As in Victoria we have a Plan for Charging EV's from AGL that starts at 12 midnight and runs to 6am with the Power costing 8cents a kWh. So was looking to see how I can lift the Reserve to 100% if the next day was Poor weather or Cloudy.

Would it be possible to discuss how you control the Reserve, so I can jump in and see how to start looking. Also looking at TOD (time of Day) costs and EV Charging Costs.

[BJReplay]

Long story short, it's an authorised post to the same API that the app on your phone uses to adjust the reserve - https://owner-api.teslamotors.com/api/1/energy_sites/YOUR_SITE_ID/backup/ with the desired reserve setting.

There's a fair bit more to it than that, but https://github.com/jasonacox/Powerwall-Dashboard/blob/main/tools/tesla-history/tesla-history.py gives you an idea of how to do the authentication and identifying sites in python - as it uses the same API to get your history to populate the influxDB for this project using the same API.

Here it is adjusting the reserve in the lead up to peak yesterday afternoon:

There was no real need - sunny day - but if we'd had loads come in, it would have preserved charge for the afternoon peak and used grid during the day.

[jasonacox]

Hi @OzBrown ! Thanks for the post and comment!

I use the set-reserve.py script to change the reserve setting on my Powerwall based on time of year, time of day, charge level and cloudiness. See the cron.sh script.