Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Wiegand keypad support? #132

Closed
koffienl opened this issue Aug 1, 2018 · 85 comments
Closed

Wiegand keypad support? #132

koffienl opened this issue Aug 1, 2018 · 85 comments

Comments

@koffienl
Copy link

koffienl commented Aug 1, 2018

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
Copy link
Author

koffienl commented Aug 1, 2018

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
Copy link

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
Copy link
Collaborator

omersiar commented Aug 3, 2018

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
Copy link
Author

koffienl commented Aug 3, 2018

@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
Copy link

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

@kodibrain
Copy link

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

@nardev
Copy link
Collaborator

nardev commented Aug 4, 2018

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
Copy link
Collaborator

nardev commented Aug 4, 2018

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
Copy link
Collaborator

nardev commented Aug 4, 2018

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

@koffienl
Copy link
Author

koffienl commented Aug 5, 2018

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
Copy link
Collaborator

nardev commented Aug 5, 2018

@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
Copy link
Author

koffienl commented Aug 6, 2018

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

@koffienl
Copy link
Author

koffienl commented Aug 6, 2018

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
Copy link
Collaborator

nardev commented Aug 6, 2018

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

@koffienl
Copy link
Author

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

@koffienl
Copy link
Author

koffienl commented Sep 3, 2018

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
Copy link
Collaborator

@koffienl Hello,

Are there any updates on this?

@koffienl
Copy link
Author

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
Copy link
Collaborator

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
Copy link
Collaborator

nardev commented Sep 26, 2018

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

@omersiar
Copy link
Collaborator

@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
Copy link
Collaborator

nardev commented Sep 26, 2018

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
Copy link
Author

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
Copy link

ke-ss commented Dec 3, 2018

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
Copy link
Collaborator

nardev commented Dec 4, 2018 via email

@omersiar
Copy link
Collaborator

omersiar commented Dec 4, 2018

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

@nardev
Copy link
Collaborator

nardev commented Dec 26, 2018

@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
Copy link
Collaborator

nardev commented Dec 26, 2018

@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
Copy link
Collaborator

nardev commented Aug 29, 2019

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

@frenchie71
Copy link

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
Copy link
Collaborator

@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
Copy link
Collaborator

nardev commented Sep 12, 2019

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

@frenchie71
Copy link

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
Copy link
Collaborator

nardev commented Sep 12, 2019

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
Copy link

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
Copy link
Collaborator

nardev commented Sep 12, 2019

@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
Copy link

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
Copy link

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

@Bryan76
Copy link

Bryan76 commented Jan 20, 2020

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
Copy link

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
Copy link

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
Copy link
Collaborator

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
Copy link

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
Copy link
Collaborator

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
Copy link

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
Copy link

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
Copy link

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

@peteshoard
Copy link

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
Copy link

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
Copy link
Collaborator

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
Copy link

Great! I'm really excited by this news!

@anethum
Copy link

anethum commented Feb 20, 2020

hello together, what is the current state.

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

@vrelk
Copy link

vrelk commented Mar 17, 2020

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'. (#)

@omersiar omersiar unpinned this issue Apr 2, 2020
@matjack1
Copy link
Collaborator

matjack1 commented Feb 3, 2022

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
Copy link
Collaborator

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests