Start a new topic

physical security


So, not everyone has an indoor garage where they install their EVSE :-)  Wish I did!  Mine is in a carport, and in theory some person with sufficient chutzpah could stop by and top up their EV all unbeknownst to me, while I was out driving around.  I could leave the unit Paused, but the front panel button is sitting right there... Alternatively, some person with malicious intent, or curious teenager, could screw up my settings by poking around in the menus.


In the short term, I'm building a nice little wooden cupboard/enclosure (with mesh ventilation panels to keep bugs out, and painted white to keep the late sun off the transparent plastic face plate).  I could put a lock on the door.  


But it would be nice if the front panel button could be disabled via web UI, and there was something -- a physical keyfob, maybe -- that could be used to unlock it again on the rare occasions when it's needed.  I'd like to make that front panel button inaccessible, so no one can tamper with my settings or turn the device on when I left it off.  


of course if I am gone for a long time, I can just throw the 60a breaker at the house panel (that is indoors).  but then I have to reboot every time I want to use the device.  wouldn't want to do that every day.  might not be good for the unit, frequent power-cycling.


anyway, has there been any thought about physical security when the unit is installed outdoors?


one really nifty possibility would be to detect the presence of the car (my Bolt joins the household wifi network when in the carport) and only enable the unit when that particular car is there!  with an override in the http interface, of course, for when I want to be generous and let a friend charge up at my place.


2 people like this idea

The button interface works directly with the controller. WiFi is not required for the button to operate (not all stations have WiFi), it is not currently possible to disable with software.


For outdoor installations we recommend physically unplugging the button. It is unnecessary if you use the WiFi portal.


A easy way to secure stations from a stop by top off thief (is this really a thing?) is to set a start and stop charge timer for times you normally charge.

I made a proof-of-concept video that addresses the issue De Clarke raises.  This video shows real functioning OpenEVSE hardware/firmware but please understand it is very far from a complete solution as of today.  Maybe by Summer 2020 this can be something real with all of the necessary features in place.


Enjoy and please do comment, thanks:  https://www.dropbox.com/s/d781ln60ea24uar/AB1D201F-97F5-431B-8B6A-73ED3BEAAD36.mov?dl=0


Happy New Year,

Craig K.



1 person likes this

Happy New Year... The demo is really great. We are working on a custom ESP32 based Wifi module. It may be a good opportunity to add NFC functionality into the WiFi module maybe even move the button over too.


Craig... What hardware are you using? We will get some to play with. If you are interested in collaborating, we can send some ESP32 WiFi modules your way.

Chris

1 person likes this

Happy New Year to you too.   The NFC reader PCB is the MFRC-522 that I purchased on eBay.  Sellers in China price them at <$2 but you will wait for China Post.  Some US based sellers have them for around $6 with a lot quicker delivery.  For a controller I used an Adafruit ProTrinket https://www.adafruit.com/product/2000 because it fit the requirements perfectly; having eeprom in its 328p for storing tag UIDs, FTDI bus for interface to OpenEVSE plus for programming and debug, and having the ability to have a SPI or I2C interface to control the MFRC-522.  Happily there is a MFRC522 library to be found on GitHub that works well with Arduino and rich with example code.  The NFC tags I use are MIFARE Classic 1k and so far all I do is read the unique identifier from the tag.  There is some possibility to read/write the eeprom in the tag such if you wanted for example to have a tag set for 100kWh of EVSE use and read what is available and decrement what is available after use - or dream of other ideas what to do with the tag eeprom.


So the ProTrinket approach was nice for proof-of-concept but I really think the NFC tag control code should be on the ESP32.  The OpenEVSE serial bus can connect to only one other board, it must be the ESP.  The ESP can interface nicely with the 3.3V MFRC board and work fine with the 5V OpenEVSE serial bus. For the ProTrinket 5V board I added a little regulator to 3.3V to keep the MFRC happy.


I use one sketch for the ProTrinket to memorize 32bit tag UIDs to the microprocessor's eeprom.  Then download a new sketch to the ProTrinket so it looks for tags and if the tag matches any UID in eeprom it sends the RAPI command to unlock OpenEVSE.  If the tag is detected but the UID is not found in eeprom then it sends the RAPI commands to say "bad tag" and give a short red blink on the RGB LCD.  Lincomatic already had the AUTH_LOCK 1 code in his development branch so all I had to do was fix a small bug that I found in that code.


I have your gmail address.  I'll send you an email about collaboration and such things.


Bye for now,

Craig K.

Login or Signup to post a comment