Support for multiple readers, enter and exit

[akeilox]

While reading through the mfrc lib issue discussions as well as trying out various mfrc522 examples I noticed many utilizing the SS pin to support multiple mfrc522 readers connected to the same mcu.

In a typical setting, say for a door, an entry and exit readers would be the most common.

So my question is would you consider adding support for (at least) 2 mfrc522 readers where they can be initialized by SS pin individually

mfrc522.PCD_Init(enter); mfrc522.PCD_Init(exit);

but work in the existing logic, with perhaps sending the id (enter/exit) of the read to JSON (sendDataWs)

With such one could send the json to a remote .php to make a simple access control of entry and exits with timestamps and deviceid. Understand the current logic sends to the websocket for its IP, but the modular approach enables such neat integration - from my limited understanding.

Would like to hear your thoughts on this.

[omersiar]

current logic will change, i just tried to see what can be done with websocket, i am not a c++ coder just a hobbiest :).

Multiple rfid readers can easly be achieved, but what is hard is the determining the cable lenght for SPI bus and it's not much that long but simply enough for inside and outside readers on the same door.

if there are multiple doors and great distance between them, modules can be communicate over wi-fi.

I am still trying to convience myself about working flow. i always considered that device should be complete embedded device which requires nothing, no 3rd party server, no post or get http requests, etc. this way users benefit ease of use. but i really do not know flash and ram would be enough for that case.

learning javascript, html dom, etc stalls the progress, currently, there are many little things need to be solved, and of course ultimately how should it will be work.

feedbacks are always welcomed. thank you for your interest on this project. kind regards. 👍

[akeilox]

I appreciate the current design because of few simple facts:

1) i have initially started with arduino uno, running EEPROM example happily as standalone. Unlimited reads and limited writes were a concern that I tried to get my head around. Also the other shortcoming that one had to re-do everything if one card lost and wants to get it deleted from allowed list.

2) then i wanted to add "somehow" async call to server after door opened, to log the access. Only to find out using the Ethernet shield and the client.writeln() functions are buggy with delays and it rendered the whole concept impractical. Even using wired ethernet I couldn't get basic reliability. If it did work reliably I thought I can make an end-point in the code where the server (access log master) will push a code with the card to be deleted and it'll sort of 'sync' the EEPROM. Quickly realized this is not viable with arduino ethernet shield being unreliable from the get go. Its 2017 and WiFi could do better.

3) after which i was interested in esp8286 simply because it had all in one, reliable networking, allows to create its own wifi to manage it without server dependance, and tiny size fits the embedded logic well. Better handling of Network stack and powerful processor (two cores) with the upcoming esp32.. well it seemed to be the perfect medium.

In your last iteration I think you hit that sweet spot, and using websockets it makes lot of sense why one cant open async socket to server optionally.

In last iteration, system turns on with no assumption of internet/LAN and provides AP and set pw. And one can quickly check and add allowed cards within browser, in a headless setup (no screen, no buzzer, even no led lights). With NTP server to get the time logged right, and pushing card communication to a websocket layer. which I thought its brilliant.

Following the logic and workflow as standalone-first with optional server communication fits very nicely in my opinion. One can enable the functions when needed.

The SPIFF of 3M (even 1M) is plenty enough for storing 1K++ records and its pretty amazing when I learned about it. And if stored in a format like JSON, it can be communicated over network to server which can return an "updated" JSON which client can read and write back into SPIFF.

Perhaps MQT to facilitate events like entered from MainDoor, exit from SideDoor at timestamp .

When I see the settings page with option to change SS/RST pin and discussions of multiple readers (SPI bus cable length being not so flexible), it made a lot of sense to fix the pins (cause wemos, nodemcu, 8286, esp32 all works with a little or no change, which can be done on compile time) for Exit unit (optionally). This way we wont tackle dealing n number of readers but a simple unit of setup (door with enter and optional exit unit, with cable length being reasonable in this use case, optional network access control/server integration).

If the Settings page allows to set a name for the "device" like MainDoor. and default is enter SS, with optional exit SS to define. With a Relay pin and delay x ms field configurable.. This makes a perfect setup fully utilizing the rather limited pins on Wemos/8286/alike.

Its a stanalone system but with few settings change one can enable two readers, enable MQTT, enable server async call to designated end-point (for those who wish to do their own php/aspx, which needs to follow the JSON schema already defined). And may be an optional end-point/websocket to receive a PUSH from Server to delete a Card or Synch.

The settings page pin selection will simply change to enter/exit pin and I can see the existing UI can easily accommodate these and the underlying logic.

If cable distance too far? then simply add another unit and call it door2/point2 etc. But enter/exit definitely makes a lot of sense since cable length will be within SPI limits. Adding another unit just for the exit of same door will not be taking advantage of whats available.

I am more than willing to assist where I can, as I truly believe the path you taken is the correct one with possibilities (within reach) to make this a great neat setup!

[omersiar]

UNO EEPROM or AVR Eeproms in general, covers years of usage, even if you write it to many times a day. So that would not be a problem.

