Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
fhteagle opened this issue Mar 9, 2023 · 10 comments
Open

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

fhteagle opened this issue Mar 9, 2023 · 10 comments

Comments

@fhteagle
Copy link

fhteagle commented Mar 9, 2023

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
Copy link
Owner

KipK commented Mar 9, 2023

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
Copy link
Author

fhteagle commented Mar 9, 2023

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
Copy link
Owner

KipK commented Mar 9, 2023

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
Copy link
Author

fhteagle commented Mar 9, 2023

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 OpenEVSE/openevse_esp32_firmware#461 on how to design it to make it work for the most users.

@jeremypoulter
Copy link
Contributor

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
Copy link
Author

fhteagle commented Mar 10, 2023

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
Copy link
Owner

KipK commented Mar 10, 2023

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
Copy link
Contributor

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
Copy link
Owner

KipK commented Mar 10, 2023

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
Copy link
Author

fhteagle commented Mar 11, 2023

Bringing the HA integration developer into the discussion here: firstof9/openevse#184

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants