Arbitrary I2C/SPI/GPIO Autheticator

[Awbmilne]

I am looking at configuring am OpenEVSE charger for use at home. Home being very visible near the sidewalk in a busy city, I'm hoping to have some locking for my charger so nobody can roll up and just use it.

The RFID auth is an excellent option, and it's awesome to see that so readily integrated into the UI. But I'm looking for something a little more streamlined. I'm hoping to use the garage remote in my vehicle to enable a charging session, but keeping the RFID available as an easy "tap to charge" option for guests.

This is a pretty niche use case, and the garage door remote would not be very secure as I will likely have to rely on static code messaging (HomeKit doesn't have any open rolling code standards, afaik), so I would not ask for that type of authentication to be covered, but what would be incredibly powerful would be having the option to cook my own authentication device.

My idea being that the ESP32 could rely on a secondary controller to do authentication and communicate with it over I2C, SPI, or a simple High-Low GPIO. This second device (in my case) would handle the radio signal for the garage remote and an RFID scanner, providing the session authentication logic. The ESP32 controller could poll the secondary controller for whether a session should be allowed to be started. I'm not sure how straightforward this would be to implement, but I would hope much of the existing RFID Auth structure could be reused.

Using something like I2C or SPI could be nice in that the ESP32 could provide a little bit of information back to the auth controller, such as a "session started" signal to close the auth transaction.

Just working out some ideas! Amazing system already!

[Dicion]

If you implemented an OCPP backend, (like SteVe), then you could possibly do this a large number of ways. It's more flexible and designed for that sort of thing. That is exactly why OCPP was designed and what it is supposed to do. Handle advanced level authentication, billing, control, metering, etc of one or a group of chargers.

I recommend you look into SteVe, and see if it can do the capabilities you wish.

[Awbmilne]

I didn't know that openEVSE supported OCPP, that's awesome!

I'm not sure it's ideal for my use case as it would require constant network access and an OCPP compliant CSMS server. Yes, a Raspi Zero could serve as a very basic CSMS with auth, etc. but wifi 🫤. Wi-Fi outdoors is always... Fun.

Is there some existing way that session start/stop could be handled through a hardwired connection to another microcontroller?

Bonus questions for OCPP: How does OpenEVSE handle session start commands? For example, does the session-start need to be sent before the car is plugged in? Does OpenEVSE send an auth/session request when plugged in? What happens in a power outage, does OpenEVSE continue its session or re-request auth?

[Dicion]

Is there some existing way that session start/stop could be handled through a hardwired connection to another microcontroller?

I mean, the simplest method would be to put another control relay in-line with the 50A contactor coil control. Then control that secondary relay from whatever else you want. If that contactor doesn't close, the EVSE won't charge, It will just sit in 'connected' status until both systems (OpenEVSE) and the secondary relay, close the contactor.

Bonus questions for OCPP: How does OpenEVSE handle session start commands? For example, does the session-start need to be sent before the car is plugged in? Does OpenEVSE send an auth/session request when plugged in? What happens in a power outage, does OpenEVSE continue its session or re-request auth?

Some of this is a question for @matth-x as he wrote the OCPP section based on his MicroOCPP code. You can read about MicroOCPP at it's official site here: https://www.micro-ocpp.com/ or at it's github here https://github.com/matth-x/MicroOcpp

I always plug in before authenticating. I think this is the intended method of operation, but I don't know if it works the opposite way as well. Auth, then plugin within X seconds. So yes, once plugged in, it updates the OCPP backend that a vehicle is connected, but in my case, it does not auth until I read a RFID card, or use the backend app to auth the transaction. Then it approves/activates. It really depends on how you have it setup. I think you can set it to auto auth and charge regardless too. It's quite customizable.

[chris1howell]

A second relay would not be a good idea. Disconnection could be under load. This will cause errors on the vehicle/EVSE and wear components quickly.

The best way to control would be over the WiFi APIs, MQTT, HTTP or OCPP.

If you want to control with an external microprocessor you can disconnect WiFi and do exactly what WiFi is doing, send serial RAPI commands to enable and disable etc.

On Sat, Jun 22, 2024, 9:37 AM RT @.***> wrote:

Is there some existing way that session start/stop could be handled through a hardwired connection to another microcontroller?

I mean, the simplest method would be to put another control relay in-line with the 50A contactor coil control output. Then control that secondary relay from whatever else you want. If that contactor doesn't close, the EVSE won't charge, It will just sit in 'connected' status until both systems (OpenEVSE) and the secondary relay, close the contactor.

Bonus questions for OCPP: How does OpenEVSE handle session start commands? For example, does the session-start need to be sent before the car is plugged in? Does OpenEVSE send an auth/session request when plugged in? What happens in a power outage, does OpenEVSE continue its session or re-request auth?

This is a question for @matth-x https://github.com/matth-x as he wrote the OCPP section based on his MicroOCPP code. You can read about MicroOCPP at it's official site here: https://www.micro-ocpp.com/ or at it's github here https://github.com/matth-x/MicroOcpp

— Reply to this email directly, view it on GitHub https://github.com/OpenEVSE/openevse_esp32_firmware/issues/858#issuecomment-2184039008, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAN5QH4DRJ7B65FNZDDN3XLZIV4YJAVCNFSM6AAAAABJDPMNKKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCOBUGAZTSMBQHA . You are receiving this because you are subscribed to this thread.Message ID: @.***>

[matth-x]

Both scenarios are supported over OCPP: plug in first and authorize first. The transaction eventually starts when both conditions are true, i.e. the cable is plugged and the user is authorized. The OpenEVSE platform has a high degree of freedom for custom use cases. In the current integration, transactions resume over power losses and don't need to be restarted (that can be changed, e.g. for commercial setups).

If you want to build something on your own, then it's a quite straightforward process to find the necessary parts in the existing MQTT or OCPP code and write a custom task. Of course the existing interfaces as Chris suggested are already sufficient for integrating a custom authorization scheme.

[Dicion]

@chris1howell

What if the relay was placed on the pilot line, to change the pilot signal on demand?

Reading here: https://www.speakev.com/threads/remote-evse-control-via-pilot-signal.136832/

It seems that switching between the actual pilot, and a +12V steady signal is the best, clean option that has the potential to cause no issues.

1 Hooking up relay bypassing to +12V = Ready state, no charge. 2 Enabling the relay switch to the real pilot should then initiate charge. 3 Switching back to +12V should tell the vehicle to gracefully drop the charge.

The only potential issue with the above, is once the actual EVSE pilot is disconnected from the vehicle (step 3), it will stop pulling it down to 9V, and the EVSE should drop the contactor at that point. According to the thread above, however, if that happens too fast, it can cause the contactor to open before the Vehicle gracefully stops charging. It all depends on how long the delay is with the EVSE, and how long OP's vehicle takes to stop charging.

I agree that using OCPP or one of the other software protocols is the correct answer, and said so in my first reply, but they're specifically asking for a simple, hardware workaround.