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

RAPI command to enable/disable bootlock #170

Open
chris1howell opened this issue Aug 4, 2023 · 4 comments
Open

RAPI command to enable/disable bootlock #170

chris1howell opened this issue Aug 4, 2023 · 4 comments

Comments

@chris1howell
Copy link
Contributor

Add RAPI command to enable/disable bootlock. Bootlock compiled in by default but off.

Bootlock currently requires a define at compile and can not be turned on/off. This requires different firmware to be compiled with/without bootlock and has caused confusion with users and numerous support requests. Many users update to the "latest" firmware without understanding the firmware with bootlock would render their station inoperable without the WiFi with the correct bootlock firmware.

@glynhudson
Copy link
Contributor

I agree there needs to be a way to override bootlock.

How about a delay of say 2 min where bootlock waits for the WiFi module to boot up and then after that if no Wifi module is detected after 2 min bootlock is disabled and the EVSE controller works as normal?

What do you think @jeremypoulter @KipK?

@chris1howell
Copy link
Contributor Author

chris1howell commented Oct 11, 2023

Bootlock compiled into 8.2.3 has caused a huge support headache, as many users can not charge or instability causes the station to lock. I have considered deleting the 8.2.3 release, for now I ship with 8.2.2 as a default, noted 8.2.2 as the "Recommended Release" on Github and have added Disclaimers:

8.2.3 is now compiled with BOOTLOCK/HEARTBEAT enabled.
NOTE: Do not install if:
Wi-Fi is not installed
Wi-Fi version is not stable
Wi-Fi version not greater than 4.2.1
You don't want your station locking due to comm/WiFi issues

This has helped reduce support requests, however I am not a fan of releases that are only for a sub-set of the community. The ability to enable/disable bootlock with it set to disabled by default would allow everyone to use the same release.

@jeremypoulter
Copy link
Contributor

So maybe a boot lock timeout as @glynhudson suggested, with a RAPI command to configure the duration? 0 will disable. The timeout suggestion was to handle the case of a faulty WiFi module.

@chris1howell
Copy link
Contributor Author

I think the bootlock feature is most useful for stations under full automated control, such as commercial stations controlled via OCPP. Bootlock prevents the dispensing of free energy if the communications are unavailable due to hardware/software issue or a denial of service attack. A timeout would not be desirable in this use case.

We are currently using bootlock as a bit of a hack so the station will wait for WiFi module to come online before responding to vehicle requests. Most users are not likely under full automated control, so bootlock it really is not necessary or desirable.

I am fine with enable/disable and even a timeout as long as the timeout can also be indefinite/disabled. I still think boot lock should be disabled by default, anything that prevents station operation causes headaches and support requests. Please remember, not everyone has a WiFi module and would be really frustrated if they had to wait 2 minutes before using their station every time it is powered up.

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