RIFD working, keypad not?

[marktn]

Hello,

What a nice project! I have the RIFD working, only it does not read keypad numbers? I added a pin code to the RIFD, but that didn't work.

esp-rfid Access Control 1.3.5

Any idea?

[matjack1]

hey @marktn are you using the code from the dev branch that you have compiled yourself? Can you confirm you are using the latest code?

If so, can you please share some logs of the serial port while using the debug mode? I guess you have enabled the pincode in the settings? It's off by default.

[marktn]

No i used this version, https://github.com/esprfid/esp-rfid/suites/5709560102/artifacts/188342329 because I had save problems. The link is of another issue, so no idea if it is enabled.

[matjack1]

OK, can you please send me the serial logs of what's going on? Use the debug version as it outputs more info please. Thank you!

[marktn]

How to do that? update to the debug version?

[matjack1]

You can find the debug binary in the package that I've shared above. Then monitor the serial port while the application is running, and please share the log of what happens so that I can try to understand better what's going on.

[marktn]

It only reacts on a tag, not when using the keypad. Is this what you need?

[ INFO ] PICC's UID: XXwasIDXX [ INFO ] Mqtt Publish:{"type":"WARN","src":"rfid","desc":"Unknown rfid tag is scanned","data":"XXwasIDXX 26","time":1648730713,"cmd":"event","door":"esp-rfid-1"} [ WARN ] rfid | Unknown rfid tag is scanned | XXwasIDXX 26 [ INFO ] Mqtt Publish:{"cmd":"log","type":"access","time":1648730714,"isKnown":"false","access":"Denied","username":"Unknown","uid":"XXwasIDXX","door":"esp-rfid-1"} [ INFO ] Mqtt Publish:{"type":"heartbeat","time":1648730723,"uptime":367,"ip":"192.168.1.93","hostname":"esp-rfid-1"} [ INFO ] Nextbeat=1648730903

[matjack1]

Thank you @marktn that's perfect.

Are you using the Wiegand pad, right? Then, have you added the "pincode requested" flag in the settings? You should enable that, it's not on by default.

[marktn]

Where do I find that settings? I could not find that.

[matjack1]

There should be a "Pin code requested" if you pick the Wiegand option in the "Hardware settings". Can you find it? If not, please send me a screenshot so that I can double check, thanks!

[marktn]

Yes i found that, set it to true. Only nothing happens, also in the serial monitor and log there is nothing happening.

[matjack1]

hey @marktn if you have a chance, try this PR: https://github.com/esprfid/esp-rfid/pull/496

You can find the binaries at the bottom of this page: https://github.com/esprfid/esp-rfid/actions/runs/2097087754

[marktn]

No, that did not work. I have programmed a pin in the keypad, that is no problem? Also did use a number that is not programmed in the keypad.

[stupsi099]

@matjack1 with your file from the link with date 5.4.22 and v2board.bin it does not read badges with my HID multiCLASS SE RP10. With the version from 29.11.19 it work. I set the keypad to false - it have not any. Br stupsi99

[Leissson]

Pincode is not working as an only option. It is either RFID or RFID+pincode. @matjack1 do you have any intention to integrate option for only keypad entry?

[marktn]

I need both. But the pincode is not working. Rifd works.

[matjack1]

@Leissson no sorry I don't think it's a good security practice to have pincode only. It's very easy to copy, pass around, etc.

So no, I don't plan allowing that alone nor I do recommend using that, sorry!

[matjack1]

@marktn have you tried with a recent dev version?

Can you try running it in debug mode and pasting here the logs so that I can try understanding what's wrong?

[gorstj]

@Leissson no sorry I don't think it's a good security practice to have pincode only. It's very easy to copy, pass around, etc.

So no, I don't plan allowing that alone nor I do recommend using that, sorry!

It depends on the risk behind the door!

mot should be an option?

[gorstj]

When there is no pin code for a user I still need to press ‘#’ to activate the relay

if there is no code for a specific user I would expect the relay to activate as soon as the card is presented?

[matjack1]

@gorstj

It depends on the risk behind the door!

Sure, but if you just need a pincode I don't think you need the complexity of this project? Or maybe I'm not understanding your use case :)

if there is no code for a specific user I would expect the relay to activate as soon as the card is presented?

yes, it should! If it doesn't work double check if the pincode required setting is disabled?

[gorstj]

I like having a super complex pin code as a backup if I’m locked out without my fob/card (or can text to someone)

I want the flexibility of having a pin for some rfid fobs but not others (some are less likely to be lost than others)

[evazzoler]

@ matjack1 consider different points of view:

1) Pincode cannot broken, cards and token can 2) Pincode cannot be lost but can be forget only. If you forget a pincode nobody can find it, if you loose a card or token somebody can find it and use it 3) If you loose your card (in card+pin mode), nobody can use the card without pin, but you can't use the pin without card 4) In front of a door while you are under threat, you can pass the only card you have, but you can digit a different pin that triggers a silent alarm while open the door

