Wiegand keypad support?

[koffienl]

I stumbled upon this project and it looks very promising. In some spare time I'n building something similar but it's not as extended as this project.
I'm using a wiegand RFID with keypad reader in my project. Looking at the demo and source code it looks like there is no keypad support yet? Is this something that will be added in the future?
Looking through the issues I also saw some questions about support for buzzer, would be a very nice to have to enable.
With buzzer support you could send a command to the ESP to start buzzing so the user is notified to enter a code / tag. Also after accepting a code it could start buzzing to notify the user the system is armed.

Some code snippets I use for keypad support:"

  int timeout = 10000;
  long KeyTimer = 0;
  int keylength = 4;

  // Keep an eye on timeout waiting for keypress after starting with a *
  // Clear code and timer when timeout is reached
  if (KeyTimer > 0 && millis() - KeyTimer >= timeout)
  {
    Serial.println("Keycode timeout");
    CurrentInput = "";
  }

  // When * is pressed start keytimer to capture code
  if (String(wg.getWiegandType()) == "4" && String(wg.getCode(), HEX) == "1b")
  {
    Serial.println("Start capture keycode . . .");
    KeyTimer = millis();
  }

  // When key is pressed AND timer is running AND CurrentInput < keylength AND key is not * or #
  // Then add key to the current input
  if (String(wg.getWiegandType()) == "4" && KeyTimer > 0 && CurrentInput.length() < keylength && String(wg.getCode(), HEX) != "d"  && String(wg.getCode(), HEX) != "1b")
  {
    CurrentInput = CurrentInput + String(wg.getCode());
    KeyTimer = millis();
  }

  // When captured code equals predefined keylength, stop timer and check given code
  if (CurrentInput.length() == keylength)
  {
    Serial.println("Stop capture keycode . . .");
    Serial.println(CurrentInput);
  }

This snippet has a hardcoded length for keypad input, but you could change it to not only start with a * but also end with a # . Further this snippet uses a timeout to prevent the code to wait endless for the user to finish the pincode.

[koffienl]

OK, for the fun of it I did a quick add of code to the main.cpp and it seems to be working. User keypad code looks like it can be quit long (tested with 123456789 as pin). To start keypad you press ```*````` and to finish you press # everything between will be seen as the pin code.
the PICC type of the input will be set as ````PIN````

Add line 75 add

// Variables for whole scope
int timeout = 10000;
long KeyTimer = 0;
String CurrentInput = "";

Add line 500 replace this:

            Serial.print(F("[ INFO ] PICC's UID: "));
            Serial.println(wg.getCode());
            uid = String(wg.getCode(), HEX);
            type = String(wg.getWiegandType(), HEX);
            cooldown = millis() + 2000;

with this:

          // Detect Wiegand26 and Wiegand34 keyfob
          if (String(wg.getWiegandType()) == "26" || String(wg.getWiegandType()) == "34")
          {
            Serial.print(F("[ INFO ] PICC's UID: "));
            Serial.println(wg.getCode());
            uid = String(wg.getCode(), HEX);
            type = String(wg.getWiegandType(), HEX);
            cooldown = millis() + 2000;
          }

          // keypad stuff
          // When * is pressed start keytimer to capture code
          if (String(wg.getWiegandType()) == "4" && String(wg.getCode(), HEX) == "1b")
          {
            Serial.println("Start capture keycode . . .");
            CurrentInput = "";
            KeyTimer = millis();
          }

          // When key is pressed AND timer is running AND key is not * or #
          // Then add key to the current input
          if (String(wg.getWiegandType()) == "4" && KeyTimer > 0 && String(wg.getCode(), HEX) != "d"  && String(wg.getCode(), HEX) != "1b")
          {
            CurrentInput = CurrentInput + String(wg.getCode());
            KeyTimer = millis();
          }

          // When # is pressed stop keytimer to capture code
          if (String(wg.getWiegandType()) == "4" && KeyTimer > 0 && String(wg.getCode(), HEX) == "d")
          {
            Serial.println("Stop capture keycode . . .");

            Serial.print(F("[ INFO ] PICC's UID: "));
            Serial.println(CurrentInput);
            //Serial.println(wg.getCode());
            uid = CurrentInput;
            type = "PIN";
            CurrentInput = "";
            KeyTimer = 0;
            cooldown = millis() + 2000;

Add line 1339 add:

    // Keep an eye on timeout waiting for keypress after starting with a *
    // Clear code and timer when timeout is reached
    if (KeyTimer > 0 && millis() - KeyTimer >= timeout)
    {
      Serial.println("Keycode timeout");
      KeyTimer = 0;
      CurrentInput = "";
    }

[Godferdom]

Thank you for this add!
I was also looking for this enhancement.
It would be really interesting to see it in the initial code.

Regards

[omersiar]

a pull request would be nice. @koffienl If you can test these changes in your setup and come with conclusion that is stable enough i can make it to include on mainstream code base.

[koffienl]

@omersiar I'll try in a few days. This was just quick copy / paste of some code I had. Have to take a better look if it's all OK.

[kodibrain]

hi @koffienl thanks for this add. I have issues when compiling.

[kodibrain]

ah ok it is missing } at the end of replace add line 500 :)

