I concur, that if ESKOM is in a load-shedding mood, then set “Keep batteries charged” and revisit the setting in happier times.
The reliability of ESKOM x the reliability of an API x the reliability of automated software doesn’t compute to a reliable solution.
Resources spent trying to squeeze the last % out of the system by automation are better spent on another couple of panels.
Yes, and then also no.
Conclusion I came to, on certain days, no matter how many panels one has, it simply ain’t enough.
Here are some of those days in the last 30 days.
I burn around 5%/h when the house is idling with no large loads. So I set an extra 10% reserve in SoD when levels 1-3, and 20% extra for levels 4+. ESS auto-recharge will save my skin if it drops too low below the set SoC so ill be good enough for morning to ride it out.
That being said ESS with battery life has been keeping my battery around 40-50% as the panels are struggling during winter. This aggressive load shedding has caused me to also make a lot of tweaks to my system.
It goes without saying that any automation will have to deal with the same issue.
The “Keep batteries charged” setting uses the grid to charge in the absence of solar power.
Case point, off from 6pm-8h30pm, now I see we are also off from 00:00 to 2h30 again, dam must be empty again.
AND there is a new cold front coming in tomorrow, probably for a few days, week.
Bugger this, back to Keep Charged.
Jissie, this is starting to cost some serious bucks now, thank heavens we don’t have to also pay the new fuel price to and from work…
I’m only seeing the cold front from Thursday… really hope it doesn’t start earlier…
And we should be back to stage 2 before midnight, and therefore only getting shedded by 08:00 tomorrow morning. Anyways! It is too complicated staying up to date with these variable levels. I just set my min SoC to 50%. At stage 6 we get 4 hours. At worst, assuming I’m at min SoC and zero sun, I use 5% an hour (at worst). So that gives me 10% of safety margin (at worst).
So I’ve used the “set it and forget it” strategy. And I maybe pay one unit of electricity oer day for it. Maybe.
Same here. When we hit stage 4 or higher, I set “Keep Batteries Charged” and then, because all the large loads are bunched up in fewer hours anyway (eg pool pump, geysers, etc), I don’t lose that much due to full batteries anyway. What is lost is an acceptable cost for the luxury.
I use home assistant with solcast solar forecast which is far more accurate than built-in forecast for cloudy days. Based on the solar forecast, the DoD is set at 8PM and again every update between midnight and 6AM.
This means, that generally, battery is only used over night if the next day is full sunshine. For in-between, the DoD is set according to what I expect to be able to recharge the next day after baseload and load used solar first.
With this, I generally just dont have to worry at all about morning loadsheds. It may sound like I dont save as much from not using grid as others, but I do after tweaking it a lot. It is just delayed. Savings is ± the same.
I also have the forecast on my dashboard, like so:
I found this was the best way to deal with SoC/DoD and CoCT loadshedding. I gave up on CoCTs crazy stints.
The other work-arounds was to get geysers to run as much during sun hours, that was more of a mission but it is almost 99% sorted now.
@tinuva which extension are you using for Solcast integration? Mine is fairly dated and a bit broken at the moment.
Thanks all for the comments - I am going to implement changes to keep the minimum SOC higher when loadshedding is present. 
@ebendl I will admit, I am a bit old-school, so its all yaml code
You can see the code on github: home-assistant-config/solcast_rest.yaml at master · tinuva/home-assistant-config · GitHub
I did it this way, so that I could create the forecast graph as you can see in the above screenshot. It allows me to extract more data into entities than is available using the different solcast integrations I tested.
Deleting this, as it was not working.
I have been using: https://loadshedding.eskom.co.za/LoadShedding/GetStatus and so far pretty accurate. It only updates when the LS stage changes so you can’t use it to forecast.
Finally got it working with Node Red and I can now set my Min SOC to a level based on Stage which is working perfectly. Or manually overide if needed (using a Telegram integration).
It says “5” now, but Eskom is on 4?
Edit: Yoh, that’s some terrible Javascript. Anyways:
Finally got the CoCT loadshedding apps’ endpoint. Now we can get the correct current CoCT stage AND the time for the next stage, for those that want.
At this time, this is Eskom:
% curl 'https://loadshedding.eskom.co.za/LoadShedding/GetStatus?'
4
Eg. eskom on stage 3
[
{
"currentStage": 2,
"startTime": "2022-07-09T07:00",
"nextStage": 3,
"nextStageStartTime": "2022-07-09T22:00",
"lastUpdated": "2022-07-09T07:02:16.000Z"
}
]
Show CoCT on stage 2 and that stage3 will start at 10pm
Not that I need it anymore, but I finally figured out how to get the correct CoCT loadshedding stage into HA.
Attributes even include when the next stage and what stage that will be. Eg. for today, CoCT is mostly on stage2 until 10pm at which time it goes to stage3. The history on the sensor is wrong, because it used to be a template that was hardcoded, but I now found the CoCT loadshedding app’s endpoint.
Ok I created it into a HACS addon for those that want it.
Add it as a custom repository to HACS and you will be able to install it.
After adding it under integrations, then go back and configure your area, to enable the “next loadshedding slot”.
The only part that needs to be fixed, is to take into account the next stage change, which it currently doesn’t, but that should fix the issue for those that want that ability in HA.
