What would happen if...

[Stephen2615]

Greetings,

My Powerwall 2 is part of, but not managed by a VPP. It basically has nothing to do with the VPP provider but I think it was necessary to get the government to subsidise the Powerwall. The VPP provider was known to use some method of forecasting the weather to tell the battery to charge at night if the next day looked cloudy or something like that, especially in winter. I never found out whether Tesla or the VPP provider causes the battery to charge using off peak power.

In winter, we basically get fog for at least 70% of the nights but the online weather forecast doesn't recognise it as cloud. So the battery won't charge from off peak and the sun doesn't burn through the fog until midday sometimes so we do not get a fully charged battery.

I trained a sky model where I have a small camera look at the sky at night and if it recognises "overcast clouds", it can send an mqtt message to tell whatever, the sky is probably foggy as it compares openweather.org forecast (again which doesn't know about localised fog). If Telsa or the VPP provider intends to charge the battery because of cloud, they usually start by 11 pm.

If using the set-reserve.py to 100 say at 11:30 pm to force charge the battery, does this cause any problems if the algorithm that Tesla or the VPP provider decides to charge the battery at the same time. I would prefer not to have any charging conflict it is a problem.

I hope this makes some sense.

TIA!

Stephen

[JohnJ9ml]

This does make sense to me. I have been on a similar pathway this past week - tangential, but messing with some of the same factors.

I'm on a PW3 setup, but I think the factors are quite the same. As far as I can tell, the Tesla-triggered Storm Watch logic to decide to charge seems to be processed purely in the mother ship, and I suspect there is some polling by the gateway / primary PW that learns of there being a relevant NWS alert. Its decision seems to be purely to push the desired limit to 100%.

My VPP request is still awaiting evaluation, but I suspect it is a similar approach: they decide the time is right, something is set centrally that is polled by the PW, and then it pushes to 100%. My sense is that there is no determination as to where the current setting is to decide whether or not to follow through. Opting out of a Storm Watch event can only be done from the Tesla app, and I have not as yet located any state or alert inside the data being pulled by the API that shows a storm event is active. In short, I'm not sure you could tell yourself - nor could they - that something else had decided to push the battery setting to 100%.

Over the past week, I've been taking the solar forecast from SolCast, applying some math, and determining whether battery level + today's charging - normal use leaves me with battery before the sun hits the panels tomorrow (calculating worst case as well). I just put this in place a couple days ago, but haven't had time to do the last bit of deciding to throttle the battery setting.

The one last bit that I have yet to incorporate is taking the historical actuals data from SolCast and then applying it to see how well the forecast did, how well my panels performed compared to the forecast, and see if I can determine some fudge factor I need to be applying. Obviously, historically knowing there was fog doesn't help a forecast much, and your camera approach is rather interesting and intriguing, but SolCast's actuals data promises to be rather impressive, as they incorporate cloud conditions at a pretty fine granularity.

The one thing that I do think your thrashing around the reserve setting might impact is the learning data for time-based use. Gut feeling thus far, since I've only been playing with this for a couple of weeks, but after a couple weeks of running set at 20%, the system seemed to have developed a good sense of how to handle the night time hours - whether to use the battery or run the house from the grid for part of the night. Since I've been playing with the reserve a couple of days, it seems as though maybe it jettisoned all that historical data and is starting again from scratch - odd decisions the system made the first week with PTO now seem to have returned as soon as the reserve is played with. Perhaps it wouldn't dump the historical data when it knows the change is a temporary one that it made due to polling a central place.

[JohnJ9ml]

One other idea here:

As I intimated, I've been playing around the last week trying to develop some code to do projections based upon solar forecasts of generation combined with current battery levels and means for usage to the morning. Today is a rainy day, combined with fog in the morning.

I'd been looking at the Storm Watch functionality in the app, and there is the ability to 'schedule" your own personal Storm Watch event. Alas, it's a bit silly, because the only thing you can do is create schedule that starts "now" and then set a duration (in hours). I so wish it were possible to schedule one later so that it could, for example, start after midnight when the rates were again low.

In spite of its weaknesses in scheduling, I could tell from my calculations that I was not going to end up with enough battery to make the morning (just as a security blanket), and I was going to force charge some before 3pm. Today, rather than playing with my time-based settings, I decided I'd schedule a storm watch event lasting an hour (that's really all I needed to get through an average night). I have it running now, and it's been pushing roughly 7kW into the batteries. It didn't go mad and run at 12-14kW as I've seen it during a big storm watch trigger, but I'm pretty certain this won't cause the system to discard any history it's built up, and if a legitimate event came along such as a storm or VPP, I trust that since this is triggered in the same manner as those events, they'd work it out themselves whose event ended last.

[Stephen2615]

@JohnJ9ml

I was talking to a Tesla person some time ago about something and he said that I was fiddling with the settings changing the backup reserve on the app. He said it takes two weeks to adjust a baseline to get max self generated power to the house. He basically said it was not a good idea. I never force charge during the non winter months but winter is another story and I want a full battery in the morning as I am effectively using off peak power instead of peak and shoulder.

I don't care about the algorithm during winter. I can barely charge the battery to 100% in winter even with sunny skies all day and I have plenty of PVs on the roof. Self consumption has priority over battery charge and as we are at home doing stuff, the battery charge is dependent on what we do.

Another thing that I noticed with my VPP provider is that they somehow have access to some parts of the app and the end user can't do some of the settings. I discovered that when someone asked me to change something and it wasn't there. That might just be misinformation but it was something that I noted.