Don't underestimate the benefits of a long secure pin!

[matjack1]

I see your points @evazzoler actually I was thinking of a pin code of 4-5 digits, but I can appreciate what you are saying, makes sense.

It shouldn't be difficult to add this support, I'll do it, maybe we should enforce some complexity level? What do you think?

[evazzoler]

OK. I've implemented a lot of features serverside via MQTT based on a mysql DB. Some people working in home security found some of those functions interesting. If you like, I could list them and you can take what you prefer. It would be better/faster to speak about by phone, then write down a list. I suppose we speak the same language... If you want, I can PM to you my phone#.

[t0bse]

@ matjack1 consider different points of view:

1) Pincode cannot broken, cards and token can

6. if you use this project for a simple door, like in your garden (could also jump over the fence) it's also very useful if only a pincode is required. i think you should implent a pincode with at least 6 digits and warn the user.

[stupsi099]

is there a newer test version (.bin) for my original green board?? the online version 1.3.x have problem with webrefresh. any download link ? br rupert

[matjack1]

@evazzoler thanks, feel free to reach out to me via email if you want :) I don't have much spare time to work on this project, but it's interesting :)

[matjack1]

@stupsi099 you can find the binaries of the latest build of today here: https://github.com/esprfid/esp-rfid/actions/runs/3303810816 at the bottom of the page

[evazzoler]

Hi, I want to help making a recap in what happened these years with the pin "philosophy". Just consider that some users are using esp-rfid in a real world, so changing the games make unusable new firmware with new changed "philosophy". I'm one of those. IMHO the PIN philosophy should be universal OR configurable.

[1.3.1] Pin was supported, but every press of a digit was managed as a single code. This is wrong, useless, don't work.

[1.3.3] Pin was supported and the code was considered sent when "#" was pressed. Correct: most readers send every digit and code are managed access-control-side. That permits to use different pin lenght in one access-control environment. No side effects but flexibility

[1.3.5] Pin is managed only when associated to a card. If I disable "request pin code", pin becomes not managed. Wrong: the user could need to use pin only, the user could need to associate (reader side) a fingerprint to a number sent as card/pin, the user could need to use three alternate methods at the same time: card OR pin OR fingerprint.

So the definitive universal solution should be to manage pin ending with "#" as in 1.3.3 fw version and when "request pin code" is set to true, esprfid expects to receive the user associated PIN ending with "#" after the card code (with reset countdown). It is like asking for 2 different card for opening a door (bank mode, existing in some commercial access control boards). The configurable solution maybe an explosed set of flags about that. Pin configs should not be in the "hardware" page but in "general".

I have a 1.3.3 system for the door at home, a 1.3.1 at office (no pin needed, no upgrade needed, useful to mantain an older version for comparin resons), a 1.3.5 on my desk for testing but unfortunately I cannot use at home door for the unmanaged pin problem.

My reader has 13.56 MHz RFID technology, pinpad and fingerprint (it sends a code associated to the fingerprint user number hashed with a configurable value, so different readers can send the same code with the same finger, seen as a long pin).

OFFTOPIC: changing on the 1.3.5 fw the usercodes with HEX when a card is read, is formally correct, but broke the existing user database and backups. Just mind at a 1000 user DB!

[dplicato]

@evazzoler Thank you for taking the time to write a so clean and helpful recap.

Hi, I want to help making a recap in what happened these years with the pin "philosophy". Just consider that some users are using esp-rfid in a real world, so changing the games make unusable new firmware with new changed "philosophy". I'm one of those. IMHO the PIN philosophy should be universal OR configurable.

I totally agree!

So the definitive universal solution should be to manage pin ending with "#" as in 1.3.3 fw version and when "request pin code" is set to true, esprfid expects to receive the user associated PIN ending with "#" after the card code (with reset countdown). It is like asking for 2 different card for opening a door (bank mode, existing in some commercial access control boards). The configurable solution maybe an explosed set of flags about that. Pin configs should not be in the "hardware" page but in "general".

Sounds perfect!

I have a 1.3.3 system for the door at home, a 1.3.1 at office (no pin needed, no upgrade needed, useful to mantain an older version for comparin resons), a 1.3.5 on my desk for testing but unfortunately I cannot use at home door for the unmanaged pin problem.

I need to use the pincode-only "version": can I ask you which commit of the 1.3.3 version are you using (and which board) to have a general stable environment? Thank you!

[matjack1]

Thank you very much @evazzoler ! It's interesting also for me to understand the history of the project.

Just to understand, when you refer to 1.3.5, are you talking about the dev branch? Or the last stable build? Everything on the dev will go on a 2.0.0 version, for which I'm thinking about the user migration problem you are highlighting, I know about that :(

