No way in UI to prevent "Auto-Release"?

[fhteagle]

Is there any way with GUI v2 to turn off / prevent / ban Auto-Release? I crawled through the whole UI and could not find it anywhere. I would like to be able to permanently turn off auto-release, in a way that will survive power cuts, firmware updates, etc.

[KipK]

yes I've removed the auto release switch has it could never survive reboot & co so this has not much sense.

Would be better to add a default state in Configuration ( Default to Disabled | Active ) But that's a fw change

Would that deserve your use case ?

[fhteagle]

The most important thing for my specific use case is the unit not changing itself on unplug for now. Since the auto-release switch is removed, is there any way that I can set auto-release to permanently off?

Long term, yeah that's a harder problem to capture all of the possible user desires for what the unit should do on power up, needs more discussion than just here. I will add that to the use case writeup project to try to plan/measure the population of users and what they want on that.

[KipK]

auto release is never saved as it is part of a claim

Also overrides can't have auto-release set to false. I guess the only way is adding a default state switch some where in the settings for long term state

[fhteagle]

Having auto-release and/or default state of activated vs disabled be a user configurable item seems like better design to me as well. Let's get more input from the user base via https://github.com/OpenEVSE/ESP32_WiFi_V4.x/issues/461 on how to design it to make it work for the most users.

[jeremypoulter]

But can you give some more info on your high level use case? It could be that there is an alternative way to meet your requirements. Manually adjustments on the UI are temporary by design

[fhteagle]

Sure. I live in an area with really highly variable renewable production but still a high amount of coal base load electricity. I have been delayed getting my own personal solar installed by the `$!#@@##$*& installers around here, so OpenEVSE's baked in PV divert features would be kind of hacky to try to implement. Instead, I have rigged HomeAssistant to have knowledge of grid CO2 intensity and local solar production, and to choose times to charge for me that are optimized to take advantage of renewable power as much as possible.

If auto-release is permanently on and the OpenEVSE is set back to activated on unplug, that is often not compatible with the above goal at the time of the next plug in.

So, I have rigged a temporary workaround for HomeAssistant to re-establish manual override and status: disable for each of my two OpenEVSE's a few minutes after an unplug event on that specific unit. This seems to be working as intended for now.

But, in my opinion, it would be better for the OpenEVSE installer and/or end user to have choice about what status the unit starts up in, goes to after unplug, etc, instead of auto-release being hard coded to work a certain way. Again, I think this should be part of a larger process of capturing user stories, distilling to needed features and functions, and guiding future development goals, and I am happy to participate in that as best as I can.

Thanks.

[KipK]

I think just setting the default state to Active or Disabled in the config should handle this, or we could save manual overrides claims if set to auto_release=false ( will have to also enable auto_release for /override endpoint then )

[jeremypoulter]

I think it may be better to use the /claim API to set the active/disabled state, which you can then set the auto release to false. This then also frees up the override to be used as intended to temporarily override what Home Assistant has set.

[KipK]

I guess we can save to flash the claims with auto_release = false, perhaps just for a new system client id with lowest priority to prevent too many writes.

[fhteagle]

Bringing the HA integration developer into the discussion here: https://github.com/firstof9/openevse/discussions/184