PN532 NFC / RFID Reader, x-fache Tagerkennung

  • Damit ich in Zukunft auch mit NFC Tags arbeiten kann, habe ich versucht, den für mich funktionierenden Aufbau mit einem RD6300 RFID Reader, durch einen PN532 zu ersetzen.
    Folgende Schritte habe ich hierfür durchgeführt:


    Vorabeiten
    - Hochrüsten des DoorPi von Version 2.5.0.1 auf 2.5.0.4
    - Test aller bisher angewendeten Funktionen, inklusive des RDM6300 RFID Readers
    - Einbringen aller erforderlichen Module und Änderungen für den PN532 anhand der von Andreas (Nea) gemachten Beschreibung. (Sehr gut zusammengefasst und ausgearbeitet).
    - Im Unterschied zu Nea’s Beschreibung habe ich die Installation unter /libnfc und nicht unter /home/pi/libnfc gemacht. Lag daran, dass in der Beschreibung das Installationsverzeichnis mit "/libnfc" und nicht mit "./libnfc" angegeben ist. Sollte aber keine Nachteile bringen.


    Test der PN532 Installation
    python /libnfc/trunk/examples/tagtool.py --device tty:AMA0:pn532
    [nfc.clf] searching for reader on path tty:AMA0:pn532
    [nfc.clf] using PN532v1.6 at /dev/ttyAMA0
    ** waiting for a tag **
    Type2Tag ID=A11F222B


    Der Test verläuft meines Erachtens erfolgreich. Wird z.B. die Receive Leitung des Lesers getrennt erfolgt eine Fehlermeldung. Daher gehe ich davon aus, dass die Anbindung des PN532 in Ordnung ist.


    Einbringen der Konfiguration in der „doorpi.ini“
    [keyboards]
    virtuell = filesystem
    prodsystem = piface
    # rfidreader = rdm6300
    nfcreader = pn532


    [nfcreader_InputPins]
    A11F222B = sleep:0


    [nfcreader_keyboard]
    device = tty:AMA0:pn532


    [EVENT_OnKeyPressed_nfcreader.A11F222B]
    10 = take_snapshot:http://guest:jpeg@192.168.5.55:80//dms.jpg
    20 = out:Garagentor,1,0,1
    30 = mailto:<Meine.Mail@Adresse,TK-6241 %d.%m.%Y um %H:%M Uhr,A-4 Relais wurde betaetigt,True


    PN532 mit DoorPi
    Wird das RFID Tag nur kurz an den Leser gehalten, wird die vorgesehene Funktionalität, ein Relais zieht an, ausgeführt.


    Logfile:
    2016-06-06 15:57:34,114 [DEBUG][doorpi.keyboard.from_pn532] tag: Type2Tag ID=A11F222B
    bis
    2016-06-06 15:57:35,711 [TRACE][doorpi.action.handler] [5NSUPS] finished fire_event for event_name OnKeyPressed_nfcrfidreader.A11F222B


    Fehler
    Wird das RFID Tag länger (ab 1 Sekunde und länger) an den Leser gehalten, wird die vorgesehene Funktionalität mehrfach ausgeführt.


    Logfile:
    2016-06-06 15:58:07,384 [DEBUG][doorpi.keyboard.from_pn532] tag: Type2Tag ID=A11F222B
    bis
    2016-06-06 15:58:10,227 [TRACE][doorpi.action.handler] [Y627DT] finished fire_event for event_name OnKeyPressed_nfcrfidreader.A11F222B


    Frage:
    Ich habe im Forum keine Hinweise auf ein derartiges Verhalten gefunden. Daher wollte ich im ersten Ansatz diese Meldung nicht als „Issue/Bug / Problem“ eintragen. Vielleicht bin ich ja der Einzige mit dem Problem und habe irgendwo etwas bei der Installation / Konfiguration übersehen. :/


    Kennt jemand dieses Verhalten und kann mir mitteilen, wie man die Mehrfachausführung unterbinden kann?


    Gruß
    Ewald

  • bringt leider keinen Erfolg. Ich denke mal, dass die Anreize selbst ja auch nicht durch das Hochsetzen einer Zeitkomponente verloren gehen.


    @Nea
    Aber vielleicht mal die direkte Frage an Dich. Wie sieht das denn bei Dir aus, wenn Du das Tag etwas länger an den Reader hältst? Was sagt Deine Logdatei?
    Ist dort tatsächlich der Vorgang:


    2016-06-06 19:38:17,184 [DEBUG] [doorpi.keyboard.from_pn532] tag: Type2Tag ID=A11F222B
    2016-06-06 19:38:17,186 [DEBUG] [doorpi.keyboard.from_pn532] ID: A11F222B
    2016-06-06 19:38:17,186 [DEBUG] [doorpi.keyboard.from_pn532] ID gefunden: A11F222B


    nur einmalig zu sehen?


    Gruß
    Ewald

  • Das ist tatsächlich ein Bug, da müsste pula nochmal schauen. Danke fürs melden!


    @pula
    Könntest Du dir das nochmal anschauen bitte, natürlich nur wenn Du ein wenig Zeit und Lust hast.
    Wenn ich den tag dranhalte und meine 3 sek. Türöffner abgelaufen sind fängt das Relay an zu flattern. Wie gesagt aber nur wenn man den tag durchgehend dran hält. Könntest Du hier bitte einen sleep von ca. 5 sek. noch einbauen, danke.

  • Danke fürs Ausprobieren. Vielleicht noch ein Gedanke:
    Bei Dir dauert es anscheinend 3 Sekunden, abhängig von der Türöffnerzeit. Bei mir liegt die Zeit kürzer, da mein Relais nur für 1 Sekunde arbeitet. Das Flattern des Relais habe ich übrigens auch.


    Meines Erachtens müßte das Problem im libnfc Bereich zu lösen sein. Denn eine erneute Tagmeldung sollte erst nach einem erneuten Anlegen des Tags erfolgen. Diese Abhängigkeit kann eigentlich nur im libnfc Bereich gecheckt werden. Für die darüber liegende Applikation, hier DoorPi, ist es schwierig den wirklichen Ist Zustand zu erarbeiten.


    Gruß
    Ewald

    • Offizieller Beitrag

    Jetzt ist es hier hoffentlich gelöst:
    https://github.com/motom001/DoorPi/tree/pn532_bouncetime


    Installation mittels Anleitung Pi2 + Jessie (Release 2016-02-26) mittels manueller Installation
    Branch ist "pn532_bouncetime"


    Oder die Änderungen manuell übernehmen:
    https://github.com/motom001/Do…93ab0448871b454fa20524c5f


    Bitte gebt mir eine Rückmeldung, ob das Problem damit gefixt ist. Dann übernehme ich das in den master-Branch.


    Es gibt dann in der ini einen zusätzlichen "bouncetime" Parameter für das keyboard - default 2000 (Angabe in Millisekunden)

    Code
    [keyboards]
    nfcreader = pn532
    [nfcreader_keyboard]
    device = tty:AMA0:pn532
    bouncetime = 2000

    Somit sollte das Flattern unterbunden sein. Ihr könnt die Bouncetime natürlich auf 30000 hochdrehen, dann gibt es für 30 Sekunden lang keine Meldung mehr.
    Wenn ein solcher Tag übersprungen wird, dann gibt es eine Debug-Log-Eintrag "founded tag while bouncetime -> skip"

  • Hey Thomas danke für die schnelle Reaktion, Was mir noch aufgefallen ist wenn der Pi kurz vom Stromnetz geht und danach wieder bootet startet DoorPi nicht mehr da der Reader nicht mehr gefunden wird. Hier liegt wieder das gleiche Problem vor da das Keyboard nicht beendet wurde hängt sich der Reader auf oder ist exklusiv belegt. Zur Arbeit lässt sich der Reader erst dann wieder bewegen wenn man die Spannung am Reader kurz kappt. Das ist zwar ein seltsames Verhalten da der Reader ja in der Zeit wo der Pi Spannungslos ist dann eigentlich auch Spannungslos ist aber leider verhält sich der Reader so.


    Nachtrag:
    Doorpi kann man dann nicht mehr als deamon starten als Anwendung geht es aber seltsamerweise. Hier bringt erst ein Reboot Abhilfe.
    @RaspiEHU
    Könntest Du das mal bitte gegen checken, danke.


    -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
    @motom001
    Das Problem das Ewald beschrieben hat ist nun bei mir weg. Danke.

  • Hallo Nea,
    habe gerade den PI mal für 1-2 Sekunden stromlos gemacht und wieder eingesteckt. Bei mir ist DoorPi wieder hochgelaufen und funktioniert inklusive Reader.
    In Deinen Beiträgen habe mitbekommen, dass Du die Stromversorgung nicht standardmäßig für den PI einspeist. Das ist bei mir nicht so. Da ist alles Standard, heißt, dass alles an der Mini-USB des PI hängt.


    @motom001
    Das mit dem bouncetimer funktioniert und ist, wie von Dir beschrieben im Logfile zu sehen.

    @motom001
    Das Problem das Ewald beschrieben hat ist nun bei mir weg. Danke.

    Na ja, so ganz weg ist das nicht. Wenn das Tag auf dem Reader liegen bleibt, wird nach Ablauf des bouncetimers der Vorgang wiederholt. Es läuft jetzt aber wesentlich entspannter ab.
    Daher Thomas, bitte drinlassen. Mit dem Workaround kann man sehr gut leben. Eine "normale" Bedienung ist jetzt möglich. Ohne wäre der Reader, zumindenst für meinen Anwendungsfall, nicht brauchbar. Danke hierfür.


    Gruß
    Ewald

    • Offizieller Beitrag

    Na ja, so ganz weg ist das nicht.

    Nur rein von der Logik her: Wie würdest Du es Dir wünschen?


    Der Workaround von mir merkt sich, wann irgendein Chip das letzte Mal erfolgreich aufgelegt wurde. Wird irgendein Chip erneut erkannt und die "bouncetime" ist nicht abgelaufen, dann wird nichts gemacht. Da führt zu Problemen wenn der Sohn 10 Sekunden nach mir das Haus betreten will.


    Eigentlich müsste, wenn ein Chip erkannt wurde, die neue Chip-ID gleich der letzten bekannten Chip-ID ist und die bouncetime noch nicht abgelaufen ist, die bouncetime erneut gesetzt werden. Sollten sich die Chips unterscheiden, dann ist alles gut und bouncetime ist egal. Der Gedanke ist Richtung KeyUp und KeyDown und somit die Feststellung ob der Chip aufgelegt oder weggenommen wird. Dann wäre es wieder sehr angenähert an die anderen Keyboards - ist das praktikabel / realistisch?

  • Hallo Thomas,


    Sorry für die späte Antwort.


    Dein letzter Vorschlag hört sich gut an. Damit sollte für die meisten Anwendungen die Problematik gelöst sein. Für meine Belange finde ich den Vorschlag praktisch und praktikabel.


    Sollten sich die Chips unterscheiden, dann ist alles gut und bouncetime ist egal.

    Damit ist bestimmt gemeint, dass die bouncetime für die erste ID beendet und für die neue ID gestartet wird.


    Gruß
    Ewald