Keyless Entry / Access Control Module, Revisited

Projects
1

After having my implants for a few years now, and barely using them for half that time, I decided it was long enough just thinking about adding RFID unlocking and potentially engine starting to my vehicles. I’ve been thinking about it since before I got them and life got in the way, but I finally came back around to it. Thankfully, there have been a lot of developments since the last time I looked into it (xEM AC was the only thing anyone was really doing). Thanks especially to chimpofm for the SimpleSexy Project and all his research on the subject, and inspiration Completed - Personalized Electronic Nfc Ignition System and Barediver for the same, and porting the code Nissan Hardbody Keyless Entry .

I am not sure if the project was abandoned, or just considered in a good enough state to use, but I decided to build the hardware and work on the software some more. GitHub - msjunk19/chelonian-access: RFID access control · GitHub I have been working on it for a few days, the code has been expanded to:

  • Have Master and User Cards
  • Store the UIDS (Master and User) in EEPROM for persistence and ease of programming
  • Programming mode added
  • Automatic Master Card programming, if none are stored on boot
  • Add/Remove User Cards via Master Card
  • Programming mode automatically exits
  • Built in LED support (can connect external LED to the internal LED Pin)
  • Neopixel LED support
  • NO HARDCODED UIDS AT ALL
  • NO CODE EDITING NEEDED TO DEPLOY TO DEVICE
  • NO PC NEEDED ONCE YOU FLASH THE DEVICE

I feel like I am probably forgetting some things, but everything is currently in a working state, I have plenty more testing I want to do, but thought I would share it here now to get some feedback from the community on features, etc. The docs have barely been updated to reflect the current status, but I am working on that also. I will add some code testing videos tomorrow, its 430am now. I should also mention, that while i do not have the simple sexy pcb, this SHOULD be 100 percent compatible with the existing esp32c3 supermini based hardware, as I havent changed any pin designations, besides adding the led pins. The only thing I havent connected yet is the relay board, but the code for them is working. It currently fires the 2 sequentially like the original code did. Look forward to everyone’s thoughts on improvements I can make!

4 Likes
2

I added a webserver and captive portal after posting. Need to change to LittleFS to serve the pages instead of hardcoding them. If there is no user specified WiFi Access Point saved, the esp will show a default AP to connect to, here the only function is to set up your own Network name and Password. The plan is that the device will not expose any controls on the default credentials, only the single page. Once you set your own, it will give access to change/trigger the device.

2 Likes
3

User Card Programming via Master Card Example

3 Likes
4

Updated the code some more, added LittleFS, parititioning so the areas in flash don’t accidentally clash, captive portal(s). Both are set up as per the post yesterday. I need to go back through the project and refine some things such as the led trigger timing and a few minor improvements. For the most part this is working though. There is even a python script which runs when flashing that also flashes all the files to the LittleFS storage, so you don’t have to add those manually. I am still debating using the WiFi AP, depending on whether or not I can find more security than the AP password to secure it. I haven’t ever tried anything like that so I have to brainstorm on how we could authenticate with the device. Ill post some more videos of the new functionality later! Looking forward to any feedback you all have

4 Likes
5

Been busy the last few days, I have 2 vehicles in for paint right now, but I have been working on this in my spare time. I have ditched the EEPROM library for preferences and refactored all of the storage, additionally, I have added security/device pairing for mobile devices. the user configured captive portal now only sends commands to the device if your device id is stored in memory. In order to pair a device you must have physical access to a pairing button, so this SHOULD remove the ability for someone else to just connect. While the access point can be connected to, if the device hasn’t been paired, it doesn‘t send anything back to the esp. Ill try to get a video of some of the new features later.

1 Like