2/ To make it consistent with OpenEVSE UI, this entity state shouldn't follow "pilot" value, but the /override "charge_current" state when set, or the "max_current_soft" if there's no override.

I think this would be better handled via the library.

sure that , I forgot you've made a lib for this

quick question for you if you know the answer, does max_current_soft get the value of "charge_current" from /override?

nope, max_current_soft is the setting in /config, it doesn't change. You usually only have to set it up once.

max_current_hard is stored on EVSE module
max_current_soft on ESP32.
They have the same purpose , but max_current_soft can't be > max_current_hard
and claimed max_current can't be > max_current_soft

charge_current set the pilot. If there's many claims ( override is a claim , sort of ) Openevse takes charge_current value from the higher priority claim.
Mostly it's override service, but shaper and ocpp have higher priority. Shaper only set max_current anyway, not charge_current.
If there's no charge_current claim, then max_current will set the pilot, if there's no such, then max_current_soft.

And Divert set charge_current too, but lower priority than override.

I don't know if you were aware of that. But you don't have to poll the /override /claims /config or any other endpoints.
Once connected to /status websocket, it will throw version attributes for each of those endpoints when they have some changes ( override_version , claims_version, config_version, limit_version ).

This way, you now exactly when to get a fresh /override and co

You still have to grab them once at startup.

Yup I look for those in the library:

UPDATE_TRIGGERS = [
    "config_version",
    "claims_version",
    "override_version",
    "schedule_version",
    "schedule_plan_version",
    "limit_version",
]

So I've whipped up a new property for the library, what do you think?

    @property
    async def async_charge_current(self) -> int | None:
        """Return the charge current."""
        try:
            claims = None
            claims = await self.list_claims()
        except UnsupportedFeature:
            pass
        if claims is not None and "charge_current" in claims[0].keys():
            return claims[0]["charge_current"]
        if self._config is not None and "max_current_soft" in self._config:
            return self._config["max_current_soft"]
        return self._status["pilot"]

It grabs the claims (the highest priority seems to always be listed first), checks for the "charge_current" in the keys for the first claim, and returns that, if it exists.

Should I loop through all claims until I find a "charge_current", or do you think the first one would be sufficient?

I forgot to tell you about this undocumented endpoint ( at least it was when I was developping the UI ) :
/claims/target

Give a look to this one, it's really usefull.
It will always gives you the running property

{"properties":{"state":"disabled","max_current":31,"auto_release":false},"claims":{"state":65540,"max_current":65548}}

properties: are the one actually used by openevse, claims: are the service ID claiming those properties.

you can match service IDs here: https://github.com/OpenEVSE/openevse-gui-v2/blob/master/src/lib/vars.js
( manual is override )

This endpoint should be easier to use :)

so will the properties dict contain a "charge_current" or use "max_current" ?

This is just an example. This endpoint has all the props a claim can have.
You see max_current here from shaper.
If you set the slider, you will also see charge_current too. They can booth be present.
You set charge_current at 25A, but shaper set max_current at 20A so pilot will be 20A. But when shaper remove the prop or increase it above 25, then pilot will be 25.

Would you be able to provide some additional example outputs?

here is one with booth shaper and override setpoint ( and state is from scheduler )

{"properties":{"state":"disabled","charge_current":28,"max_current":23,"auto_release":false},"claims":{"state":65540,"charge_current":65537,"max_current":65548}}

@KipK would you mind seeing if this branch works as you're requesting?

https://github.com/firstof9/openevse/tree/feat-402

When you have a moment of course.

I've just tested with shaper on, that's working good, you've got it 👍
It's far more responsive as the pilot value was lagging behind.

Thanks for investigating on this

Just one thing is missing ( library job ), is removing the attribute/override when = max_current_soft

edit: Ah I see something wrong, If I set the charge_current on OpenEVSE side , number.openevse_charge_rate doesn't follow on HA.

It seems HA plugin doesn't get the updated endpoint version.

I'll take a look, thanks!

It just seems it doesn't refresh data when a new version is published. I see it refreshed after a minute, not instantly

Is the websocket not sending an update when you move the slider?

yes it is: {"claims_version":119,"override_version":189}
as override is also a claim, it publish booth new version.
For the slider anyway, you just need to parse the override endpoint as you don't care of what has been published elsewhere.

On UI, I keep a copy of all the endpoints in a local data store. When the /status websocket receive a new endpoint version ( aka claim_version, override_version, etc ) , it directly grabs it and update the data store.

I had to integrate a request queue manager, because OpenEvse API doesn't like more than 1 query at the same time.

Ya the library stores the api replies in a dict and when updates come in, the dict get's updated.

@KipK it seems to work fine for me...

@firstof9 I don't get why it did that the other day.
I've reinstalled completeley the addon with correct branch and it works ok now so I guess there was a mixup between stable and this branche on my setup. Sorry for that.

Looks all good to me

edit: I have some little things to comment but that's on library side:

• changing the charge rate will delete the current state override instead of just adding a property.
• setting the charger state to enabled / disabled remove the charge_current property set on override.
• moving charge rate to max value should remove the property from override

@firstof9 I don't get why it did that the other day.
I've reinstalled completeley the addon with correct branch and it works ok now so I guess there was a mixup between stable and this branche on my setup. Sorry for that.

No problem sometimes Home Assistant doesn't pull in the latest libraries either and needs a good kick to get it working right.

I think I know what's happenbing, as I got this issue again today.

Logs on HA where stating that openevse websocket was disconnected.

Restarting HA solve the issue. So it seems the integration is not always reconnecting to websocket when disconnected.

Restarting HA solve the issue. So it seems the integration is not always reconnecting to websocket when disconnected.

I'll take a look, pretty sure I have the websocket reconnecting on disconnect in the library.