[dplicato]

Thank you very much @evazzoler ! It's interesting also for me to understand the history of the project.

Just to understand, when you refer to 1.3.5, are you talking about the dev branch? Or the last stable build? Everything on the dev will go on a 2.0.0 version, for which I'm thinking about the user migration problem you are highlighting, I know about that :(

While waiting for @evazzoler reply, I guess he is referring about the dev branch that has a VERSION constant defined as 1.3.5, while the "stable" (branch) is versioned as 1.0.2 (and, FYI, has the keypad reading funcion implemented but broken, only the first keypress is recognized).

About the "retrocompatibility" problem, let me ask: it would be so difficult to re-implement the "universal logic" proposed by @evazzoler described here: "So the definitive universal solution should be to manage pin ending with "#" as in 1.3.3 fw version and when "request pin code" is set to true, esprfid expects to receive the user associated PIN ending with "#" after the card code (with reset countdown)." ?

thanks! dp

[matjack1]

sure it's possible, no problem, I think it has been removed for a security concern, but I plan to re-add it, after some previous @evazzoler comment :)

But I wouldn't advise to rollback to a previous commit of the dev branch as we are changing a few things.

I might be able to get the pincode support back in the next week or so, if that's fine.

[dplicato]

sure it's possible, no problem, I think it has been removed for a security concern, but I plan to re-add it, after some previous @evazzoler comment :)

But I wouldn't advise to rollback to a previous commit of the dev branch as we are changing a few things.

Oh yes, I totally agree that the new pincode-only source code should integrate with the current dev branch.

I might be able to get the pincode support back in the next week or so, if that's fine.

Not only fine, it would be great, thank you!

dp

[evazzoler]

I need to use the pincode-only "version": can I ask you which commit of the 1.3.3 version are you using (and which board) to have a general stable environment? Thank you!

I don't remember the exact commit, I remebrer that I downloaded the compiled binay, it was 1.3.3 and (for a mistake you will read 1.3.1 as version number but it's 1.3.3).

I attach the zipped bin for your convenience.

generic.zip

[dplicato]

@evazzoler thank you very much. Can I also ask you which esp board are you using? Thanks again!

[evazzoler]

Thank you very much @evazzoler ! It's interesting also for me to understand the history of the project.

Just to understand, when you refer to 1.3.5, are you talking about the dev branch? Or the last stable build? Everything on the dev will go on a 2.0.0 version, for which I'm thinking about the user migration problem you are highlighting, I know about that :(

With 1.3.5 I refer to the dev, I'm testing periodically the dev because I'd love to put it in my real door ;-) I test continuosly (with different readers I collect as a RFID-drug-addict) because I want to ensure that no old less used functions are lost. MQTT retro-compatibility is another important thing to consider. I've implemented a node-red system (based on the marelab fork) that basically has those functions:

• time based access (no need to fix the lack of RTC after power fail in a not internet connected system)
• some codes are always valid, other only with unarmed alarm system (i.e. not armed: card, pin, fingerprint - armed: pin only)
• disposable pin or card (setting how many times you can use - 999999 = no limit)
• today only card (setting expiry date to zero, the date will be set to tomorrow at first use)
• giving a delay time after a valid code/card for pressing a single button and trigger a scenario (home automation)
• alarm after a number of fail pin/card triggers alarm system, asterisk, telegram and annouce on google nest / sonos system
• other custom functions I don't remember at the moment