[nardev]

Nice to see this, i had my own code, didn't try to integrate it with repo but it's great to see it.

Also, the buzzer and LED control is important to be added into a repo. Wiegand readers often have those two contrary to other simple RFID boards.

[nardev]

For anyone interested in ESP-RFID board with relay, for Wiegand readers, here is more about it.

#133 (comment)

p.s. check the discount code.

[nardev]

@koffienl contact me please i want to send you this board if you want.

[koffienl]

Been offline couple of days due to holiday :)
@nardev Not sure if your wiegand reader is the same, but mine also has option for blinking the LED and beeping the buzzer. Unfortunately the 2 wires needs to be connected to the ground so I'm afraid you would need a relay in between for this to connect and use, or is that already in the board?
Interested in the board but my solder skills are not that great, at least not great enough to solder a single ESP on a PCB. I'll contact you tomorrow.

For buzzing : personally I need quite a different approach for buzzing that would be to much to incorporate in the ESP-RFID project. I used several type of beeping methods in my project, all based on a simple piezo buzzer and PWM script:

#include <Ticker.h>
Ticker BeeperSlow_ticker;
Ticker BeeperFast_ticker;


// Buzzer
#define NOTE_C7  2093
#define NOTE_E7  2637
#define NOTE_G7  3136
#define NOTE_E6  1319
#define NOTE_G6  1568
#define NOTE_D7  2349
#define BuzzerGPIO 5

int BeeperSlow_timeout = 10000;
long BeeperSlow_timer = 0;
int BeeperFast_timeout = 5000;
long BeeperFast_timer = 0;
String CurrentBeeper;

void BeeperSlow()
{
  if (millis() - BeeperSlow_timer > BeeperSlow_timeout)
  {
    BeeperSlow_ticker.detach();
    BeeperFast_timer = millis();
    CurrentBeeper = "fast";
    BeeperFast_ticker.attach(0.650, BeeperFast);
  }

  if (StopBeep == 1)
  {
    Serial.println("Self detach");
    BeeperSlow_ticker.detach();
    StopBeep = 0;
  }
  else
  {
    long delayValue = 1000000 / NOTE_C7 / 2; // calculate the delay value between transitions
    long numCycles = NOTE_C7 * 300 / 1000; // calculate the number of cycles for proper timing
    for (long i = 0; i < numCycles; i++)  // for the calculated length of time...
    {
      digitalWrite(BuzzerGPIO, HIGH); // write the buzzer pin high to push out the diaphram
      delayMicroseconds(delayValue); // wait for the calculated delay value
      digitalWrite(BuzzerGPIO, LOW); // write the buzzer pin low to pull back the diaphram
      delayMicroseconds(delayValue); // wait again or the calculated delay value
    }
    Serial.println("SLOW piep!");
    delay(100);
  }
}

void BeeperFast()
{
  if (millis() - BeeperFast_timer > BeeperFast_timeout)
  {
    BeeperFast_ticker.detach();
    //BeeperFast_timer = millis();
    //CurrentBeeper = "fast";
    //BeeperFast_ticker.attach(1, BeeperFast);
  }

  if (StopBeep == 1)
  {
    Serial.println("Self detach");
    BeeperFast_ticker.detach();
    StopBeep = 0;
  }
  else
  {
    long delayValue = 1000000 / NOTE_C7 / 2; // calculate the delay value between transitions
    long numCycles = NOTE_C7 * 300 / 1000; // calculate the number of cycles for proper timing
    for (long i = 0; i < numCycles; i++)  // for the calculated length of time...
    {
      digitalWrite(BuzzerGPIO, HIGH); // write the buzzer pin high to push out the diaphram
      delayMicroseconds(delayValue); // wait for the calculated delay value
      digitalWrite(BuzzerGPIO, LOW); // write the buzzer pin low to pull back the diaphram
      delayMicroseconds(delayValue); // wait again or the calculated delay value
    }
    Serial.println("FAST piep!");
    delay(100);
  }
}


