Discussion: switch vs input_select for "Manual override"

[mdallaire]

Hi! I first want to thank you for this integration, I have been integrating mine with manually configured rest sensors and rest commands so I was quite happy when I found this project.

One thing I noticed is the choice of a switch device for the override. I also started with this when integrating the override but realized there are really 3 states to the override configuration:

POST to http://openevse/override
'{"state": "active"}' : force the charger on bypassing any schedule
'{"state": "disabled"}' : force the charger off bypassing any schedule

DELETE to http://openevse/override
Clears the override and revert to schedule or default operation.

The only entity type I think could make sense would be a input_select with values of ON/OFF/None.

What are your thoughts on this?

[firstof9]

It's either overriding (on) or it's not (off), the 'default' operation is "off".

[mdallaire]

Yes, I understand this is how it's programmed in this integration.

I just saw in the code that you are using the toggle endpoint of API. I played around with it in postman and it seems to dynamically choose the override mode based on the current status of the charger (Override off if currently charging, override on if not and clear when toggled off)

There are three states available in openevse that could be applied at all time :

• Override Off/Disabled: Will stop charging and prevent charge schedule from starting
• Override On: Will start charging right away even if outside schedule
• No override

By using the toggle API we don't have access to Override Off to block an incoming schedule if the car is not already charging.

So back to my initial point, I think a input_select might be the best way to expose the three Override states and have them accessible no matter what the current charging status is. It could also allow to see what kind of override is active (on/off).

Just to give you my use case, I have a variable rate for my electricity and the provider sends signals to announce the rate. If I get a signal that the rate will be high I want to send a override off to openevse to block the schedule.

[firstof9]

That is a whole separate deal then, I'll see about a service call you can use for this function.

[ruimarinho]

I think it becomes a bit more complex if you add the other possible values (source):

• charge_current
• max_current
• energy_limit
• time_limit
• auto_release

I think this definitely can be resolved by a service call with data arguments for the more complex case and keeping a simple switch for override on, i.e., override active (POST active) and off, no override (DELETE).

[firstof9]

The binary switch uses the PATCH method as documented for toggling the manual override.

[firstof9]

The latest beta now has the services to set and clear the override.

[firstof9]

[mdallaire]

Very nice! That works well thanks!