All is based on mysql, codes related to those functions are stored on a mysql server, codes "always available" are stored on esp-rfid (they work in case of connection lost). If I would be a C programmer (unfortunately I'm not!) I would try to port some of those features on esp-rfid instead of node-red, but I'm not able...

I have to say "thank you" for your wonderful work, keeping this project alive and keeping it flying to the future!

I ask a simple question: will be possible to attach to the uart pins an ethernet board, giving to esp-rfid the ethernet capability (more stable and secure!) without changing/redesign the board? (@dplicato : I use the normal board, I ordered the blue but had a issue with italian post service that destroyed a board and stoled 2 boards).

[matjack1]

OK @evazzoler I better understand now. The dev is not going to be 1.3.5, but it's going to be a 2.0.0. And with the v2 we are going to introduce breaking changes. MQTT for sure it's going to change compared to v1 as we have changed quite a bit: https://github.com/esprfid/esp-rfid/pull/501

Unfortunately before it was grown organically and without a clear separation, that hopefully now should be easier to maintain.

In general I think the approach of having esp-rfid as a simple system to extend with node-red is good. As it's much easier to extend and customize a node-red system rather than esp-rfid. Moreover on the esp8266 the capabilities are very limited, so we cannot implement everything here.

Finally, for the ethernet, I see your point, but probably would be better to support ESP32 where ethernet support is more widespread. This is surely not going to happen on v2 initially though. Let's see for the future!

[matjack1]

@dplicato @evazzoler @gorstj @marktn @stupsi099 @t0bse @Leissson I have opened a PR here: https://github.com/esprfid/esp-rfid/pull/551 where you can pick the option between RFID/RFID + pincode/pincode only.

At the moment you can pick only one option, what do you think? Would you like to have more than one option active? At the moment you cannot have more than one option available, as it might be enough and simplifies things. Also right now the RFID cards are stored as hexadecimal numbers, so the options cannot be really used together.

[evazzoler]

I actually use both PIN or Card/Fingerprint (Fingerprint is seen as a card) with the reader I posted here above. My config needs to operate with PIN and Card, not PIN+Card. I think the best way would be to make a checkbox selection...

[matjack1]

I think the best way would be to make a checkbox selection...

The problem is not the UI, but rather the DB of users, that have hexadecimals ids (RFID card id), and cannot be entered with a decimal pin pad, right? How do you deal with that?

Do you have RFID users and pin users?

[evazzoler]

Correct: I have PIN users, RFID users and Fingerprint users. That was possibile until the RFID users DB was converted to HEX. That choice was definitely wrong because introduced no important advantages and kill the possibility to use PIN only users or Fingerprint only users.

Plus you have to convert the old decimal DB to HEX or users willo loose access. Just mind about a 1000 users system...

[dplicato]

The "desiderata" for me would be having PIN users and RFID users as also stated by @evazzoler, PIN and Cards should work independently of each other. This logic was working ok until PR #476 in date 2022-02-04. I think the same as @evazzoler about the fact that there is no advantage on having different storage encodings for PIN and RFID, so I would revert the logic on having all users, PIN and RFID, stored the same way.

[matjack1]

hey @dplicato @evazzoler I've added a commit on https://github.com/esprfid/esp-rfid/pull/551 that does multiple things:

• adds support for pin-code only AND RFID card with pin-code
• lets you pick if you want to read in hex or decimal the RFID card

The default should be hex so that you cannot enter the user id with the pin code only, as we think it's more secure. But if you want to enable that you can.

What do you think? Can you please try it and let me know if it works? Thanks for all the feedback on this!

[evazzoler]

Super, good job! Tomorrow I'll start testing it! Thank you!

Il 15/11/22 10:19, Matteo Giaccone ha scritto:

hey @dplicato https://github.com/dplicato @evazzoler https://github.com/evazzoler I've added a commit on #551 https://github.com/esprfid/esp-rfid/pull/551 that does multiple things:

• adds support for pin-code only AND RFID card with pin-code
• lets you pick if you want to read in hex or decimal the RFID card

immagine https://user-images.githubusercontent.com/65402/201880025-3d6691b8-d719-436a-87a8-5052b04fbfb6.png

The default should be hex so that you cannot enter the user id with the pin code only, as we think it's more secure. But if you want to enable that you can.

What do you think? Can you please try it and let me know if it works? Thanks for all the feedback on this!

— Reply to this email directly, view it on GitHub https://github.com/esprfid/esp-rfid/issues/492#issuecomment-1315020370, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACIKNRG62SKG7SVS66IIGPLWINIRZANCNFSM5RL6VVEA. You are receiving this because you were mentioned.Message ID: @.***>

[dplicato]

Great job Matteo! I sterted testing yesterday, I need 2/3 days to perform some deep testing and I'll be back to you with my feedbacks. Thanks.

[evazzoler]

@matjack1, I've done some test all seems to work great! There is only one thing I woud modify:

When:

User ID storage is set to Decimal Require pin code is set to true Allow pin code only is set to true

In this case:

1. I put the pin code (user ID) and direct open
2. I swap the card with a pin set, then put the pin and open
3. I swap a card with undefined pin and i have to press # for opening

In case 3, undefined pin, the system should open without pressing # (without sending a blank pin), as it works with the case 1. This not only for praticity, but for working with fingerprint without have to press # after the fingerprint is validated. Do you agree with me?

[matjack1]

thank you @evazzoler

I swap a card with undefined pin and i have to press # for opening

actually I didn't think about this, I was thinking that a pin was required, and if a pin is not entered it wouldn't open the door, but probably what you are saying makes more sense. I'll fix it :)

[dplicato]

Hi @matjack1, Finally I found time enough to perform some testing and everything is working fine and as expected, I swapped different pin configurations and did several trials with successfull results. Wonderful, keep pushing!

[matjack1]

ok @evazzoler I should have added support also for the last use case, so user with no pin code, when pin code is required. In this case if you swipe the card of a user that doesn't have a pin code associated, it goes straight to processing mode. It doesn't wait for the empty enter, I thought it wasn't necessary, but let me know if you think differently.

It's ready on the usual PR :)