void buzz(int targetPin, long frequency, long length, int repeats) {
  for (int i = 0; i < repeats; ++i)
  {
    long delayValue = 1000000 / frequency / 2; // calculate the delay value between transitions
    //// 1 second's worth of microseconds, divided by the frequency, then split in half since
    //// there are two phases to each cycle
    long numCycles = frequency * length / 1000; // calculate the number of cycles for proper timing
    //// multiply frequency, which is really cycles per second, by the number of seconds to
    //// get the total number of cycles to produce
    for (long i = 0; i < numCycles; i++) { // for the calculated length of time...
      digitalWrite(targetPin, HIGH); // write the buzzer pin high to push out the diaphram
      delayMicroseconds(delayValue); // wait for the calculated delay value
      digitalWrite(targetPin, LOW); // write the buzzer pin low to pull back the diaphram
      delayMicroseconds(delayValue); // wait again or the calculated delay value
    }
    delay(100);
  }
}

void BeepOK()
{
  buzz(BuzzerGPIO, NOTE_C7, 100, 3);
  buzz(BuzzerGPIO, NOTE_C7, 300, 1);
}

void BeepWrong()
{
  buzz(BuzzerGPIO, NOTE_C7, 300, 2);
}

This would give the following options:
Call the BeepOK() function to inform the user a code is accepted
Call the BeepWrong() function to inform the user a code (or something else) is wrong
Call the BeeperSlow() function that will slowly start to beep and after a period of time increase the speed of beeping. This 'loop' can be stopped by setting StopBeep = 1
This kind of beeping behavior is more interesting if you use reader for a DIY alarm. When the system is armed and there is movement the beep loop will be initiated to inform the user a code/card is needed. Upon a correct code the beep loop is stopped and a BeepOK() will be played.
But again this is probably way off scope of the project, so I guess I will move only the beeping part of my code to a separate ESP8266 that would only have one goal : play some bleeps based on incoming MQTT messages.

I'll be happy to discuss thoughts and ideas for a DIY alarm in a separate topic if there is interest by others.

[nardev]

@koffienl you would get it complete, just to hook the reader.
Please, can you send me photo of your reader?

The readers i have been using already have a beep on every reed, but, after that initial reading beep, you can add play something you want and play with LED.

[koffienl]

Very much interested in testing. I'll send you an email.

[koffienl]

Mail send, bu having issues with my mail so I can't add attachments. I'll fix that tomorrow so I can send you the promised pictures.

[nardev]

@koffienl hey, I got the email, you can also upload image here on github's comment.

[koffienl]

Added the code to the 0.8.0 version, works nice. Hope to do a longer period test soon

[koffienl]

I'm running a official board from @nardev with editted 0.8.0 to use the keypad. So far I have zero issues.
Not using the cooldown after each keypress is intentional, because mine (and most other wiegand keypad readers) have build-in cooldown. When I'm really fast a keypress might be lost, but that's not due to the code. When I press a number twice very fast the reader doesn't give feedback with LED and beep, so it's a timing 'issue' on the reader and not in the code or board.

[omersiar]

@koffienl Hello,

Are there any updates on this?

[koffienl]

The only update I can give is that it works without any issues at all. Have to build my second reader (same specs, different manufacturer/look) but a 5 minute test with that one was also succes.
I guess it can be incorperated into the code ?

[omersiar]

Yeah i would like to do that.

If this is the latest version of your code let me know, then i will copy it to my branch.
koffienl@0fa2b66

[nardev]

Than, it would be useful to add pin field in users lists next to card number. What others think?

[omersiar]

@nardev we need to test how long does it take to find given pin number in users files. I do not think it can scale with large numbers of users.

This will require to look into every record (parsing json and comparing).

Also how one can choose pin ? What happens when two user wants to have same pin? We can avoid that with additional check but at what cost.

[nardev]

I had this case, in fact i have implemented this but in different environment.. well the procedure is straight forward.. i'll try to make an example in separate branch...

