Use of manual override vs claims API

[fhteagle]

Towards the end of KipK/openevse-gui-v2#34 , there is some question from @KipK and @jeremypoulter about whether the HA integration should be using the claims API instead of setting a manual override. My initial reaction was to say yes, HA should be using claims. But now I am wondering how well the HA integration will be able to handle other features of the OpenEVSE firmware changing things via the claims API. Examples would be PV divert, shaper, MQTT, OhmConnect, OCPP, etc. If the HA integration is robust enough to get the message that something else in the claims API ecosystem made a change contrary to what HA commanded / expected, then sure claims is the right way to go. If there is a high likelihood that the unit would end up in an unexpected / uncommanded state, then maybe staying with manual override (and considering it that HA "makes the user input for the user" that trumps all claims) is the way to go.

Thoughts, @firstof9 ?

[KipK]

It's easy to catch who is controlling what using the /claims/target endpoint

I guess you can use booth, /override to mimic user interface for human interaction, and use of /claims for automation.

[firstof9]

Think of the integration as basically a second GUI for the user to interact with. There is no distinction between "human interaction" and an automation, they are the same.

Anything pushed out by the units, if I can, will reflect a sensor of some type in Home Assistant.
Anything interactive/changeable, if I can, will reflect some type of control in Home Assistant.

[jeremypoulter]

What maybe an idea is to assume human interaction by default and use /override but also add a service to allow calling /claim, that can then easily be used by automations.

[firstof9]

Right now the only control using override is to set the amp limit.