No issues on my side – cards still works as intended (not the mushroom template cards though but similar templating).
I don’t think I changed anything, but here’s my latest cards:
Card 1:
type: custom:mushroom-template-card
primary: Upcoming loadshedding slots
icon: mdi:power-plug-off-outline
multiline_secondary: true
secondary: >
{%- for event in states['sensor.eskomsepush'].attributes.events -%} {{
as_timestamp(event['start']) | timestamp_custom('%a\t%Y-%m-%d \t%I:%M %p\t')
}}➡{{ as_timestamp(event['end']) | timestamp_custom('\t%I:%M %p\t') }}
({{event['note']}}) {{- '\n' -}} {%- endfor -%}
icon_color: red
Card 2:
type: custom:mushroom-template-card
primary: Upcoming loadshedding stages
icon: mdi:guy-fawkes-mask
multiline_secondary: true
secondary: |2-
{%- for event in states['sensor.eskomsepushstatus'].attributes.status.capetown.next_stages -%} {{
as_timestamp(event['stage_start_timestamp']) | timestamp_custom('%a\t%Y-%m-%d %H:%M\t') }}➡{% if loop.index < loop.length %}{{ as_timestamp(loop.nextitem['stage_start_timestamp']) | timestamp_custom('\t%a\t%Y-%m-%d %H:%M') }}{% else %}{{'\t\t\t\t\t\t '}}
{%- endif -%}{{'\t:\t\t'}}{{ event['stage'] }}{{'\n'}}
{%- endfor -%}
fill_container: true
icon_color: orange
badge_icon: ''
and the Rest sensors:
rest:
- resource: "https://developer.sepush.co.za/business/2.0/area"
scan_interval: '02:00:00' # RATE LIMIT!
headers:
Token: !secret EskomSePushToken
params:
id: "capetown-9-pinelands"
#id: "<your area id here>"
sensor:
- name: EskomSePush
unique_id: eskomsepush
force_update: true
value_template: "OK"
json_attributes:
- events
- info
- schedule
- resource: "https://developer.sepush.co.za/business/2.0/status"
scan_interval: '02:00:00' # RATE LIMIT!
headers:
Token: !secret EskomSePushToken
sensor:
- name: EskomSePushStatus
unique_id: eskomsepushstatus
force_update: true
value_template: "OK"
json_attributes:
- status
2 Likes
The signup is super easy.
You get the new token immediately, paste into secrets, and you’re done.
Thanks! The only thing I changed was “capetown” to “eskom” in the attributes.
Oh sorry, I see my mistake! The token is required under each sensor, amateur mistake! Thanks for helping me get there though!
1 Like
What’s up with the Eskom “API”?
It switches between stages 1 and 2 constantly. Well at least the last 2 hours.
Edit: aaw bummer. My automation to refresh EskomSePush with every Eskom status change backfired and now I’m out of API requests.
1 Like
Eskom blocks requests to get the current status for loadshedding unless its browser with cookies…
I have never found the eskom API to be reliable
$ vi public_html/LoadShedding/GetStatus
r3
:wq
Maybe the guy who does that made a typo… if they are even running Linux and using vim 
I’m getting the same issue with the mushroom card, it works fine when there is loadshedding level 1+ but when there is no loadshedding it seems the sensor then reports unavailable which I suspect is causing the issue, not a software guy so no idea how to fix it, maybe one of the clever guys on the forum could point me in the right direction 
#-----------------------------------------------------------
## Eskomsepush Loadshedding Schedule
#-----------------------------------------------------------
- platform: rest
name: EskomSePushStatus
resource: "https://developer.sepush.co.za/business/2.0/status"
scan_interval: '02:00:00' # RATE LIMIT!
headers:
Token: !secret EskomSePush
unique_id: eskomsepushstatus
force_update: true
value_template: "OK"
json_attributes:
- status
#-----------------------------------------------------------
## Eskomsepush area sensor
#-----------------------------------------------------------
- platform: rest
name: EskomSePush
resource: "https://developer.sepush.co.za/business/2.0/area"
headers:
Token: !secret EskomSePush
params:
id: "capetown-11-constantia"
json_attributes:
- events
- info
- schedule
value_template: "OK"
scan_interval: '01:00:00' # RATE LIMIT!
#-----------------------------------------------------------
## Eskomsepush allowance (50 calls per day) sensors
#-----------------------------------------------------------
- platform: rest
name: EskomSePushAllowance
resource: "https://developer.sepush.co.za/business/2.0/api_allowance"
headers:
Token: !secret EskomSePush
json_attributes_path: "$.allowance"
json_attributes:
- count
- limit
- type
value_template: "OK"
scan_interval: 3600
#-----------------------------------------------------------
## Template sensors are based on ESP above
#-----------------------------------------------------------
- platform: template
sensors:
next_loadshedding_time:
friendly_name: Next loadshedding time
device_class: timestamp
unique_id: Next_Loadshedding_Time
value_template: "{{ state_attr('sensor.eskomsepush','events')[0].start }}"
next_loadshedding_level:
friendly_name: Next loadshedding level
unique_id: Next_Loadshedding_Event
value_template: "{{ state_attr('sensor.eskomsepush','events')[0].note }}"
next_loadshedding_time_end:
friendly_name: Next loadshedding end time
unique_id: Next_Loadshedding_End_Time
device_class: timestamp
value_template: "{{ state_attr('sensor.eskomsepush','events')[0].end }}"
next_loadshedding_duration:
friendly_name: Next loadshedding duration
unique_id: Next_Loadshedding_Duration
unit_of_measurement: mins
value_template: '{{ [( as_timestamp(states.sensor.next_loadshedding_time_end.state) | int - as_timestamp(states.sensor.next_loadshedding_time.state) | int ) / 60,-1] | max | round(0) }}'
time_till_loadshedding:
friendly_name: Time until next loadshedding
unique_id: Time_Until_Next_Loadshedding
unit_of_measurement: mins
value_template: '{{ [( as_timestamp(states.sensor.next_loadshedding_time.state) | int - as_timestamp(now()) | int ) / 60,-1] | max | round(0) }}'
time_till_loadshedding_ends:
friendly_name: Time until next loadshedding ends
unique_id: Time_Until_Next_Loadshedding_ends
unit_of_measurement: mins
value_template: '{{ [( as_timestamp(states.sensor.next_loadshedding_time_end.state) | int - as_timestamp(now()) | int ) / 60,-1] | max | round(0) }}'
eskomsepush_calls_remaining:
friendly_name: EskomSePush API Calls remaining
unique_id: EskomSePush_calls_remaining
value_template: '{{ int(state_attr("sensor.eskomsepushallowance","limit")) - int(state_attr("sensor.eskomsepushallowance","count")) }}'
loadshedding_slot_forecast:
friendly_name: Loadshedding slot forecast
unique_id: loadshedding_slot_forecast
value_template: >
{%- for event in states['sensor.eskomsepush'].attributes.events -%} {{
as_timestamp(event['start']) | timestamp_custom('%a %d %b:') }} {{ event['note'] }} {{
as_timestamp(event['start']) | timestamp_custom('from %H:%M') }} to {{
as_timestamp(event['end']) | timestamp_custom('%H:%M') }}
{{- '\n' -}} {%- endfor -%}
The reason why it breaks is because it is looking for first event (event [0]) in the list of events. When there’s no events, there’s no 0, 1, 2 etc.
I fixed mine with something like this – first check if the number of events are bigger than 0, then use the first. IF not, set it to Unknown.
next_loadshedding_time:
friendly_name: Next loadshedding time
device_class: timestamp
unique_id: Next_Loadshedding_Time
value_template: >
{%if state_attr('sensor.eskomsepush','events')|count > 0 %}
{{state_attr('sensor.eskomsepush','events')[0].start }}
{%else%}
Unknown
{%endif%}
I’m not sure that’s exactly true.
My code (as posted) produces this UI with no upcoming slots:
I will say that I was seeing similar issues to @jatho the other day.
Have a look under “Developer tools” → “States”
Search for “eskom” and check that the REST sensor is getting data:
If it isn’t, a restart of HA can often sort it out (well, that’s what I eventually resorted to, and it did)
Mine is now displaying correctly but its only because there are upcoming loadshedding sessions, as soon as there aren’t any it displays as per my previous post because the sensor is in a state unknown. I’ve tried the reboot and it doesn’t have any effect.
I suspect that @ebendl’s suggestion may work so will try that, just need to wait until there are no upcoming stages to confirm.
Thanks for all of the input, much appreciated.
2 Likes
That actually looks like not all the machines serving that API where updated. As the load-balancer switches between them you get different answers.
Ask me how I know 
Haha… yes I’ve had that too. You design this beautiful setup… for us (previous job) it was always at least two Zope application servers, talking to a database with failover, with haproxy loadbalancing and varnish in front to cache the heck out of all the static content…
Updating was always interesting. Especially since Zope (which is to Python as Jboss is to Java) takes a while to start up and heat up the database caches…
I realise I must change this value to my own but how do I find the exact id for my area?
I tried various permutations …
Thanks
2 Likes
You can use the search endpoint: EskomSePush API 2.0