btw, it's easier to remember 4 digit pin than 10 digit card number, that's why.. and pins usually work like "last 4 digit of phone number" so everyone get's it's own easily distinguished.

[koffienl]

In my code the var uid is set to the input, right after closing the PIN with a # symbol. The typeis set to PIN instead of PIC (iirc). Since somehwere in 0.8.0 the ```uid```` changed from HEX to DEC so basicly it's the same as a tag, a bunch of numbers. Currently using 6 digits but you could make a hardcoded max length ?

"Also how one can choose pin ? What happens when two user wants to have same pin? We can avoid that with additional check but at what cost."
I anticipated this for my househould, so everyone can choose their own pin, but it has a 2 digit prefix for a 'usernumber'. Not something you would want to fix with code, but a simple workaround.
So when 2 persons want to have 1234 as a PIN they would each use 011234 or 021234 as their personal PIN.

@omersiar I'll check my current/final code later this evening.

[ke-ss]

This will be really useful when working. I have a NodeMCU ESP8266 12E. I can flash sucessfuly with these provided binaries: 1) 0.9.0 2) 0.8.3 and 3) 0.8.1 and I am able to connect to the wifi hotspot and see the web page for each of these each using 192.168.4.1. However only 0.8.1 will save some of the client settings I input and let me connect through my local modem router.
Perhaps I need to compile with settings placed in the config files rather than use the provided compiled binaries?

[nardev]

My suggestion, try to build from source. It's not hard`

…

On Mon, Dec 3, 2018 at 4:06 PM jas ***@***.***> wrote: This will be really useful when working. I have a NodeMCU ESP8266 12E. I can flash sucessfuly with these binaries: 1) 0.9.0 2) 0.8.3 and 3) 0.8.1. I can connect to each wifi hotspot and then see the page of each with 192.168.4.1. However only the last of these binaries will save the new client settings and then let me connect through my local modem router. MAy be I need to compile with platformio and not use the provided compiled binaries? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#132 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAqe9oxaGHNyu8OEZnaavymgwc2KekKOks5u1T3pgaJpZM4Vqlco> .

[omersiar]

@kessack The only version currently supported is v0.8.1, sorry for the confusing releases lastly. I will remove confusing release now.

[nardev]

@omersiar i'm sorry i didn't trace the reason, why it was not included in 0.9?

I'm just working to merge it with my branch, with some other buzzer and LED options.... but "my way"

Is there any suggestion suggestion you can offer me? Any particular guideline what to add?

[nardev]

@koffienl is it ok if i use part of your code for buzzer? It will be part of new signaling functionalities i'm making for buzzer and for LED signalization.

[nardev]

@peteshoard no, send me an email, i'll send you the version which has that included and some more mqtt options.

[frenchie71]

First of all many thanks for our great software and efforts. I have implemented and tested keypad support with my Gelikom XK1 in the stable branch of my fork of your project based on the suggestions here - feel free to use it. Unfortunately I can't submit pull requests that easily because I did a couple of changes w/r to magic numbers and initially wanted to do HMAC TOTP stuff with Pins over MQTT but abandonned it. here

[omersiar]

@frenchie71 Hello, thanks for your hard work. If you want to push your code to mainstream repository, you should consider working on dev branch. It still can possible to merge them on the stable branch but this will require me to do additional arrangements. Anyway, thanks in advance.

[nardev]

@frenchie71 please, refer the code that i have sent you as from @nardev

[frenchie71]

Hi @nardev , I am not sure if I understand your request - you say that you have sent me code ? When and how did you send it ? Or are you referring to the discussions in this issue ? What exactly is your request ? Are you claiming copyright for portions of the code mentioned in this threat ?

[nardev]

I just opened the commits that you have made regarding the keypad and i noticed some similarities.
Because i made that months ago and that is the fw that i'm shipping on the official boards.

Also i mixed you with @peteshoard so i thought you started merging that code.

Anyway, forget about that.

Regarding the arduino fixing on the current state, i don't think it's solved, also, jsonarduino had major changes. I thought those are most important to be fixed.

[frenchie71]

OK, I see. I was not aware of any functionality that you may have in your official board with that regard. What I did, was to take code out of this thread, Test and improve it and put it into the commit. However, if you have developed and or published it before me, I am totally happy for you to take the credits. I just needed that functionality for my installation and I saw that nobody would push it, so I did.

[nardev]

@frenchie71 i definitely didn't sound ok. I'm glad that you contributed. Thnx.

