RFID entry system
RFID entry system | |
---|---|
![]() | |
Name | ESP RFID door controller |
Zone | Infrastructure
|
Owner | i3Detroit |
Make Model | ESP-RFID relay board |
Part Number | |
Date Acquired | |
Storage Location | Mounted to the wall near the door |
Authorization Required | No |
Status | Running |
Value | |
IP Address | a side: 10.13.107.15; b side: 10.13.107.167 |
MAC Address | A side: 58:BF:25:DB:82:7E; b side: 58:BF:25:DC:62:8E |
Hostname | a-side-main, b-side-office |
Documentation | code |
Other References |
Contents
Intro
This is the door controller that controls access to the building
Rules
Instructions
TO ENTER:
- Scan your key against the rectangular LED
- Type in your PIN
- Press enter
- On successful PIN entry, the door will unlock for 3s, then automatically lock
- No audible feedback is given at this time, just try the door as you type the last digit of your PIN
- If you have entry problems, please contact Mark Furland or Amelia Meyer
TO EXIT:
A-Side Main:
- Press the crashbar as normal
- The magnet will re-engage 3s after the bar has been pressed
B-Side Office:
- Press the green EXIT button
- The magnet will re-engage 3s after the button has been pressed
Or just use the door handle
Maintenance Info
Door log is at /var/log/mqtt-door.log
FAQ
ToDo
Known esp rfid bugs (not reported to esp rfid because making test cases is annoying)
- Doors scan as the previous user occasionally
- doors crash a lot when reading the user list
Future Plans:
- make a script that can automagically pull the spreadsheet, but this is a google permissions issue and I think the best way is to create an account that only has read access to the spreadsheet and use credentials from that and I've been lazy.
- Update CRM to replace slot with pin, and put all the keys back in the CRM.
- Cronjob or something to update the doors, but this will need some more error handling because the doors will often crash if you sync twice. You just have to retry, but it's annoying.
Wiring Notes
Keypad connection
From the top of the board the order is
- D0
- D1
- WG (N/C)
- BUZ
- LED
- GND
- VIN
- F1 (N/C)
- F2 (N/C)
colour table
purpose | reader | extension |
---|---|---|
12V | red | brown |
GND | black | brown/white |
D0 | green | green |
D1 | white | green/white |
LED | blue | blue |
beep | yellow | orange |
??? | grey(not populated on all keypads) | orange/wite |
N/C | N/C | blue/white |
non-keypad connections
- Button has a button
- Door Stat: not connected
- 12V
- RSW: Not connected, no idea
- RPDW: Connected to magnet coil
RFID Key Formats
There are three formats for the data in our flavour of RFID:
- 1 26 bit decimal number, just a number, written on keyfobs
- 2 16 bit decimal numbers,
<5 digits>:<5 digits>
, currently (2022-07-29) in the CRM and written on the cards. - the number but as hex It's what is in the spreadsheet right now.
Converting formats
- To go from hex to decimal:
echo 0x05094D8 | perl -nle 'print hex'
0x
is optional
- To go from 2 16 bit to decimal:
echo 80:38104 | perl -laF/:/ -e 'print (($F[0] << 16) + $F[1])'
- To go from decimal to 2 16 bit:
echo 5280984 | perl -ne 'printf "%03d:%05d\n", $_ >> 16, $_ & 0xFFFF'
- Decimal to hex:
echo 5280984 | perl -nle 'printf "0x%X\n", $_'
There is also ablog post and Google Sheet about this.