my system runing on build 119 but v2.0.0 rc0reading mfrc522 empty uuid
oguzatagan opened this issue · comments
hello sorry my bad english.
im using nodemcu my system running on build 119 but sometimes freezing. İ update v.2.0.0rc0 but mfrc522 reading empty uuid. im sharing my config please help.
{
"command": "configfile",
"network": {
"bssid": "aa:aa:aa:aa:aa:aa",
"ssid": "ssid",
"wmode": 0,
"hide": 0,
"pswd": "password",
"offtime": 0,
"dhcp": 1,
"ip": "",
"subnet": "",
"gateway": "",
"dns": "",
"apip": "192.168.4.1",
"apsubnet": "255.255.255.0",
"fallbackmode": "0"
},
"hardware": {
"readertype": 0,
"wgd0pin": 4,
"wgd1pin": 5,
"sspin": 15,
"rfidgain": 32,
"wifipin": 255,
"rtype": 1,
"ltype": 0,
"rpin": 5,
"rtime": 20,
"doorname": "diskapikilit",
"beeperpin": 255,
"ledwaitingpin": 255,
"openlockpin": 255,
"doorbellpin": 255,
"accessdeniedpin": 255,
"useridstoragemode": "hexadecimal",
"requirepincodeafterrfid": true,
"allowpincodeonly": false,
"removeparitybits": true,
"doorstatpin": 255,
"maxOpenDoorTime": 0,
"relay2": {
"rtype": 1,
"ltype": 0,
"rpin": 4,
"rtime": 400
},
"relay3": {
"rtype": 1,
"ltype": 0,
"rpin": 4,
"rtime": 400
},
"relay4": {
"rtype": 1,
"ltype": 0,
"rpin": 4,
"rtime": 400
},
"numrelays": 1,
"pincoderequested": false
},
"general": {
"hostnm": "diskapi",
"restart": 500,
"pswd": "password",
"openinghours": [
"111111111111111111111111",
"111111111111111111111111",
"111111111111111111111111",
"111111111111111111111111",
"111111111111111111111111",
"111111111111111111111111",
"111111111111111111111111"
]
},
"mqtt": {
"enabled": 1,
"host": "192.168.1.5",
"port": 1883,
"topic": "diskapi_kilit",
"autotopic": false,
"user": "user",
"pswd": "password",
"syncrate": "180",
"mqttlog": 0,
"mqttha": 1
},
"ntp": {
"server": "pool.ntp.org",
"interval": 30,
"timezone": 3
}
}``
Hello.
The same thing happens to us.
The TAG UID does not appear.
Although the system works correctly with the tags that were already registered, from what I understand that the reading is correct, it seems that it is only a display problem
In the access LOG for existing tags, it records the correct opening, but the UID as zero and the user undefined.
We have it installed on the blue relay board.
I've just flashed version 2 and have the same issue
I've also flashed the dev version and uuid are's not being recognised @omersiar is this a known problem to you as this is stopping it being used right now, thanks
I fixed this by editing rfid.esp and recompiling
I changed this line:
uid += String(mfrc522.uid.uidByte[mfrc522.uid.size - (i + 1)] < 0x10 ? "0" : "");
Back to the old way from previous versions
uid += String(mfrc522.uid.uidByte[i], HEX);
Recompiled and uploaded the bin file and it works
@plex3r, @oguzatagan, @juanvaab et al.
Given the solution plex3r has found this is likely related to a previous issues. see: issues #466 and #586
Prior to the fix UIDs were read incorrectly if a hexadecimal byte in the UID had a leading zero, that zero would be dropped in converting to a string e.g. Card UID ED0BA996 read as EDBA996.
So the newer version of the code which corrects this may now read the correct UID which then will not match the UID saved by the older version of the software users are upgrading from. As this error might create other complications and problems in future it might be wiser for those upgrading to correct their user databases to have the incorrect UIDs changed to the correct UIDs rather than retrograde the new software back to the old code so it will read their old database with incorrect UIDs as plex3r seems to have done.
You can easily check this by seeing the UID in your old database and comparing against the UID for the same card using an NFC reader on say an Android app.
Please confirm @matjack1, @windy54 and @hinkma
ooo-xxx
@Divyastra no the issue is that the latest stable release just doesn't work correct when using an RC522 as the reader with the current code which is why I went back to the previous way of doing it.
The version 2 release candidate in rfid.esp has just the line
uid += String(mfrc522.uid.uidByte[mfrc522.uid.size - (i + 1)] < 0x10 ? "0" : "");
All this does is convert a UID that has a leading 0 to 00 if the card has no leading zero's it just reports a blank UID
Actually adding
uid += String(mfrc522.uid.uidByte[mfrc522.uid.size - (i + 1)] < 0x10 ? "0" : "");
uid += String(mfrc522.uid.uidByte[i], HEX);
Doesn't even really solve the issues because a UID of 04 52 01 79 is stored as 40521079
@plex3r and @matjack1 ...
Pseudo code:
OLD_uid += String(mfrc522.uid.uidByte[i], HEX);
NEW_uid += String(mfrc522.uid.uidByte[mfrc522.uid.size - (i + 1)] < 0x10 ? "0" : ""); NEW_uid += String(mfrc522.uid.uidByte[i], HEX);
IF (NEW_uid != OLD_uid) AND OLD_uid is in database pass the card but also create new user in database using old user data using NEW_uid and delete OLD_uid entry.
This might alleviate upgrade issues, make new code backward compatible and transmute old database to new database over time.
ooo-xxx
@plex3r to be honest the code @windy54 and I implemented was a little different and worked for us, the code you see in the new release that you have pasted was supposedly a more elegant solution by @hinkma, i'd need to review and check the code when i see Steve (windy54) maybe this evening. In the meantime it might be worth your reviewing the code and issue as shown in #466 to see if that is relevant to you and this issue.
Also what you are saying is the dropped zero is recovered but the bytes hex characters ends up being switched. If so we have databases with two incorrect forms of UIDs
ooo-xxx
@Divyastra I had a look at those in that issue I don't see how to implement your code in rfid.esp if you can help I'll test it.
Windy's code is not what has been included in the dev branch which the latest firmware build is based on, well it is sort of but it's missing the second line, however in my testing it still doesn't represent UID's correctly exactly as you say it's swapping the characters
Found a use for my flipper zero here testing :)
@plex3r Time permitting I'll check tonight with Windy as it is important we get this right because it will also break the database if it's wrong when we switch hardware from mfrc522 to weigand as is planned for our hackspace. As to my understanding the wiegand code produces the correct UID.
ooo-xxx
Ok after playing around with many many code snippets from the interwebs I've got something that works with leading zero's
for (byte i = 0; i < mfrc522.uid.size; i++)
{
uid.concat(String(mfrc522.uid.uidByte[i] < 0x10 ? "0" : ""));
uid.concat(String(mfrc522.uid.uidByte[i], HEX));
}
Tried to use code tags didn't work so well
@Divyastra @plex3r I don't have a MFRC522 sensor, so unfortunately I cannot test this yet.
If you both can confirm that one PR works I'll get it merged into dev, thank you very much!
@matjack1 my pull request #613 I've just tested on a nodemcu board with RC522 reader with several cards plus flipper sending one that begins 04 and it recognises the uid's correctly.
I did move the rfidState = cardSwiped; statement out of the for loop and it doesn't appear to have introduced any unwarranted behaviour
Thanks
I have got to re-configure our test setup with a 522 reader and then I will investigate and get back to you.
We reckon it needs the second line
@plex3r, @matjack1 & @windy54
Ok sorry for any delay and confusing code snipits.. @windy54 handles our implementation and testing for the hackspace and his test bench is currently configured for testing the transition to weigand readers and he will need to reconfigure for 522 before testing. my test bench was dismantled years ago when windy took over. I managed to get my head around the code again this morning and my postmortem comments follow but should be treated as theoretical and untested.
AFAIK... the code windy and I proposed in #466 should work. @hinkma proposed what appeared to be a more elegant version and I think that was then adopted but without fully testing. Also only half of hinkmas solution was propagated to the code branch. you need both lines for it to work and would explain why the uid results are coming out as zero or blank.
For some reason hinkma chose to index the uid byte array in reverse uidByte[mfrc522.uid.size - (i + 1)]
instead of forwards and directly as in the original code uidByte[i]
in any case for the modified solution you MUST be consistent in which you use for both lines:
Hinkmas solution was:
uid += String(mfrc522.uid.uidByte[mfrc522.uid.size - (i + 1)] < 0x10 ? "0" : "");
uid += String(mfrc522.uid.uidByte[mfrc522.uid.size - (i + 1)], HEX);
but this ought to work equally well:
uid += String(mfrc522.uid.uidByte[i] < 0x10 ? "0" : "");
uid += String(mfrc522.uid.uidByte[i], HEX);
This is actually equivalent to Plex3r's proposed solution which uses concat instead of +=:
uid.concat(String(mfrc522.uid.uidByte[i] < 0x10 ? "0" : ""));
uid.concat(String(mfrc522.uid.uidByte[i], HEX));
You would need to check if the endianess of the resultant string is reversed
You CANNOT mix the two as Plex3r tested and failed and i mashed together in my suggestion about backward compatibility without properly examining the code and possibly leading to the confusion, my apologies:
WRONG:
uid += String(mfrc522.uid.uidByte[mfrc522.uid.size - (i + 1)] < 0x10 ? "0" : "");
uid += String(mfrc522.uid.uidByte[i], HEX);
@plex3r somewhere you also mentioned taking a line out of the loop, I can't find that comment now but as i recall it was the final assignment of the completed uid after constructing the string, yes to my recollection we did the same when we worked on #466 as the assignment only needs doing once at the end not repeatedly in the loop.
Sorry I'm not in position to test the code atm but just as soon as windy has reconfigured and tested we can get back to you. Especially i think we need to confirm endianness of string. What is most important for us is that the resultant uid string from the 522 matches the uid from the same card via a weigand reader so when hardware is transitioned from one type of reader to another the database isn't broken.
ooo-xxx
@Divyastra some more testing needs to be done with the wiegand code vs the 522 code
I've just tested with 2 boards 1 run my fix for 522 board and another running the same code but using a wigand reader in 36 bit mode
522 reads a uid as 22d3dad6
This is consistent with what my flipper zero reads the uid as
However the wiegand data is seen as d6dad322
Thanks
@plex3r Yes I think you are right and that's why i haven't recommended go on your PR just yet.
@windy54 and I have both tested the PR today independently and it works fine just as you report and it is our preferred version to implement. (In our case we were checking against an Android NFC readers output UID rather than Flipper, but we still concur).
Windy has also reported the Wiegand output UID is reversed as well and I was going to confirm that, this weekend having rebuilt my test bench and compilation tools today.
We also tested the reversed access of the RC522 byte array as @hinkma had suggested and it too results in a correct but reversed UID that would match the wiegand UID. I suspect that was his motivation. i.e. to make it match the wiegand UID.
Whilst that would make both consistent internal to esp-rfid without needing to change the wiegand code I do have a preference that it also match other readers such as flipper and android NFC Readers etc. external to esp-rfid i.e. consistent in all cases, that way manual entry of a UID can also be performed when UID reading has been done on some other device without need for mental acrobatics to reverse UIDs etc.
Windy has also reported another issue with the wiegand output, that in certain circumstances requires a divide by 2 or bitwise shift right (which I haven't got my head around yet) before the data will match (In addition to the bytewise reversal of the UID). He has code that will correct for this that I would like to check also.
I think this would be the subject of another issue/bug report beyond the scope of the present issue and may face much more resistance to change if there are large numbers of wiegand users who's system just work for now and don't want or need a breaking change.
In our case we are currently using RC522 and are about to transition all our units and thus the database to Wiegand so it's important to us.
So I want to understand the implications of the wiegand issue properly before making recommendations on the PR on this RC522 issue i.e. PR as is or with reversed UID as per hinkma's solution to make it compatible with the existing wiegand code without need to change. Saving a code change to wiegand might however prove to be moot if there is a divide by 2 issue that needs changing the code anyway.
@matjack1 an opinion on this would be valued please.
ooo-xxx
Wiegand is 24 or 32 bit my reader can do both with a simple additional wire connected to ground to enable 32bit mode
We will also be using a mixture of 522 and wiegand readers and will need the uid's to match but ideally as you say they should produce standard expected UID's as per other readers.
For now I will use my own local copy with the fixed 522 code because as it stands the code in the release just doesn't work.
If some wiegand readers reverse the output but not all then there would potentially be a need in the UI to have a check box to enable reverse datastream or similar configurable for a per device setting
@plex3r
A quick update and call for quick test:
So yes we will likely have to do a local fork as well.
I don't want to blowup my remaining nodemcu so i'm exercising caution with the one wiegand reader i have access to which is 12v and TTL output. Windy has his different wiegand reader attached to an original esp-rfid board so will I'll have to check what precautions were taken to ensure TTL logic tolerance on that schematic.
@windy54 has code that kind of returns correct value for his reader which is 32bits possibly no parity ( I need to verify that) which he has decoded the 32 bits by probing on d0 and d1 with logic analyser. manually decoding gets us the correct result as we would have on the rc522 BUT byte reversed. So he has re-reversed the bytes and undone the shift right that deletes the parity in software and gets the correct result for the cards he's using.
However, I have started trawling through the wiegand code to understand it and I think I have found another place leading zeros are dropped but in the wiegand code and would appreciate your help confirming it.
So on the rc522 code string was used to convert from hex to ascii one byte at a time. As we know if the byte had a leading zero that was dropped by string function. We have now corrected for that.
In the wiegand code the card id is returned as an unsigned long i.e. the whole ID in binary/hex it is then converted to a string as a whole....using the string function! I suspect a leading zero will also be dropped here. As you can fake a card using your flipper it will be a lot easier for you to check than for us to find a test card with suitable UID.
Try hypothetical UID=0fd50204 please
I believe rc522 will return 0fd50204 as expected for the corrected code.
I believe returned UID from byte reversing wiegand will return 402d50f i.e. the last but one hex digit was lost as it became a leading zero on reversal.
I believe returned UID from non-reversing wiegand will return fd50204 i.e. leading zero dropped on whole UID.
In either case this symptom will only manifest if the leading hex digit or last but one hex digit is a zero in either case respectively.
(for completeness old rc522 code would have returned fd524 which will be what is in old databases on transistioning i.e. 3 lots of leading byte zeros dropped)
So if this proves to be correct then the same fix applied to the rc522 code may also need to be applied to the place where the wiegand uid is converted to a string line 57 of rfid.esp if i'm not mistaken.
It's a shame the rc522 code doesn't return the same unsigned long as well and the string conversion done in the same way in the same place regardless of reader type.
If I don't manage to comment again before a Very Merry Festive Seasons Greetings to all reading this :)
ooo-xxx
Attn: @matjack1, @plex3r & @windy54 et al.
Note to coders:
I believe the code for pn532 readers will have the same bytewise dropped leading zero issue as rc522 has.
Refer to lines 143 to 147 of rfid.esp in dev branch. The same code fix as suggested in PR by plex3r for rc522 should perform for pn535 as well if corrections made at this location with another PR after someone with a pn535 reader verifies.
Objective: make all readers give same resulting UID so multireader systems can mix reader types and database isn't broken when transitioning between reader types. All these fixes WILL beak existing databases where dropped zeros have already propagated into the database. Wiegand Databases easily corrected rc522 and pn535 databases will require reregistration of only affected cards to the database.
ooo-xxx
I've ordered a pn532 to test with.
Just to let everyone know, I am using latest DEV branch to test our 522 reader and it is no longer reading cards.
I have gone back to the dev branch with no changes for correcting the UID or inverting wiegand bits.
I know my reader is ok because if i load an arduino sketch it reads cards.
The wiring and configuration is identical between arduino and esp code.
With the esp code I get a collision error.
Steve
@windy54 what code gives a collision error? and at what point does this manifest?
Thanks
@matjack1 & @plex3r
So I've been focusing on the logical errors for card's UIDs being zero or leading zeros being dropped. I have however noticed severe delays and timing errors and periodic resetting on my setup (latest Dev branch with debug flag on). I had shrugged off these as possibly due to blocking delays from excessive debug messaging using sprintf etc, a problem i've had in the past and ignored them whilst i concentrate on issue at hand.
This morning I noted the comment from @snegokmf (Sergey) on #606 which might bear further investigation as some of those symptoms are recognisable and may be related to the problems @windy54 is having atm. The slow response and long delay in relay on time (30 seconds instead of 400ms) only occurs in AP mode the system is responsive in client mode when it's working but still shows instability and a propensity for boot loops.
If I can figure out how to pulldown an older version of the code previous to the commit Sergey mentions, I might test changes on that first.
ooo-xxx
For the Wiegand reversal of bytes issue I have "fixed" my own copy tonight and now the UID when read from a Wiegand reader is byte reversed to match that of an RC522 reader
If anyone wants to test it I'll update my github later
Well my byte reversal works but if a uid should start with a 0 then it gets dropped and it also doesn't currently work for 7 byte uid's either.
I think for now I'm going to have to stick with 522 readers in all my devices until someone cleverer than me can look at and fix the wiegand code
I've updated my test code and can now reverse 4 byte uid's from a wiegand reader and add a leading zero if it gets dropped, it's crude but seems to work basically looks at the length of the resultant string and if it's 7 characters then adds a leading 0.
This still however doesn't work for 7 byte uids
@windy54 the code for 522 reading uid's in the dev branch is comepletely broken which is what my first pull request fixes if you want to check it out
@plex3r I'll be getting back on this in a couple of days, just a quick note in the mean time:
- the wiegand code taps out at 34bit wiegand codes which are actually 32bit+2paritybits so always returns a 32bit unsigned long as a result. codes less than 26bits treated as pin number entry as i recall. So 7 byte uid's aren't an option atm in any case and should be dismissed as a use case for now.
- I'm switching to use of snprintf to manage char array construction with any number of dropped zeros as you can specify number of significant digits required with padding '0' characters. This is instead of using tests for zero followed by String() to perform string constructions and zero padding. This will be for rc522 pn532 and wiegand to give consistent results in terms of character length of UID.
- the wiegand code has an option for formatting the UID string as a decimal instead of hex, i believe this is to accommodate manual entry of uid on a keypad, this would make it inconsistent with the strings produced by rc522 and pn532 in a multireader system. Although I don't think this scenario would ever be employed (i.e. decimal entry on keypad in one location and card entry for same user in another location or optional card entry using the same reader) a simple fix might be to allow decimal entry of uid but to render back to a hex string to make it consistent. Unless @matjack1 et al. can give us good reason to leave rendering of string as decimal in certain circumstances?
- UID byte order reversal would be trivial directly on the returned unsigned long before conversion to a string if it wasn't for variable UID lengths (and possible choice of DEC/HEX rendering). I will work through that when i have both cases in front of me on test bench.
- Windy's 522 issues are hardware reading issues even after your PR fix or my new fix using snprintf
Happy New Year to all reading this.
ooo-xxx
Hey @plex3r, thank you very much for the PR #613 ! I have now a sensor to test MFRC522, so I was able to check your code :)
It works, thank you very much!
I haven't followed all your comments here, but the last point where @Divyastra have mentioned me, I think it's fine to have only HEX here, there is no pinpad in MFRC522 sensors unlike for the Wiegand sensors (not all of them, but some).
So I think we are good here :)
I'm going to close, but if you still have problems please reopen. Thank you very much all!