Maybe save the state of loadshedding and the time of the previous API call and see from that to current time if you in LS then set a flag to indicate that. Timer will clear the flag at end of LS?
Now you know if it is currently LS or not.
Groetnis
Maybe save the state of loadshedding and the time of the previous API call and see from that to current time if you in LS then set a flag to indicate that. Timer will clear the flag at end of LS?
Now you know if it is currently LS or not.
Groetnis
Updated version:
It now correctly reports that Iâm in a LS event, not sure if they move on at some point? Will see what happens.
I did change the eskomsepush to a timestamp with the time it was last updated
Looking good there!
Once you happy, would you mind sharing the code and a short description of how to get it into HA please?
Groetnis
Sure thing, will post the latest code the weekend. The earlier stuff is the essence, but Iâll post some tweaks.
That really looks good for a nightâs work.
Please can you make the code agnostic enough to be used nationwide?
It should already be Just figure out your area ID once using this: EskomSePush Business API 2.0 (getpostman.com) and then change "<your area id here>"
to yours
The only part that I havenât captured is the load-shedding stage for Cape Town - I live in Pretoria so not too much of a problem for me (EskomSePushâs API can give it to you though). And because of the API call limits for personal use, I rely on the Eskom sensor to get as many LS status updates that I need.
Forgive me, but what is the âEskom sensorâ? Maybe itâs something that every Saffer knows about, but Iâve been abroad a long time.
HomeAssistant models the thing as a âSensorâ. So he probably means the one that has name: EskomSePush
in it
Yes in my case its the neighbors generator.
But all south Africans know now that 3 times a day your faulty wall plug wont shock you.
In my case that is a fairly unreliable measure. My neighbour is a very frugal man. Let me explain, he is probably the kind of person who turns the gas flame off when he turns over the bacon. The Zimbabwean âcontractorâ who is painting at my place gave him his business card, and he remarked that âit is not time yetâ⌠despite the fall facing my side being so clearly in need of paint that Iâve considered paying for it⌠just so I donât have to look at the thing. Anyway⌠based on this, the petrol generator isnât always in the best working state, and even when it is, he will sometimes simply not start it. Which is not a bad thing⌠the drone of a petrol generator with that slight misfire every 7-11 seconds⌠not the most musical thing
Haha, sorry, I meant this one: eskom_loadshedding_status
This one reads the loadshedding status directly from Eskom. Unlike the EskomSePush one it doesnât have an API limit, so I can hit it more often to see if the national status change. When it changes, I can trigger an update to the EskomSePush sensor to see if my scheduled loadshedding changes.
The latter is done via an automation, that looks like this:
- id: '1663278849966'
alias: Update EskomSePush Sensors when loadshedding status changes
description: ''
trigger:
- platform: state
entity_id:
- sensor.eskom_loadshedding_status
condition: []
action:
- service: homeassistant.update_entity
data: {}
target:
entity_id: sensor.eskomsepush
mode: single
So the Eskom sensor updates every 180 seconds (3 mins) while the EskomSePush sensor (REST) updates every 3600 seconds (1 hour). Since the EskomSePush API gives you 50 calls a day, it means I spend 24 of those on getting the scheduled LS activities every hour, while the rest are reserved for updates when loadshedding changes.
The other EskomSePush call (also REST) called EskomSePushAllowance
doesnât count towards the API according to their docs, but also refreshes once an hour to get the number of API calls I have remaining.
This makes sense, and optimises your notice period.
Can this functionality also be solely achieved within Node-Red?
There are many horror stories of HA being unreliable due to updates.
( And quite frankly Node-RED already scares me, but I have been lucky in cobbling bits of other peoplesâ jsons together).
Donât know - I havenât used NodeRed before!
Shows you what I know, I thought that was a Node-RED dashboard you made.
No worries, but yeah, all standard Home Assistant dashboards.
I am still trying to figure out how I could best make use of this new API.
Currently, I only use it to show the upcoming slots.
Just using solcast pv forecast and having that adjust the DoD for the batteries, is enough to keep the batteries ready for any situation. So yesterday we didnt have much pv forecasted, so batteries didnât get discharged too much. Here is a quick view of the last 24 hours:
And right now, its charging again (its not even 9am yet, where the good stuff starts for me in CPT):
The only thing I can think off, is to figure out maybe what to do about 4-8am slots for now, but generally I am already covered for that.
So my system now basically:
The one thing I havenât been able to do yet is to run the geyser when thereâs excess power available and batteries are full and the solar geyserâs temperature is too low. It does this already but if the batteries are full during LS it wonât try again when Eskom comes back (geyser are on the non essential side).
I have a manual âdoomsdayâ switch that Jaco installed for me a little earlier the year. It is good enough for me and have saved me quite a bit of money already during LS. During loadshedding I can flick the switch an run the geysers, pool pump, oven, scullery etc. should the sun allows. If Iâm not home, Iâd rather not do it due to inability to control loads and unreliability of the sun on cloudy/rainy days. Donât want to run those off the battery, no real point. My battery wasnât sized according to non-essentials.
Maybe you can get an automatic/wifi âdoomsdayâ relay to use in automations.
Sounds cool. Will have to speak to Jaco about something similar at my place for my borehole especially.
I used these alot at my previous house ⌠work a treat! Donât take up alot of space and not to expensive.