monkeyboard / Wiegand-Protocol-Library-for-Arduino

Wiegand 26 and Wiegand 34 Protocol Library for Arduino
323 stars 131 forks source link

wg.getcode....without reading fingerprint #18

Closed njordan77 closed 6 years ago

njordan77 commented 7 years ago

Hello, i have an installation with Arduino & Wiegand FingerPrint/RFID reader....all works fine for several months, so the reader provides Arduino with codes and Arduino decides to open the door and even not....

Today, first time after 2 months perfectly working, suddenly during the day without any interaction....the door opened. So my question, is there any chance that the library is suboptimal behaving in certain situation, providing codes....believing codes are coming in without any really communication....some not cleared variables.....

For me its hard to believe that without any fingerprint reading....the hardware from the fingerprintreader provides a code like "123423452" by itself....also the last read fingerprint was a different one from this one......

guess you will understand this for me its tough now how much i still believe in this installation, and also not 100% sure which part failed.....thanks for your thoughts and ideas. Norbert

jpliew commented 7 years ago

Hi Norbert,

I don't think this has anything to do with the library.

There are many situation why your door can open.

  1. Door locking mechanism, loose, not latching properly

  2. If your door is control by single IO pin, there might be a power spike

  3. There could be a bug in your Arduino sketch, stack overflow, buffer overrun, etc

  4. Arduino's IO pin broken

If I am you, I will do this

  1. Install a camera at the reader and door

  2. Capture and store the wiegand data using Serial.println(wg.getcode())

  3. Using oscilloscope to check for power spike

Then wait for another door open by itself.

If you need to community to help you when it next happen, you need to provide

  1. The log of the wiegand
  2. The sketch you are using
  3. Screen shot of the oscilloscope measure the DC power in AC mode https://www.youtube.com/watch?v=eVB_n4t57Yc

Hope this helps.

Cheers JP

njordan77 commented 7 years ago

Thanks. 1) surely not - as any lock unlock is logged via MQTT in my house, so i have seen exactly that arduino (in this case ESP8266 did open the door). 2) you never know, its all shielded with CAT7, but this could happen in any installation.... but again, i have seen in MQTT logs that the uC did react based on a getCode from Wiegand....either there came the code by itself....or (which you know best, and thats what i asked) available() was triggered and it took one of the last "codes" used in history...otherwise i have no idea how the uC could have decided on his own.....and it worked great for 2 months now without any self-opening....(meaning self reading a valid Wiegand Code and opening based on that one) 3....like 2 can of course happen, BUT...if this was the case there would not have been the valid MQTT messages...so this shows that at least the code did work properly and not stack overflow,....if staack overflow had happened, a reboot would have been done which again im my case would have sent a REBOOT mqtt message, which was not the case....

I agree that the actions you describe would make sense to do next, but should one explain that mqtt messages have been sent correctly as if this code would have been received by the uController.

So, therefore my asking was, if artifacts could be taken if a wg.available() happens....and old codes are reused and not received.....otherwise my only idea would be that the READER is broken.

Sidequestion, any success with ESP8266....at least in my case it works normal. (until recent events).

jpliew commented 7 years ago

Hi Norbert,

Now it is starting to make more sense as more information were given, in your case your are using ESP8266 and not Arduino UNO where this library was first created for.

Before we make more assumptions, let's go back to the basic of the problem.

"The wg.getcode returns a valid code and before that a different code was return."

1) Now let dissect ReadD1 and ReadD0, any interrupt that comes in will change _cardTemp and _cardTempHigh (if bit count is over 31)

2) There is no memory that stores previous code in the library, so any pulse that comes in would have changed the initial correct code.

Base on these 2 points, as long as there is a single pulse no matter it is valid or invalid pulse, it would have change the card data. So for the wg.getcode to return the previous data will be hard to make sense.

Since your MQTT logged the codes, and the behavior was the correct one, we can safely say that there is no spike that is opening the door by itself.

Now, the suspects in the first reply are all eliminated.

I would do this:

Setup another real Arduino UNO, and capture the same D0 and D1 together with the current ESP8266. Also logging the UNO's response. By comparing both data, you should be able to figure out what is causing the issue.

Also, coming back to the camera, when the incident happened, were you there? or you got back and found the door opened? I asking this just to find out if the code was a phantom code or someone actually make a scan.

njordan77 commented 7 years ago

Thanks.... regarding ESP - it works pretty good...so most of the time codes are transmitted/interpreted correctly, just like with Ardino - tried both.....only from time to time....like every few days a stack overflow happens and you can see in serial monitor a reboot.....but nothing else happens...like wrong code....door open. Cannot say if this is an ESP issue or Arduino as well, but i guess you perfectly tested with Arduino that such scenario is not happening.

Will have to remove the reader from the wall, which is quite annoying - but to fix this i will have to look deeper.

To your question....no nobody was at home are close. so i found the door open, and checked the LOG of MQTT messages. First believe was that my wife did not lock the door when leaving, but the LOG says that my wife's finger was used to OPEN....and before that my wife was closing the door 2 hours before the unlock event...when she left for work. Sure there is the chance that somebody opened the door with a scan, but hard to believe....its not like my area is very famous for this kind of "business" :-)

jpliew commented 7 years ago
  1. Camera
  2. Another UNO

Should help debug the issue.

Another thing that you might want to check, some reader has last 10 scanned memory, some store 10-99 valid code. Check that too.

Good luck.

jpliew commented 6 years ago

Hey @njordan77 do you have any update for the debugging? Could you update please?