Closed yheynema closed 5 years ago
Sorry, this feature should be implemented in an external RAPI client, such as the ESP8266 client, not in the firmware. You can implement RFID support externally, and use AUTH_LOCK to lock/unlock the EVSE
Looking at similar function, currently the external rapi client, i.e. ESP8266 w/wifi firmware, would have to be polled to monitor when the charge session is over and apply the AUTH_LOCK.
Would it make sense to have the firmware automatically apply AUTH_LOCK when the charge session is over (if it was active when the vehicle was connected) to ensure charger will not remain unlocked if there is an issue with the ESP8266 that does not seem to like being polled frequently.?
Re Polling the ESP, you should use MQTT and/or Websockets rather than polling the state changes will be pushed to you then rather than having to poll
Wondering if this place is a good one for proposal of enhancement. Please feel free to let me know if not and redirect me to the right place, please. I actually and happily own an OpenEVSE device and I plan to have a second EV car connecting to it. In order to help split the electricity consumption bill, I would need to trace which car consumed energy. Looking for a simple solution, I though about having a separate RFID next to the charger that would enable/disable the device. I though about having a new "RAPI variable" be available. Through RAPI command it would be possible to set the, let's say, "carid" variable to a byte number. But once the firmware detects the cable is disconnected, it resets the variable to 0. The downstream system (EVSE Wifi, or any other) can thus disable the charger. The charger could be energized back by the external system when the RFID detects a valid code and set the "carid" variable through RAPI. The external system is still responsible to poll the charger. The only new responsibility for the charger is to reset the carid value to 0 once a disconnect state is detected.