Should the new "Pending" state be on the Charge Mode instead of Status?

[busywait]

Is your feature request related to a problem? Please describe.
Release 2.0.x has just added a new Pending state for the main Status, and I've been reviewing my automation triggers to see what needs to change.

Adding Pending to the main Status makes it harder to be specific about transitions like from "Connected Waiting" to "Charging" because the Pending state could interrupt that transition.

Describe the solution you'd like
The Pending state is intended to show when API requests are waiting to be actioned, and these affect the charge scheduling - isn't Pending more relevant to the Charge Mode than the status of the cable and charge delivery?

Describe alternatives you've considered
I can ignore the "From" transition when triggering on states, and can use "not_from" and "not_to" in the trigger if I edit the yaml.

I can use the Cable Status for Unplugged vs Plugged In.

Additional context
Add any other context or screenshots about the feature request here.

[busywait]

Sorry, I was misunderstanding the information I read in the release note - I originally thought that Pending applied to the Cable Status as well as the main Status. While Pending feels more like a Charge Mode state to me, it's not affecting my use of the integration.

I also originally assumed that Pending was a state introduced by this integration to indicate waiting for a response from the Pod Point API, but now I understand that is actually a state from the API [nope, see below] indicating waiting for the individual Pod Point to respond (and so the state in Home Assistant might go to Pending if I request a change via the app, although I've not see that happen yet).

[mattrayner]

Hi @busywait, thanks for raising this!

The pending state is a strange one, it is present in the mobile app and through observation (as there is no documentation for these endpoints) appears to be the following:

As a user, when I change a setting that affects my Pod (charge mode, schedules, etc) I would like to understand when the change has taken place

The app appears to keep track of the date/time a request was made (request_time) to change a setting, then compares this to the 'last message received from pod' date/time (update_time).

When request_time > update_time state = pending

As the pod and api are not aware of a message that has been sent to a pod, the api (which only reports the last state of the pod) doesnt DIRECTLY return pending. I have recreated the observed behaviour from the Pod Point app by implementing the same logic described above.

If you make a change to your pod VIA home assistant (stop charging, start charging, start charge now, stop charge now) I store the date/time of that request. Then there is a check which compares that date/time to the last message received from the pod. If the pod has not send at update after request_time, the assumption can be made that the pod has not yet received the update. Changing the state to pending highlights to users that their change has not yet been accepted/implemented by the pod.

This will only take place when the request for change happens within Home Assistant as all requests 'external' to the integration are transparent.

I hope this helps to clear up why your integration does not show pending when you make a change in the app.

If you can think of a better way to hande this/want this to be an option feature, I can look into this for a future release

[busywait]

Thanks for the clarification. I think that Pending makes more sense in the Pod Point app which is designed for interactive control than it does in your integration API, which will more typically be used in automation (I think). Thanks for clarifying that it is a state that is local to the calling app. Personally it doesn't help me, but I've modified my triggers to account for it.

In case it's interesting, here are the ways that I'm using your Pod Point integration:

• Trigger status update requests to my car on real events (unplugged, finished charging, ...) to see up-to-date information in Home Assistant without stopping the car from "sleeping" because of polling the car API for status updates
• See that the car is setup to charge overnight, is charging and has charged
• Use the "Schedule override" service (+ Car API) with a shortcut button inside the house to work as a "boost" button to start charging the car to 100% now regardless of Pod Point schedules or charging limits that were set in the car
• Check the status histories (Status, Charge Mode, Cable Status) to work out what happened if the car didn't charge as I expected

Next time I change my electricity tariff I'll try and use the "schedule override" service to make use of dynamic electric tariffs like Agile Octopus.