lincomatic / open_evse

Firmware for Open EVSE

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

RAPI command to enable/disable bootlock

chris1howell opened this issue · comments

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.

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?

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.

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.

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.