Closed njordan77 closed 6 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.
Door locking mechanism, loose, not latching properly
If your door is control by single IO pin, there might be a power spike
There could be a bug in your Arduino sketch, stack overflow, buffer overrun, etc
Arduino's IO pin broken
If I am you, I will do this
Install a camera at the reader and door
Capture and store the wiegand data using Serial.println(wg.getcode())
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
Hope this helps.
Cheers JP
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).
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.
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" :-)
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.
Hey @njordan77 do you have any update for the debugging? Could you update please?
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