Comments (6)
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
from pod-point-home-assistant-component.
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.
from pod-point-home-assistant-component.
@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?
from pod-point-home-assistant-component.
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)
- 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)
- 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
from pod-point-home-assistant-component.
@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.
from pod-point-home-assistant-component.
from pod-point-home-assistant-component.
Related Issues (20)
- Add support for custom voice intents and sentences
- Update cost currency to load dynamically from the user's Pod Point account
- Status Incorrect if using Charge Now in new Pod Point App HOT 3
- Average Power HOT 2
- Add a switch to set Charge Mode
- Unable to login due to invalid credentials - fix detailed inside HOT 8
- Unable to prepare setup for platform pod_point.*: Platform not found (No module named 'podpointclient.charge_mode') HOT 6
- Frequency of polling HOT 5
- PodPoint Current Energy Sensor HOT 2
- Pod Point have changed their API endoints which has broken the integration HOT 1
- Podpoint values not updating HOT 2
- Charging Allowed switch failing HOT 9
- Stop Charge Now - Clearer/cleaner way to cancel a schedule override HOT 2
- Expose a "Charged" status like the PodPoint app does HOT 3
- Should the new "Pending" state be on the Charge Mode instead of Status? HOT 3
- PSL- Cable Status shows plugged in, but it is not (when the Pod Point is in Smart mode) HOT 5
- Invalid handler on install HOT 5
- Unable to log in HOT 1
- Cable Status sensor is unreliable since last update HOT 5
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from pod-point-home-assistant-component.