Integration status does not reflect actual status of pod point about pod-point-home-assistant-component

[townsmcp]

This wouldn’t be an integration issue. As you can see from the following link, UK regulations came into effect 30th June 22 to protect the grid, specifically look at point 3. If all PodPoints allowed charging to take place immediately rather than a staggered start the grid could potentially collapse under the strain of all Pods surging the grid and calling for power at the same time

See https://pod-point.com/electric-car-news/smart-chargepoint-regs

From the link it appears you could temporarily override the delay by disabling the scheduling on the app

[Marky0]

This wouldn’t be an integration issue. As you can see from the following link,

Thanks I didn't know about this. But I'm not trying to circumvent the delay. I just want HA to accurately show when my pod-point is enabled. OK if pod-point has to randomise the turn on, that now makes sense, but the HA integration shouldn't indicate that the pod-point is "charging" until charging actually starts.

[townsmcp]

@Marky0 i agree with you fully, it really shouldn’t show charging unless it’s actually charging. Sadly this would be down to the PodPoint API as technically it should be charging even though it isn’t. You can observe it in the app - it shows up charging however the light on the pod isn’t reflecting the pod actually doing a charge. I got caught out on this a few times with head scratching moments of sending charge command via the app while standing next to the pod and wondering why nothing is happening. Then I stumbled on the regs link. I very much doubt PodPoint will change the api to reflect what it actually happening.

A thought occurs to utilise the PodPoint status sensor and current_energy sensor increasing to give you the info you are looking for? As long as current_energy is increasing you know charge is actually going to the car? I guess an input boolean might be able to be added to the integration to reflect this? Alternatively, do you have an integration from your car and an input boolean that changes state when charge is going to the car?

[mattrayner]

Hi @Marky0, unfortunately @townsmcp is correct. There are two separate 'issues' here that cause the behavior you are seeing (which, to be clear, is expected by Pod Point)

1. The pods themselves only 'pass' data back and forth from the APIs at an interval so schedule updates are not instant, with up to 10 minutes before it is reflected on your device (this is by design on the Pod Point side, so not something we can help with. This is the 'root cause' of this notice the bottom of page 14 in the Pod Point solo documentation. This interval accounts for a delay in stopping charging when you 'switch off' the charge through the HA integration, as well as exacerbating point 2.

Note: additional to the delay in your pod updating the charge schedule, if your vehicle is already connected and you transition from out of schedule to in schedule a randomized delay is added to your charge time (see point 2 below)

2. The new government legislation - If you transition from outside of a charge window, into a charge window (or vice versa) through scheduling AND your vehicle is connected during the transition a randomized delay of ~10 minutes is added to the start of your charge (or taken away from the end). This is to smooth out demand for electricity from the grid, preventing a surge that overloads the infrastructure. This happens within the Pod Point firmware so is not something we have any control over and is, in-fact transparent to us.

So, what about the APIs?

The APIs we are using are not publicly documented (although they are the same used by the mobile app, so are likely stable). Based on the app functionality and API structure the statuses seem to indicate the possibility of charging, so connected indicates that the vehicle is connected, not that there is charge actively being delivered, the other statuses available, waiting-for-schedule and unavailable do not provide enough context to determine this. We've already doing some lifting behind the scenes to create the derived connected-waiting-schedule status.

I previously looked into creating a sensor to determine actively delivering charge but this is quite difficult due to the delay in receiving updated via the Pod Point API. As mentioned in point 1 above the data we get is not real time, so it is possible for you to query the API twice and get the same value back due to a de-sync in the timings (which are also not consistent from what I have seen)

Because of these I don't think there is currently a way to improve the situation, although if anyone is able to work something out then I'd be happy to merge it in

[Marky0]

@mattrayner, @townsmcp thanks for the comprehensive replies. Using the current_energy sensor unfortunately doesn't work as it is not fast enough to detect the pod-point turning on before it causes a hardware trip with my solar inverter.

However I have found a work-around by using my vehicles api to test the pod-point charge status which is fast enough to reliably set the charge current and avoid a trip. Its not pretty, but it works ! Thanks again for your replies.

[mattrayner]

Just one to add here, you can reduce the polling time of the pod point APIs to get data faster. However setting it low is extra load on the pod point servers at all times, regardless of if you are charging or not, which might cause them to take steps to disable your access. If you do want to look into it, it’s under the integration options from the integrations page

On Mon, 13 Mar 2023 at 20:34, Marky0 ***@***.***> wrote: @mattrayner <https://github.com/mattrayner>, @townsmcp <https://github.com/townsmcp> thanks for the comprehensive replies. Using the current_energy sensor unfortunately doesn't work as it is not fast enough to detect the pod-point turning on before it causes a hardware trip with my solar inverter. However I have found a work-around by using my vehicles api to test the pod-point charge status which is fast enough to reliably set the charge current and avoid a trip. Its not pretty, but it works ! Thanks again for your replies. — Reply to this email directly, view it on GitHub <#24 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA2XGNRL3SGNYQSCLEOO6HTW36AFVANCNFSM6AAAAAAVYDCNT4> . You are receiving this because you were mentioned.Message ID: ***@***.*** .com>

-- Matt Rayner http://www.mattrayner.co.uk/