When i deployed basic EEPROM version to my apartment's door, I quickly realized the problem with lost PICCs, it would require coordination between residents to re program it. I did not touch my setup since it 's deployed, so much hassle to deal with, but it's just an apartment's door which can be opened even with physical brute force, so the security of the system was not a big concern. Since 2014 it just works and people are happy with it because it just quickly give you the access.

Then ESP8266 hit the market, there were no Arduino Core back then, then community made a huge step by releasing Core for the Arduino IDE, but it was buggy and not quite reliable, again, back then.

Core is now matured enough, there are multiple libraries to choose from, etc. Which makes really easy to built a solution around it. So here we are, building it.

Easy communication with device makes operations much more smooth, removing a user's RFID tag with a smart phone is now considered no big deal, but this comes with a drawback, we need more and more code, for smart phone specific code, handling IP address, gateways, SSL certificate for encryption, securing websocket communication, HTML, JS, you got the point.

By the way, @rocadura https://github.com/omersiar/RFID522-Door-Unlock/tree/master/SD_v2 made a great work by introducing standalone Ethernet version.

https://github.com/omersiar/RFID522-Door-Unlock/pull/12

And also ESP is dirt cheap compared to Arduino Yun or Raspberry Pi.

I can add support for multiple RFID Hardware on same ESP MCU. Also I am in touch with rfid library developers for implementing simple Interrupt method, which is way more convenient.

[omersiar]

There are multiple example of this, and likely ESP-RFID will support more than one RFID reader, but the real pit fall is hardware part.

[arjobo]

Hi, sorry for opening this issue again but I'm very interested in this project and congratulate for this great job. Have you thaught making a mesh version so all esp8266 can be synchronised? There are some interesting libraries available like https://github.com/Coopdis/easyMesh

[arjobo]

This library is more active and a clone of easyMesh https://gitlab.com/BlackEdder/painlessMesh

[omersiar]

i taught it once, while this issue was rised by @akeilox. But the implementing this will be horrible for me, low level meshing would be hard. you may want to install two esp-rfid and sync data between them via backup and restore facility.

[arjobo]

I need at least 8 synced esp-rfid. Connecting to just one for granting and revoking access would be the ideal solution. It sounds like the easyMesh library abstracts you from low level meshing. If a node connects to the mesh network the access list could be synchronized. Another posibility would be having a master esp-rfid and every change made to the access list would invoke a websocket call to the other know esp-rfid slaves.

[omersiar]

Painless mesh looks promising and whole meshing thing is interesting. Since we are supporting JSON messages by default it can be arranged.

[arjobo]

I will have a look on it and share my findings. Thanks for your feedback.

[omersiar]

@arjobo Different network configurations needs different handling, and painless mesh requires a bridge between ESP-RFID network and mesh network. For example you will need an ESP8266 for ESP-RFID and another to bridge ESP-RFID to mesh network.

I do not like the idea of more hardware, I will try to implement more simple approach where one ESP-RFID will act as a master and other ESPs can join to network and query UIDs.

[arjobo]

In the master/slave pattern wifi range should also be taken into account. It could be that a far slave cannot reach the master and should therefore query UIDs through other nearby slaves. A pitfall of just one master would be that an outage of the master would bring down the whole access control. I think syncing is a must between ESP-RFID nodes so they can operate individually.

[omersiar]

If one node which is connected to master is reachable from another node then it can query master via the nearest node, this is not a self constructing mesh network as painlessMesh do, Admin should configure each node. Each network node should reach the master either via another node or directly or via router. If connection couldn't make to master, nodes can query their latest inventory which will be synced from master. This is the workflow, implementing will be hard for me, especially syncing inventory part.

Fork latest version, change settings page for node networking (AP Mode part will be hard coded, invisible, BSSID, and RSSI required for the admin to distinguish nodes between them)

mDNS query for finding master's ip, if cannot reach subnet of master ask connected node to query master.

Implement websocket client which will query the master.

Implement inventory sync between nodes and master (also from node to node) (inventory is actually user data which is a file on SPIFFS and contains JSON string) nodes can query master for inventory time to time, first checks all the UIDs if there is a mismatch from master, node asks for the missing data, once its done, UIDs should be synced, but also user data can be change from time to time. when admin make changes on user data master also can send changes to nodes, node can ask master for UID file integrity it can be hashed for checking or we does not care differences and get all the data from master.

This is overwhelming, I can not promise that this ever will be implemented. It's an interesting task, and loved the idea, also there are still fundamental features waiting to be implemented to ESP-RFID before this.

For now you can simply deploy ESP-RFID where ever you want and use backup and restore facility

[arjobo]

I understand completely that this is overwhelming and as you indicated an interesting task. For sure their are different ways of implementing this, perhaps a mesh network is not the ideal solution but having independant ESP-RFID nodes each their own access list and be synchronized between each other would be the way to go and will also be scalable. Based on your coding efforts and feedback I will try to make a prototype with 8 ESP-RFID synced nodes.