I'll review and see what to add an how on top of your changes. Do you have some more things going on?

I had "type of locks" so you could use local(gpio pin), remote (http) and remote (mqtt) topic lock.

For example, that was one of changes i had.

I also wanted to make bit more decoupled situation with different segments. To separate things a bit because it's pretty messy now in the code.

Do you have email/slack. Can we discuss somewhere else?

[frenchie71]

Sounds good to me, I have nothing going on in special - wrote everything on the fly - but coupling/decoupling/commenting/documentation seems to be a good approach at this stage of the project - also to help potential contributors to understand the code. I'll send you an e-mail :-)

[evazzoler]

Please, consider the users that don't want to use a RFID tag but pin only.

[Bryan76]

Please, consider the users that don't want to use a RFID tag but pin only.

:: raises hand :: I would be one of those users. I wish to use this project but implement PIN only entrances. (obviously will need to guarantee multiple users don't pick the same PIN).

[peteshoard]

Please, consider the users that don't want to use a RFID tag but pin only.

:: raises hand :: I would be one of those users. I wish to use this project but implement PIN only entrances. (obviously will need to guarantee multiple users don't pick the same PIN).

I'd be happy implementing auth over MQTT separately, passing the uid /code in a kv pair and then sending back a MQTT to open the lock, could even set the delay in that message.

I'm not competent enough to compile myself, looking forward to the next release so I can upgrade.

[evazzoler]

I'd be happy implementing auth over MQTT separately, passing the uid /code in a kv pair and then sending back a MQTT to open the lock, could even set the delay in that message.

It is not a good idea to work synchronously with MQTT via WiFi connection. The authentication should always live on the device and MQTT should give/remove codes asynchronously only.
This way your door will open even when wifi is down (for any reason, including jamming and deauth).

If you need a MQTT managed device, you can search trough the forks of this project. I remember something similar.

It would be nice if one day these very many forks were integrated into a single project. I don't understand why the situation has become so intricate.

[omersiar]

It would be nice if one day these very many forks were integrated into a single project. I don't understand why the situation has become so intricate.

Right, Arduino universe is not always consist from coders. I remember the first few months of this project.

I am currently working on pure REST API version of esp-rfid and probably ditch the MQTT entirely instead it will provide webhooks for events.

[peteshoard]

Rest will be a great edition, but I do use the MQTT door open and auth notifications to activate alarms, CCTV and insert data into a DB for display, without MQTT it won't be possible to do these things I'm guessing

[omersiar]

Does MQTT even reliable in your environment? I do not like the persistent connection nature of MQTT, please correct me if I'm wrong, MQTT require persistent socket connection (TCP) to the broker right?

[evazzoler]

Does MQTT even reliable in your environment? I do not like the persistent connection nature of MQTT, please correct me if I'm wrong, MQTT require persistent socket connection (TCP) to the broker right?

MQTT 5 was improved with a lot of feature present before but not so practical to use.
They are a lot of QOS levels and a "Reconnect Handling" feature that permit to the user to manage broken connections. The "Session Present flag" may be used correctly for managing the reconnection and loos of data.

MQTT offers a lot of out-of-box features that give infinite possibility to the user. i.e. in your environment you can set different brokers, authenticated and not authenticated, public and private, and forward certain topics from one to another and/or vice-versa. They are million of mqtt libraries that are ready to be integrated everywhere (just think about nodered, php, etc.).

I think that persistent connection in a context of "access control system" is not so hard to mantain and will not introduce problems. MQTT was made for supporting a huge number of roaming clients (GPRS in "mobile" mode that loose connection every minutes) and its diffusion demonstrate that it is able to do it. Why to leave a robust, widespread, growing and well implemented protocol for adopting the old fading REST? Is it really so important to avoid well managed persistent connections?

[frenchie71]

It would be nice if one day these very many forks were integrated into a single project. I don't understand why the situation has become so intricate.

hi @evazzoler , could you point me to some of the forks that have additional development please ? that would spare me the effort of scanning all 239. If I look back at myself when I started to pull stuff from Github and amend my own code I was struggling with the Github Fork-Branch-Pull Request work flow, i.e. I simply did not know how to properly submit Pull requests. Maybe it would be worth collecting the code from the forks, contacting the other coders and maybe implement back mainstream ? Happy to help here.

I am currently working on pure REST API version of esp-rfid and probably ditch the MQTT entirely instead it will provide webhooks for events.

@omersiar , With regards to MQTT / Rest API etc. I'd say it would be fatal if we removed features from the software - by my experience this will reduce the number of people using it. I think what we should maybe consider doing is open a separate threat on how to restructure the code in order to make available APIs (Socket, HTML, MQTT....) and readers etc. configurable. I had some talks around this with @nardev a couple of months ago - just thinking it would be worth opening the discussion to the community...

I mean, it would totally be OK to have a stripped down version - in a separate branch - or a separate version for the official board or for stand-alone readers with no network at all - but I would rather love to see everything streamlined in one repo than spread around... What I could imagine is adding the different build targets to the platformio file with -D defines...

[frenchie71]

PS - MQTT works super duper fine in my environment ;-)

[peteshoard]

It would be nice if one day these very many forks were integrated into a single project. I don't understand why the situation has become so intricate.

hi @evazzoler , could you point me to some of the forks that have additional development please ? that would spare me the effort of scanning all 239. If I look back at myself when I started to pull stuff from Github and amend my own code I was struggling with the Github Fork-Branch-Pull Request work flow, i.e. I simply did not know how to properly submit Pull requests. Maybe it would be worth collecting the code from the forks, contacting the other coders and maybe implement back mainstream ? Happy to help here.

I am currently working on pure REST API version of esp-rfid and probably ditch the MQTT entirely instead it will provide webhooks for events.

@omersiar , With regards to MQTT / Rest API etc. I'd say it would be fatal if we removed features from the software - by my experience this will reduce the number of people using it. I think what we should maybe consider doing is open a separate threat on how to restructure the code in order to make available APIs (Socket, HTML, MQTT....) and readers etc. configurable. I had some talks around this with @nardev a couple of months ago - just thinking it would be worth opening the discussion to the community...

I mean, it would totally be OK to have a stripped down version - in a separate branch - or a separate version for the official board or for stand-alone readers with no network at all - but I would rather love to see everything streamlined in one repo than spread around... What I could imagine is adding the different build targets to the platformio file with -D defines...

I think that this should be turned into an extension of Tasmota, let the core of that project worry about MQTT and API stuff, then it's just additional features to slot in.

[evazzoler]

hi @evazzoler , could you point me to some of the forks that have additional development please ? that would spare me the effort of scanning all 239. If I look back at myself when I started to pull stuff from Github and amend my own code I was struggling with the Github Fork-Branch-Pull Request work flow, i.e. I simply did not know how to properly submit Pull requests. Maybe it would be worth collecting the code from the forks, contacting the other coders and maybe implement back mainstream ? Happy to help here.

here: https://github.com/marelab/esp-rfid

But I think it is an abandouned project. Pages on the site give a 404.

[omersiar]

For solely learning purposes, I am working on RESTful API version of esp-rfid. Base features are as below:

Backend

• Bulletproof Wi-Fi handling and bootstrapping (espressif's SmartConfig etc.)
• No support for Websocket, it is causing more issues than being only use case for just getting live RFID tag scan result.
• Log retention, solving bigger data transfer fails between client and server
• Better MQTT connection handling and better scheme for events (you guys convinced me :) )
• Clean, optimized code that conforms SOLID principles
• Health checks (Storage, Wi-Fi, MQTT)
• Time Based One Time Password
• RFID Hardware Abstraction Layer (for tinkerers)
• Schedule Rule Engine ?

Frontend

• WebUI will not be embedded in esp8266 (more freedom)
• React Native framework (Application for almost any screen, mobile, desktop, web, tv)
• Auto finding esp-rfid devices that are connected to same network
• Manage multiple esp-rfid device in one place (orchestration)
• Sync data between devices (users, rules, etc)

Status: POC API boilerplate is ready. No ETA.

[evazzoler]

Great! I'm really excited by this news!

[anethum]

hello together, what is the current state.

does esp-rfid support Pins via keypad? Or only rfid via reader?

[vrelk]

The current code is confusing. The reader returns MSB values, but the code is checking for LSB values and it seems to work.

Reader returns 'A' while the code looks for '1b'. (*)
Reader returns 'B' while the code looks for 'd'. (#)

[matjack1]

Hello, I'm reviving this issue as I've added support for pincode here: #477

Each user has its own pincode on top of the RFID card.

If you have any questions let me know!

[matjack1]

I'm closing this in favour of the more recent issue #492

Also now there's another PR open to cover different use cases of the pin code, here #551