fixed sensors for dashboard + fast polling

[hallidaydaniel]

Hello! Great work on this custom integration.

I have two initial suggested changes:

The first is simple - shortening the polling interval. From some testing, the EO seems perfectly capable of providing data once per minute and this helps with seeing what's happening, especially with short charges. Maybe long term, this could be a config item?

The second is more complex but more importantly, I have changed the sensor behavior in the following ways. These are all aimed at having the sensors behave in the expected ways in Home Assistant, particularly the Energy Dashboard:

• Changed the StateClass to be 'total_increasing' for both sensors. This is a match for the Home Assistant documentation on a sensor like this which increases then goes through a reset back to 0 periodically - from the documentation for 'total_increasing' : "Similar to total, with the restriction that the state represents a monotonically increasing positive total which periodically restarts counting from 0, e.g. a daily amount of consumed gas, weekly water consumption or lifetime energy consumption." . The previous setting total is only suitable if the value decreasing has some sort of information e.g. a net energy meter.

• Changed the logic for when 'last_reset' is registered, and when to record a 0 value. Previously the sensor reset every time it got a reading/data from the API. Instead, it should only reset when the value for the session drops back to 0 / it's a new session. This, combined with the StateClass drop it back to 0.

My apologies in advance that although I have a developer background, Python is new to me and I may have made some basic mistakes, hopefully, the principle of what I think the code should do is at least clear. I think there are quite a few error states to manage, which this does not yet do (like a potential race condition on never getting to 0, although the 1-minute scan interval in my testing seems to solve this).

To illustrate the outcome of these changes, this is how a charge session now registers in Home Assistant:

This compares to how one could look previously:

With these changes, data correctly accumulates on the energy dashboard too (still testing to validate this further):

[hallidaydaniel]

Just realised I should say that the first picture illustrates two charge sessions - one ending, a short gap (value stays at high number) then a second session starting with the value starting again from 0.

Please do get in touch to discuss any of this (can do Zoom etc too if useful). Would love to collaborate on this over time.

[twhittock]

Wow, thank you so much for contributing, I'll merge now! Yes I'd be happy to collaborate more on further improvements. Lets open issues for the things which could be better, and we can find a way to work it out.

[twhittock]

@hallidaydaniel FYI, I updated this to have a default poll interval of 5 min, and made it a 'configure' option on the integration.

[hallidaydaniel]

@twhittock - Just been looking to see what other improvements could be made. Is there a document or anything 'official' on the EO API that the integration uses? Just trying to sketch out what else could be possible.

[twhittock]

No official documentation that I could find. There is another repo with a library https://github.com/bfayers/pyEOCharging and a thread on the HA forum where some people have been sharing postman collections. (https://community.home-assistant.io/t/ev-charger-api-collection/378432/18)

[hallidaydaniel]

Thanks for these @twhittock - useful work by others!
Having a look through, I think some useful goals (in my rough order of value - yours may differ!) are:

1. Get current session power - useful for understanding the makeup of power load on house. Seems to require a call to an additional URL, api/session/detail. Could be done following the confirmation of the existing session?
2. Get the current Volts and Amps (actually required for the first point, but some more work to present as sensors I guess). Less directly useful, but there so could be handy.
3. Enable and Disable Charger - looks like it's possible to lock/unlock with a call. This could be presented as a binary sensor in HA - Useful for being able to automate locking when you are away from home
4. Pause and Unpause Session - looks like also possible, again could be presented as a binary sensor or two buttons. Could be helpful for automating when the charger actually runs (for Solar / PV setups or economy overnight electricity rates
5. Session History - this looks to be the same as you get in the app (makes sense). Don't think it has that much value as an integration for HA.

Let me know what you think / which one to try first - I will open an issue for it and we can get started on it.

[MuddyRock]

If I may make a suggestion related to number 4, I think a sensor indicating whether the charger is "live" (i.e. in a mode where it would provide power to the car if one was plugged in) or not would every useful, ideally along with some kind of override to make it live. The play / pause button is currently greyed out in my app, and calling them via the API returns a non-error RESTful response, but doesn't seem to do anything.
From what I can see, the charger is live if:

• any one of the modes (solar, op or time) returned in ChargerOpts is 1, AND the schedule for the current half hour timeslot / type of day (weekend or weekday) matches (e.g. for off-peak charging between 00:30-04:30 and no other charging, the schedule string is
  0PPPPPPPP00000000000000000000000000000000000000000

It's always 50 chars, one for each half hour block, starting at 00:00, and always terminating with two additional zeroes - the P in position 2 indicates start off peak charging at 00:30, as long as opMode is also 1). Other codes are used in the schedule string to indicate solar / scheduled charging.

OR

• all modes are 0 AND there is a T in the relevant timeslot in the string.

I think there are a few other possibilities, and I also haven't yet tried overlapping schedules (what letter is used /does the app allow a timeslot to be both off-peak and scheduled/solar?), but this might be good enough to start with.

My testing so far has confirmed that by replacing chars in the string with T, except the terminating zeros, and disabling the off peak and other modes, all via a call to set the charger options (see my respository version of pyEOCharging, which will hopefully soon be accepted by the upstream owner), the charger is set to live and this in itself means that a simple set of automations in HA could initially be made along the lines of:

IF (car is plugged in and car is at home)
and (
(time = <planned departure time - X mins>
OR time = off-peak start time
)
THEN override off-peak settings and set charger to live

(the X mins before departure allows for a call to the car's defrost/preheat service)

and a similar automation to disable the charger when the car is unplugged / leaves home / offpeak time ends.

I am currently trying to teach myself Python in my spare time, but I'm starting from a very low point. I'm a lot more familiar with API calls and spotting patterns in strings etc.

I'd be happy to help with this project where I can, but with my experience, that might be in the testing department until (if!) I get up to speed with Python. I may also be able to help with deciphering the results of the API calls.

It might also be worth keeping an eye on the original pyEOCharging repository and the discussion around my pull request.
@bfayers has managed to connect to the charger's private WiFI AP - and found some additional functionality via that route (so far all I've managed to do is connect to the AP - I've asked for more info) and, if you check some of the other discussions in that repository, his aim is also some form of HA integration. I'm going to suggest that we all collaborate to work on this project.