Support
How can we help you today?
Car identification
OpenEVSE Support
iButton is a NFC device that uses the 1 Wire protocol.
If integrating the reader out on the J1772 handle, I would be concerned with the distance and running parallel to AC for so long. I am not sure it would work well so far away.
Integration of a card reader and authorization process into OpenEVSE would be a significant amount of work and require back end support as well to track users and usage. Note if you used the Wattzilla C3 UL board, the firmware is locked so adding control for the iButton would difficult and may require re-certification of the firmware with UL if certain portions of code are modified.
I think a Raspberry Pi Kiosk with a Reader (NFC, RFID, iButton) would be a better approach. you could send RAPI commands to the charging station to enable/disable etc.The Raspberry Pi would also pull usage from the Charging stations to match up with the ID. Wattzilla C3 already supports the RAPI command set so no modification would be required. The Pi could also coordinate current usage to ensure your circuit is not overloaded.
OpenEVSE Support
Here is a tutorial for adding NFC to a Raspberry Pi.
https://learn.adafruit.com/adafruit-nfc-rfid-on-raspberry-pi
I'm definitely on board with using an RPi (possibly as a Django web app) for usage tracking, authentication etc. Planning to use RAPI for charger control, and for the load management task to also run on the same RPi. I don't particularly want to mod the OpenEVSE boards.
For my load management plan, I need to get the signals from a couple of panelboard current transformers into the RPi. Pi has no native A/D, so maybe use adafruit ADS1015 breakout.
I still like the idea of ID reader in the J1772 handle, but I am cooling off on the iButton approach as there is exposed metallic contact and corresponding safety concerns. My favorite idea at the moment is using infrared-remote components. 38kHz IR receiver in the handle, drive the raw baseband data down the 5th wire, and couple it to the RPi for decoding. Some little IR-generator circuit (adafruit Trinket?) attached inside the charge door of each car pumps out an ID code which is seen by the IR receiver in the J1772 handle.
I need to think thru the isolation requirements if I want to keep everything on the RPi side Class 2 (per electrical code).
If you are using the ESP8266 Wifi module, you could have the user ID variable post to the OpenEVSE emoncms site. You could then do some post-processing to correlate the user with the KWh used from the server side data. Just a thought.
I know this topic is old, but if OpenEVSE developper can have a look at this request again. I would like to know if it would be possible to introduce a new variable to the module, let's say 'carid'. This variable could be set through RAPI but return automatically to 0 as soon as the handle is pull off from the car (ie, disconnected). That way, it would be possible using an external system (RFID, and so on), to command energization of the module, and set the 'carid' value. While connected, the carid variable is set to something different than 0. Once the handle is disconnected, the 'carid' returns to 0, the external system gets it and de-energize the module.
Hi, Yanick!
Embedding into the main OpenEVSE controller is likely to be unlikely to succeed, since its firmware occupies almost the entire place. Here you need to think about a separate controller (Arduino, ESP, RasberryPi). How do you like the idea of using a radio transmitter? For example, on each machine somewhere there is a small emitter, and at the charging station there will be a receiver. As soon as the car approaches, the receiver will trigger and the station will be able to identify who has arrived. Here, with the help of RAPI, you can control the charging session. Or the second option - the use of conventional keychain. I pulled up - pressed the remote and charging started.
Ultimately being able toi drive up to a charging station and SECURELY negotiate the transaction and being charged for it without having to use credit cards etc. will be an expectation. Fumbling at gas stations with credit cards is too old. That said, there is still a case for a SECURE and PRIVATE transaction. Not being tracked is not the preserve of the criminal elements but those that don't wish to advertise that they are away from home or in a certain place for their own and family's safety.
I'm thinking about how the secure transaction can be negotiated. It's outside of the scope of the present hardware since its memory footprint is limiting. A larger embedded, open source platform is a must.
OpenEVSE Support
This feature would be much better implemented on the WiFi interface rather than the controller itself. The controller is responsible for safety, adding hardware libraries, applications, UI, and authentication would take away from its core responsibility.
Implementing NFC/RFID is already an Open Issue for the development. It is currently at a low priority as there has been very little interest.
Chuck Harrison
I am planning to install a group of level 2 charging outlets at the condo development where I live.
I think it would be great if a user could plug a cord into his/her car and have the system automatically know which car it is.
It might be ideal to use NFC or Bluetooth but those approaches seem kind of complicated. Here is an alternative thought:
1. Equip the J1772 plug handle with a Dallas Ibutton receptacle and a red/green LED.
2. Use 5-wire EVE cable and use the 5th wire for comms using "1-wire" protocol
3. The user keeps a 1-wire key on a lanyard inside his charge door
User's experience: Plug in cord, tap key to reader pad on handle, look for green light.
What do you think?