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 asPIN````

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.

https://github.com/omersiar/esp-rfid/issues/133#issuecomment-410448552

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. https://github.com/koffienl/esp-rfid/commit/0fa2b662ab84111c7ac831d0423f03e57ca2da20

[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 notifications@github.com 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 https://github.com/esprfid/esp-rfid/issues/132#issuecomment-443741869, 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.

[koffienl]

@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.

Of course, no problem. It's just a simple buzzer :)

[svrooij]

@omersiar what would need to happen to have this implemented? I got already got your board in the mail and I would really like it with the support for pin’s. Do you need some help with that?

[omersiar]

I believe @koffienl's code is matured by now, i do not have the hardware myself, so i am waiting for a pull request.

Maybe @nardev will make it happen when he has time.

@nardev there was a websocket bug with the 0.9.x where the settings were not be saved, @Pako2 solved it recently.

And current dev branch can now be worked on it.

[svrooij]

Want me to donate money so you can buy this keypad? https://rover.ebay.com/rover/0/0/0?mpre=https%3A%2F%2Fwww.ebay.nl%2Fulk%2Fitm%2F232384491546

[omersiar]

Thank you for the offer, but i can not accept it. You can put a bounty on this issue though, it may be picked up by willing coder.

[svrooij]

I just posted a bounty for this issue. Hopefully this will get you guys motivated to fix this faster. https://www.bountysource.com/issues/61614375-wiegand-keypad-support

[nardev]

I just posted a bounty for this issue. Hopefully this will get you guys motivated to fix this faster. https://www.bountysource.com/issues/61614375-wiegand-keypad-support

I did it but didn't try to push it. I had huge issues back at home so.. :(

I hope today..

[nardev]

Here is the thing.

I spent quite some time about this issue. And at the end, it was not possible to just add this easily.

The code that i made has some fundamental changes on esp-rfid and i would like to hear your thoughts.

Here is my explanation:

• So far, the uid was card number because it was only relevant index, there was no need to handle duplicate checks or have any mechanism of validation

• I had to change that approach and uid now in approach is actually timestamp or randomized alphanumeric string of 12 chars.

• That way, i believe we could be pretty safe even when in future if have multiple devices interconnected and exchanging the cards and access lists. Because of that change, now in user file i have more data. I have "card and "pin" and uid is re purposed as i explained.

• Another problem is import/export which i'm yet to complete. And for sure it will require procedure for importing old user config files.

• Also, what has changed is adding and editing new users. In order to do that, every time user is added or created, the card number and pin must be checked in order to confirm that it doesn't exist already.

• Also, in order to validate pin/card, now there is "cards" and "pins" json index that is always generated on device start OR it could be switched to "/users/cards/[card_number]" and "/users/pins/[user_pins]" index system which actually consists files which would hold user IDs "uid" numbers.

So the validation would go like: Enter Pin or Swipe Card => Check Pin/Card in Pin or card Index files or Json boject => if exists, get the UID and check if "/users/[uid_number]" file exists => if it does, open it and check permissions. => if ok, open the doors.

Right now it works like this: we directly just validate if card number exists as file name in "/P/[uid]" and then => check permissions and see if it is ok to open doors.

So, do you want me to push this?

[omersiar]

@nardev Hello Vedran,

I think this is bringing some complexity, on the other hand @koffienl 's approach was simpler but we did not receive any feedback from him/her lately.

Let's push your code to the separate branch, i will prepare beta release for it, this way people can test it with their hardware. When we finish coding of backup & restore and other details we can merge it to mainstream code.

Also my apartment has same pin for everyone approach for the main entrance door. I do not think complex security measures required for places like apartments.

And for maker spaces and etc. pin can be a little puzzled like this

"Standart PIN + Day of the month" this can be rendered as for today "123430"

assume 1234 is the standart pin known by every member of the place and 30 is the number of the day of month.

Puzzle can be set by Web UI it can be like this (This will require time to be synced)

Enable Puzzle ? - [ ] Yes Do you want to append it or prepend it? Please select a puzzle : Day of the week to PIN Day of the month Minute Minute + Day of the month

Also it can be different for odd and even numbered days.

[nardev]

I must admit that the puzzle is very interesting approach. I haven't seen it implemented.

You are right about the "complexity" in the base solution that i mentioned. But i was guided by some industry expected standard solution. It's pretty much what any developer would expect it to be.

[mcd1992]

Was contemplating opening another issue but this one seems relevant.

As a feature request it might be nice to have a 'two-factor auth' plugin system. Let people write plugins for something like keypad 2fa or even just a telegram message for 2fa.

[omersiar]

@mcd1992 nice idea, the only problem i can imagine is blocking nature of keypads (i am not sure btw)

[stephanflug]

Hallo bin hier neu und habe eine Frage.Habe folgendes Gerät im Einsatz https://www.amazon.de/gp/product/B07KZX57JV/ref=ppx_yo_dt_b_asin_title_o05_s00?ie=UTF8&psc=1 die RFID-Karte werden richtig angezeigt nur beim eingeben eines Zugangscode über der Tastatur kommt immer nur die erste Zahl und nicht mehr.

[nardev]

@stephanflug because keypad support is stil pending. I have the code for it but i have to finish testings. in 1.1. it will be available.

[Netoperz]

I do see some potential problems with this implementation as far as i can see from proposals.

1. Some keypads that are standalone controllers with terminal mode as an option, use to enter to the programming sequence. So when user is pressing the keypad is waiting for the mastercode of that particular hardware for entering setup. I have got 8 or 10 keypads and they all do the same.

More secure approach is to check for input,and put the input to the buffer, counting the buffer content. In my co i'm forming the bufffer, and filling with -1 (impossible input from keypad) than i just write the keypad input. and i'm checking if the particular place in buffer is different than -1, for example for 5 digit pin if buffer4 >-1, than the buffer goes to char array and is forwarded to verification if it exist in the database.

As for the "time for input" and "clearing the incomplete input" i'm using the systicks to count the loops, and i'm checking if buffer 0> -1 if it is, and counter limit is reached, and the pin digit input number is not reached the buffer is cleared, exactly filled with -1.

This solution works perfect over two years on 16 doors in publicly used building.

here is the code of the wiegand task. Also You need to initialize the buffer and so on...

` unsigned int WiegandInputCouter = 0; unsigned int WiegandInputCouterLimit = 150;

void WiegandWorkerTask(void *parameter) { while (true) { if (wg.available()) { runInputConfirm(); WiegandInputCouter = 0; Serial.print("WG HEX = "); Serial.print(wg.getCode(), HEX); Serial.print(", DEC. = "); Serial.print(wg.getCode()); Serial.print(", WG TYPE "); Serial.println(wg.getWiegandType()); unsigned long currentCodeProcessing = wg.getCode(); if (isCardCode(currentCodeProcessing)) { processingCardCode(currentCodeProcessing); countCode = 0; clearBuffer(); } else { countCode++; if (countCode < 6) { codeBuffer[countCode - 1] = wg.getCode(); LCD__keypad_input_counter(); for (int i = 0; i < 5; i++) { clearBuffertIfHash(); Serial.println(codeBuffer[i]); } if (codeBuffer[4] > -1) { processingCodeViaBase(); countCode = 0; delay(8); // was 1000 } } } } else { if (codeBuffer[0] > -1) { WiegandInputCouter++; if (WiegandInputCouter == WiegandInputCouterLimit) { WiegandInputCouter = 0; countCode = 0; clearBuffer(); Serial.println( "CLEAR MEM. BY W.I.C."); } } } delay(5); } }

==== clear the buffer manualy using # void clearBuffertIfHash() { for (int i = 0; i < 5; i++) { if (codeBuffer[i] == 13) { WiegandInputCouter = 0; countCode = 0; memset(codeBuffer, -1, sizeof(codeBuffer)); LCD_closed_status_screen(); runBuzzerClear(); // runLedClear(); Serial.println("CLEAR MEM. #"); } } }

`

I'm not sure that i will help here, but this approach is more user friendly than need to press special keys, and you may define the pin code length modifying the code to be relative, it's just some code i had around and i tough that it may help as an idea.

[nardev]

The keypad is not problem at all, the issue is once you make it, you have to implement pin as accessing way.

However, then, you would have parallel pin and card as ide, than there is an issue because you would have to maintain two different index lists and whole sets of functions to maintain unique pins and cards and combinations. and so on...

[Netoperz]

@nardev In my model, both pincodes and cards are using the same index list, in backend panel You can input card number on pin in the same field. Mifare Card Serial Number is the unique identifier defined in ISO 14443-3A. There are 3 types of UID defined in the standard - single ( 4Byte ), Double ( 7 bytes ) and Triple ( 10 bytes ). Only older versions of the Mifare card, the UID was 4 bytes but now have migrated to 7 bytes. So in 99% of situations You will have not less than 7 bytes for card. User pincodes are most likely shorter. I do not know a place where users use 7bytes long pincodes.

That could give a way to filter pincodes vs card numbers (that's what i'm doing in my solution, i've sent you some code to show)

Second solution is as You said to have two acess lists. Reader when You read the card UID sends long value with UID. When user is inputing pincode it sends one inpyt per keypress, so there is a way to differ the card input and the pin input and veryfy using separate functions on separete lists. Again that's the way i'm doing it.

I'm not the pro developer, i've just learned a bit just to write the functionality, that's all. Is the pincode functionality availble in dev branch ? or not pushed yet to github ?

[omersiar]

I think I convinced myself on how to put thorough the keypad on esp-rfid.

• Independent from Wiegand protocol an abstraction layer would cover the supporting the multiple keypad hardware.
• When we done finish implementing hardware abstraction layer, it is only used to consume given pin into HMAC-TOTP to verify the pin, since we already have NTP functionality this would not require a real time clock.
• Devices that are not connected to Internet still will require manual time synchronization or pin codes will get denied if there is time mismatch between User and the esp-rfid.
• With this way any RFC 6238 complaint authenticators can be used like Google's and Microsoft's
• This require users to have their mobile phones to be with them (who doesn't these days?)
• There will be manually generated (each time when all of them are consumed), one time only pin codes (lets generate generously of 10 pin codes) for access without a mobile phone. Since they are ephemeral and consumed each time used they needed to be replaced through WebUI by admin.

[akeilox]

@omersiar thats a great plan to integrate mobile authenticators like Google and Microsoft.

However what will be the maximum number of records, theoretically, that can be stored in the default flash?

My understanding was that the current build can store up to 1,000 users i.e. cards (I refer that from the hackster io article I read, I might be wrong here).

How such an authenticator pin code integration will affect the max user number in this case ?

[omersiar]

@akeilox It is based on HMAC-TOTP so it does not need to scale by user number. It just verifies if the given pin is authentic in a time window by cryptographic functions (not by checking given pin in a list of pins).

[akeilox]

Oh I see what you mean, you get this figured out.

For clarification what is the max number of users (card ids) that can be supported in current build? I recall there was some sort of test done long time ago but cant seem to find it.

[omersiar]

https://github.com/esprfid/esp-rfid#scalability

It is not guaranteed, please test yourself and share your findings.