Enhancement: show "reserve" setting in main graph

[mp09]

Enhancement: show "reserve" setting in main graph

I modify the reserve setting a lot depending on weather to support being self-powered as much as possible (but still having safety buffer in case of an outage that I know I can recover the next day based on Solar).

It would be useful to know what the setting is/was when doing some analysis and looking at the graph.

I know the main graph is pretty busy, so not sure how best to incorporate this.

[jasonacox]

Thats a good request @mp09 ! I have a script that I use to monitor my system and adjust the reserve to ensure I don't use any grid power during our peak TOU. 😁 It would be nice to see what settings it is using and how it trends throughout the day, etc.

Thankfully, we have telegraf polling for that data already via http://pypowerwall:8675/pod:

{ "backup_reserve_percent": 20.0 }

I used that set it up on the main (busy) display:

The query:

With these overrides:

But there is a problem. Currently backup_reserve_percent is only set for a 3 day retention. If we want to keep it around longer than that, we will need to create a continuous query (CQ) to downsample the data and store it in one of the infinite retention policy buckets.

Let me know what you think or would want to see.

[BJReplay]

Great idea.

I have a script (OK, I'll admit it, it's a windows service written in VB.Net) that manages my SoC for me. For about 8 months of the year, it sits there twiddling its virtual thumbs, but in winter it gets a workout when I don't have enough sun to charge the Powerwall to see me through peak.

That's when the service charges from the grid, based on Solcast insolation forecasts, Peak consumption load forecast, and current SoC.

Right now it outputs its plans to a PowerBI (that's where it is also streaming live data - a bit of a legacy which I haven't shut down) page formatted to display on my phone, which includes the charge plan:

What should be happening as charging is required is that the Backup Reserve should be increasing to the Required SOC to force the Powerwall to charge from the grid, ahead of the commencement of Peak at 3pm.

So showing SOC on the chart will be really helpful.

The other thing that the service does is if tomorrow's insolation is unlikely to be enough to meet both peak and off-peak consumption, it puts the Powerwall into standby - by setting the backup reserve to the current SoC. That avoids wasting the roughly 10% of energy lost in round trip losses that would otherwise be lost discharging the battery, only to re-charge it later.

So, for me, I can solve my immediate need immediately, by adding the Reserve Setting to the graph.

But, as with all things, it would be nice, in hindsight, to know what the setting was back in time, so a CQ would sort of be nice, but really of minimal interest. I know, after five year, that my algorithm gets it pretty right. It rarely charges when it doesn't have to, it rarely charges too much (and exports at a far lower rate than the cost of grid supplied power), and rarely charges too little (and needs to import expensive peak power).

In time, I'll probably replace PowerBI entirely, and also work out how to have the charge intent and load forecasts show up on the Powerwall Dashboard.

[jasonacox]

Awesome @BJReplay ! Are you willing to share your algorithm? 😁

I'll put in a TODO to add the CQ's for the Reserve setting.

*SOC = State of Charge and is represented on the "Energy Usage" graph as "Charge".

[BJReplay]

Are you willing to share your algorithm?

Ha, sort of. It's been open source for about five years 😉 https://github.com/BJReplay/PowerwallService

I'm running that version, but with some tweaks:

• I've pulled in a local copy of https://github.com/BJReplay/TeslaAuth forked from the excellent work that @tomhollander did with https://github.com/tomhollander/TeslaAuth to work around a library version clash.
• I'm running a version (not yet open source) that using heating degree days and cooling degree days (HDDs / CDDs) and weather forecast to adjust the forecast consumption. The main reason that's not open source is that it requires a decent regression model of your house's response to temperature to be usable, and that, in turn, needs a steady state or corrected consumption history.
• That has the effect of adding around 0.5kWh per 1°C above (in summer) or below (in winter) the maximum or minimum temperature on hot or cold days to the forecast peak load.
• That said, the load forecast is pretty good - it's the simplest same time last year adjusted by recent experience, and that turns out to be much better than anything more complex.
• What can throw it out is changing occupation (e.g. working from home - COVID19 for example), but the learning from recent experience factor relatively quickly corrects that.

I should add that some of the code isn't really open source because I haven't updated database creation scripts - there aren't a lot of users 🤣

e.g.

ALTER   FUNCTION [dbo].[fnGetMonthlyPeakLoad](@PeakStartHour AS INT, @PeakEndHour AS INT) RETURNS INT
AS
BEGIN
DECLARE @Peak INT;
WITH HourlyLoad as (SELECT DATEPART(HOUR, ObservationDateTimeLocal) as Hour, AVG(Load) As Load FROM CompactObsByMinute WHERE (ObservationDateTimeLocal BETWEEN DateAdd(WEEK, -54, GETDATE()) AND DateAdd(WEEK, -50, GETDATE()) OR ObservationDateTimeLocal BETWEEN DateAdd(WEEK, -2, GETDATE()) AND GETDATE()) GROUP BY DATEPART(HOUR, ObservationDateTimeLocal))
SELECT @Peak = SUM(Load) From HourlyLoad WHERE HOUR BETWEEN @PeakStartHour AND @PeakEndHour
RETURN @Peak
END

[aesculus]

Just noticed this for the first time as we had a multiple hour power outage last night and saw this today.

[jasonacox]

Nice!