That doesn’t sound good — I don’t have that error. I installed 1.0.0 manually.
I’m now on 1.0.1 which fixes the spelling mistakes, installed by HACS.
I’m just making sure my HA is up to date by doing a new docker pull.
There are a few of the files being updated so fingers crossed.
Well, it took HA about 15 minutes to start up, but all is well in the world now…
HA Update seemed to do the trick.
1 Like
So, I’ll fix the typo on the README now, Ive also opened an issue on the github repo to account for device changes.
The two are calculated inconsistently, the charge time is per-pod, with the energy being across all pods on the account. I’m going to make a new entity that is not attached to a device to track ‘total’ energy and then the existing sensors will change to tracking energy per-pod.
Apologies on the oversight, it will mean your energy drops significantly when the new version is release as the number is re-balanced
1 Like
This was related to me using a new API that was released as part of 2023.1 - just released a new version which calls out this dependency correctly to HACS and should prevent this issue in the future
I’ve been using this integration “in the background” for a while now, but a change of EV from a LEAF to an MG4 (excellent car, but as yet un-HA-able: the SAIC API work isn’t yet getting any useful info) has driven me to move the scheduling from the car to the Pod Point.
The Pod Point app is hopeless in this regard: although the scheduling functionality is there, there is no decent “charge now” override function, and it’s certainly not a solution my wife would be comfortable using should she need an emergency daytime charge.
My setup now involves a schedule helper (schedule.cheap_rate) set up through the UI for 00:30–04:30 daily to match the Octopus Go cheap rate; and an input_boolean (Toggle helper) for the override function. I then have a simple automation to enable or disable charging:
- alias: Pod Point - schedule manager
id: 30111f9f-6bab-495f-9a21-b357f16ab595
trigger:
- platform: state
entity_id:
- schedule.cheap_rate
- input_boolean.schedule_override
to:
- 'on'
- 'off'
action:
- service: switch.turn_{{ ['input_boolean.schedule_override','schedule.cheap_rate']|map('states')|max }}
entity_id: switch.psl_XXXXXX_charging_allowed
…which enables charging whenever the schedule or the override are on (the template is a compact or operation).
My front end looks like this, with the car still plugged in after an overnight charge and the “last charge” being a quick test of the override:
The status, override and current energy lines are only displayed if the cable is plugged in, using Lovelace conditional rows. Here it is after unplugging:
Many thanks @mattrayner for an excellent and useful integration!
EDIT: having found the delay to the Pod Point actually starting and stopping from the schedule, I created this template binary sensor that leads the “turn on” by 2 minutes; and the “turn off” by 4 minutes to try to get the maximum out of the cheap period without straying into peak time. At a guess, this will save about 10–15p per affected day. This sensor is used in place of the schedule in the above automation.
- name: cheap_rate_leading
unique_id: 13b7c7b1-2486-4d51-af1c-0ba2dccb6618
state: >
{{ iif(state_attr('schedule.cheap_rate', 'next_event')|as_timestamp(0) - now()|as_timestamp < [120, 240][bool(states('schedule.cheap_rate'))],
not(bool(states('schedule.cheap_rate'))),
bool(states('schedule.cheap_rate'))) }}
I’m glad it’s working out for you, and this is a great use case @Troon!
I’m going to look at the conditional rows 
Lovelace YAML for the first two rows:
- type: entities
entities:
- entity: binary_sensor.psl_XXXXXX_cable_status
name: Cable
secondary_info: last-updated
- type: conditional
conditions:
- entity: binary_sensor.psl_XXXXXX_cable_status
state: 'on'
row:
entity: sensor.psl_XXXXXX_status
name: Status
1 Like
I am new to Home Assistant and interested in your extra Pod Point override and schedule option. I need some more help / description on how you have got this to work. Not used Schedule Helper or Toggle Helper before.
I can see to create a Schedule Helper called “schdule.cheap_rate” and configure it with the times 00:30 - 04:30, but then after that I need your help.
Thanks
Toggle helper setup is here: Input Boolean - Home Assistant . Call it Schedule override or you’ll need to adjust the automation below.
For the automation, create one using the UI (I do all of mine directly in YAML, but that’s beyond the scope of this post) with a state trigger and service action like this:
Then hit the three dots on the Action, choose Edit in YAML, and edit the line:
service: switch.turn_off
to
service: switch.turn_{{ ['input_boolean.schedule_override','schedule.cheap_rate']|map('states')|max }}
Save it and you should be done.
This looks brilliant.
Is it possible to use something like this to monitor whether a public charger is in use or not? Would like to be able to receive a notification when the charger at my work (which is open to public) is free or not?
Thanks for an excellent integration. Installed without trouble via HACs and all working - potentially going to be a great fix for an issue I have charging EV when my Powerwall battery is set to Self-Powered.
Briefly, I use self powered mode in summer so Powerwall is exclusively charged from Solar PV. Unfortunately charging an EV overnight flattens the battery meaning have to import grid energy until the sun shines again. Time-based control mode (I use it in winter) doesn’t have the problem as it always uses the grid during cheap rate times.
So now I can detect ‘charging’ and use the Powerwall integration to set the battery to time-based until charging is done. This integration saves me having to try and guess charging is taking place by looking at grid import.
Thanks again
PS do find it quite funny that Tesla don’t have good solution with powerwall for charging an EV - hey ho!
If you have a moment please can you explain what this line is doing/how it works?
I can see it is going to result in either a switch.turn_on or switch.turn_off but how?
Appreciate you sharing - cheers
It works as an OR statement, just a bit shorter than writing it out normally. I’ve put the two entity names I want to consider into a list. The map then turns that into a list (strictly a generator, but don’t worry about that) of their states, and the max returns the largest value — in the case of strings, the latest string alphabetically.
Because the values should only be 'on' or 'off', it’ll return 'on' if there is one in the list, otherwise 'off'.
1 Like
A pod point update - wonders will never cease!
A charge now button and manual charge mode have appeared.
Just an fyi
1 Like
This post here: Podpoint rate of charge modification for Solar PV - #3 by Ant-6009
Suggests the charge rate is setable by the API
This would be a useful function if it could be supported.
My board doesn’t have the DIP switches.
I’ve had a look into this and the manual/smart/charge now functionality can definitely be added to the integration 
I’ll take a look over the next week or so and get it in
@StephenMilner I don’t have a pod with the API changeable rates, do you see an option in the app somewhere? If so, are you able to send some screenshots?
That would be great, many thanks. Your integration works fine today but charge now is cleaner than taking over the schedule completely.
All good!
Just to clarify, and maybe even correct myself:
I can’t to the conclusion that it was possible to change the charging rate after reading the account of a user who couldn’t charge at more than 3.6kwh, complained about it to podpoint who remotely enabled 7kWh.
Further to this, I have observed than when solar panels generate more than 3.2kW (or thereabouts), the charger will try it’s best to limit the charge to 3.6kW or so.
I came to the conclusion, perhaps wrongly, that this must be achieved throughout the API.