Ankündigung

Einklappen
Keine Ankündigung bisher.

eKey Fingerscanner per RS485 auslesen: Protokollanalyse

Einklappen
X
 
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

    Moin moin,

    ich habe meinen eKey FSB Türgriff jetzt testweise angeschlossen an das eKey REG4 Steuergerät und getestet! Die Erkennungsrate lässt auch ein wenig zu wünschen übrig ... Habe das Kabel mit Scotchlok Verbinder verlängert, soll ich hier lieber Lötverbinder einsetzen oder hab hab ich das ganze System zu oberflächlich konfiguriert?

    Vielen dank im vor raus :-)

    Kommentar


      Zitat von tuxedo Beitrag anzeigen
      Vielleicht hilft es dir den Java Code anzuschauen? ---> https://github.com/tuxedo0801/ekeyde...eyDecoder.java
      Danke, das muss ich erst mal querlesen ... Testen geht dann erst in 14 Tagen

      Kommentar


        Zitat von FFitzner Beitrag anzeigen
        Moin moin,

        ich habe meinen eKey FSB Türgriff jetzt testweise angeschlossen an das eKey REG4 Steuergerät und getestet! Die Erkennungsrate lässt auch ein wenig zu wünschen übrig ... Habe das Kabel mit Scotchlok Verbinder verlängert, soll ich hier lieber Lötverbinder einsetzen oder hab hab ich das ganze System zu oberflächlich konfiguriert?

        Vielen dank im vor raus :-)
        Ich habe Lötverbinder mit Feuchtigkeitsschutz benutzt, sowas hier. Müsste aber mit Scotchlok genauso gehen.
        Musste da nur dran, weil das Verbindungskabel zwischen Fingerprint und Auswerteeinheit beschädigt war.

        Hast Du jeden Finger 3mal angelernt ?
        >>Smelly One<<
        >> BURLI <<
        Grüße Armin

        Kommentar


          Moin moin,

          ja ich habe die Scotchlok mit Fettfüllung verwendet ... Lötverbinder hatte ich gerade leider nicht zur Hand ...

          Aber mittlerweile haben wir uns angefreundet ;-) Habe alles auf Werkseinstellungen zurück gesetzt und nochmal neu eingerichtet, seither ist die Erkennungsquote nahe der 100%!

          Habe den jetzt auch mehrfach angelernt! Das Problem fängt ja schon damit an, wir haben diesen Türgriff und hier ist ein anderer Scanner verbaut, was ich vorher auch nicht wusste...

          Liebe grüße aus dem Norden :-)

          Kommentar


            Hi zusammen!

            Ich hatte auf meinem Raspi ja das Problem, dass die Finger nicht immer erkannt wurden. Mit dem Umzug von smarthomeNG auf mein NAS Laufwerk hab ich jetzt auch den Converter umgesteckt. Im Großen und Ganzen hab ich das Gefühl, dass das recht zuverlässig funktioniert. Allerdings erhalte ich immer wieder mal Fehlermeldungen, nach denen dann die Erkennung quasi dahin ist. Ab dem Zeitpunkt geht nix mehr. Jetzt könnte ich das vielleicht über einen Logcheck bzw. Monit-Service oder so abfangen, aber vielleicht hat sonst noch jemand ne Idee.

            Ich nutze den Converter direkt über den seriellen Port. Hatte auch schon Versuche mit ser2net und socket gemacht, gab aber auch dort einige Probs.. Hier der Fehler:
            Code:
            2016-11-14 16:46:26.077 INFO [EkeyDecoder] de.root1.ekeydecoder.Ekey$1.fingerhashReceived: Send string '46h/Riki ZF r' to 10/0/1
            Exception in thread "EkeyDecoder" 2016-11-14 17:01:04.610 WARNING [main] de.root1.ekeydecoder.Ekey.work: decoder terminated. Stream closed.
            java.lang.ArrayIndexOutOfBoundsException: 1024
                    at de.root1.ekeydecoder.EkeyDecoder.byteReceived(EkeyDecoder.java:214)
                    at de.root1.ekeydecoder.EkeyDecoder.run(EkeyDecoder.java:276)
                    at java.lang.Thread.run(Thread.java:745)
            2016-11-14 17:01:04.610 INFO [main] de.root1.ekeydecoder.Ekey.main: Trying to get connection back online in 5sec...
            2016-11-14 17:01:10.045 INFO [main] de.root1.ekeydecoder.Ekey.main: Config: type='DEVICE'
            2016-11-14 17:01:10.674 INFO [main] de.root1.ekeydecoder.Ekey.main: Config: setting='/dev/ttyUSB1'
            2016-11-14 17:01:10.675 INFO [main] de.root1.ekeydecoder.Ekey.main: Using Device-Mode: '/dev/ttyUSB1'
            Config: RS232Config{portName=/dev/ttyUSB1, baudrate=115200, databits=8, parity=0, stopbits=1, flowcontrol=0, timeout=1000}
            2016-11-14 17:01:11.677 SEVERE [main] de.root1.ekeydecoder.RS232.<init>: null
            gnu.io.PortInUseException: ekeydecoder
                    at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:340)
                    at de.root1.ekeydecoder.RS232.<init>(RS232.java:65)
                    at de.root1.ekeydecoder.Ekey.<init>(Ekey.java:76)
                    at de.root1.ekeydecoder.Ekey.main(Ekey.java:194)
            
            Experimental:  JNI_OnLoad called.
            tuxedo , kannst du damit vielleicht was anfangen und den Fehler abfangen bzw. einen Neustart von ekeydecoder erzwingen, wenn sowas kommt? Vielen Dank!

            Kommentar


              Ich versuche die direkte serielle Schnittstelle zu vermeiden, da die ganzen Libs die es da draußen und die Java den Zugriff auf die serielle Schnittstelle erlauben, alle nicht so prickelnd sind. Netzwerk hingehen geht ohne Lib. Da lasse ich lieber Linux die Adaption "Rs232->Netzwerk" machen (ser2net). Das mache ich seit vielen Jahren auf unterschiedlichen Systemen so, auch mit Java. Probleme gab's da nie.

              Der Fehler deutet auf ein solches Lib-Problem hin.

              PortInUseException heißt so viel wie: Da gibt's eine Kollosion in Sachen Zugriff auf die serielle Schnittstelle. Evtl. hast du den Java-Prozess zweimal laufen?!

              Ich rate nach wie vor zu ser2net ...

              Kommentar


                Servus,
                ich bin neu hier im Forum und dachte mir ich lasse Euch an meinen Findings teilhaben. Ich selbst benutze ein 15€ RS485 zu UDP converter (USR-TCP232-304) - das Ding ist ziemlich gut verarbeitet für den Preis und tut was es soll. Leider routet es allen RS traffic auf das Ethernet und erzeugt dort überflüssigen Traffic. D.h. filtern etc ist nicht möglich. Auch war ich mir nicht sicher ob er die RS Botschaften immer sauber trennt und in ein UDP Packet verpackt da fast immer zwei komplette Botschaften in einem Frame landen. Aber vielleicht wird dann erst auch das Stoppbit gesetzt. Eventuell könnt ihr mir weiterhelfen - bzw. weiter unten findet sich ein Hinweis auf das Verhalten Will aber an der Stelle noch nichts verraten.

                Ich habe einen Integra 2.0 BT Ekey Leser und habe mich auf Grund der Preisgestaltung dermaßen geärgert, dass ich eigentlich viel zu viel Zeit verbracht habe mir auch das Protokoll anzuschauen.

                Ich habe ein paar Updates.
                Beim Integra sind die Botschaften ein klein wenig anders (zumindest der Header).
                Erkannte Fingerabdrücke:
                Zuerst:
                02 XX 21 82 81
                Dann als Antwort
                02 XX 21 82 80

                Fingerhash etc habe ich noch nicht überprüft, aber ich vermute es ist gleich wie beim normalen Ekey.

                Das mit den nicht erkannten Fingerabrücken konnte ich nicht auf sich beruhen lassen, daher:

                Ein normales Frage- Antwort Spiel bei keiner Aktion am Leser:
                Code:
                10:20:55.109    [COLOR=#FF0000]02[/COLOR] 75 20 82 C0 C0 88 BC 81 E6 73 B4 84 CC 23 00 [B]EF[/B] 9B 00 22 5B BE DB F1 93 1F BB 1C 00 07 03 [COLOR=#FF0000]02[/COLOR] 71 [B]20 82 81 80 81[/B] B4 84 CC 23 BC 81 E6 73 48 [B]EF[/B] DB 5E A4 35 31 30 37 3D 35 34 3B 3A 03
                Die Antwort vom Leser ist 20 82 81 80 81 und das Zählbyte EF wird aus der Anfrage übernommen. (Dies ist ein UPD-Paket).

                Bei nicht erkanntem Finger schickt der Leser auch ein 20 82 81 80 81 aber ohne vorher die Anfrage erhalten zu haben. BZW wurde vorher ein Stoppbit gesetzt. Daher meine Vermutung, dass mein RS485<->UDP wandler doch richtig arbeitet.

                Code:
                10:20:52.774    02 7D 20 82 C0 C0 88 BC 81 E6 73 B4 84 CC 23 00 [B]E0[/B] 20 00 22 DF 95 DF 27 51 50 AB 9F 00 07 00 00 03    
                10:20:52.774    02 A1 [B]20 82 81 80 [/B]81 B4 84 CC 23 BC 81 E6 73 5E [B]E0[/B] D1 C0 1A EB EC ED EA EC E8 E9 E6 E7 E1 E5 E2 69 6D 64 AC A6 AF A1 A8 AB 03
                Das Zählbyte wird auch hier wiederholt. (Dies sind zwei UDP Pakete). Allerdings kommt die Botschaft in einem eigenen Frame.

                Nach 10 falschen Erkennungen scheint mein Leser einen Reset zu machen. Weiß jemand warum er das macht?

                Hoffe ich konnte Euch helfen
                Viele Grüße

                Kommentar


                  Hab aktuell grad nicht die zeit mich mit dem Thema wieder voll zu beschäftigen. Auf deine Frage warum der Leser einen Reset macht wird dir wohl nur der Hersteller eine Antwort geben können, aber sicher nicht wollen.

                  Wenn du zuverlässig einen falsch erkannten finger detektieren kannst wäre das super wenn man das auf das Ekey Integra Home Teil übertragen könnte. Würde das Signal gerne auf dem Bus haben ...

                  Kommentar


                    Hallo dawansch,

                    Zitat von dawansch Beitrag anzeigen

                    nach 10 falschen Erkennungen scheint mein Leser einen Reset zu machen. Weiß jemand warum er das macht?
                    der Fingerscanner rebootet immer nach 10 Nichterkennungen um eine Fehlfunktion durch ESD am Sensor auszuschließen.

                    Zitat von dawansch Beitrag anzeigen

                    Ein normales Frage- Antwort Spiel bei keiner Aktion am Leser:
                    Code:

                    10:20:55.109 02 75 20 82 C0 C0 88 BC 81 E6 73 B4 84 CC 23 00 EF 9B 00 22 5B BE DB F1 93 1F BB 1C 00 07 03 02 71 20 82 81 80 81 B4 84 CC 23 BC 81 E6 73 48 EF DB 5E A4 35 31 30 37 3D 35 34 3B 3A 03
                    Die Antwort vom Leser ist 20 82 81 80 81 und das Zählbyte EF wird aus der Anfrage übernommen. (Dies ist ein UPD-Paket).

                    Bei nicht erkanntem Finger schickt der Leser auch ein 20 82 81 80 81 aber ohne vorher die Anfrage erhalten zu haben. BZW wurde vorher ein Stoppbit gesetzt. Daher meine Vermutung, dass mein RS485<->UDP wandler doch richtig arbeitet.

                    Code:

                    10:20:52.774 02 7D 20 82 C0 C0 88 BC 81 E6 73 B4 84 CC 23 00 E0 20 00 22 DF 95 DF 27 51 50 AB 9F 00 07 00 00 03 10:20:52.774 02 A1 20 82 81 80 81 B4 84 CC 23 BC 81 E6 73 5E E0 D1 C0 1A EB EC ED EA EC E8 E9 E6 E7 E1 E5 E2 69 6D 64 AC A6 AF A1 A8 AB 03
                    Das Zählbyte wird auch hier wiederholt. (Dies sind zwei UDP Pakete). Allerdings kommt die Botschaft in einem eigenen Frame.

                    Deine Analyse stimmt so nicht. Bei einem Protokoll müssen gewisse Daten (Adresse,..) fix sein. Die Nutzdaten sind verschlüsselt wobei dieser Schlüssel wechselt. Bei einer Verschlüsselung kann es vorkommen, dass Zahlen gleich sind.

                    Da es sich bei diesem Protokoll um ein internes Protokoll handelt, kann sich dieses mit jedem Release ändern.

                    Ich würde hier zum ekey home CV LAN raten!



                    lg, georg


                    Zuletzt geändert von georgleutgeb; 22.06.2017, 13:06.

                    Kommentar


                      Hallo zusammen,
                      schön dass es weitergeht und spannend bleibt :-)
                      Natürlich kann eKey das Protokoll bei jedem Release ändern, aber es wird hoffentlich kein "Zwangs-Roll-Out" auf bestehende Anlagen geben ;-)
                      Also was gleich geblieben ist, ist schon mal das Start-Ende-Handling, und die 4-Byte-Sender/Empfänger-Adressen stehen auch noch da (im obigen Trace
                      BC 81 E6 73 B4 84 CC 23 bzw andersrum B4 84 CC 23 BC 81 E6 73 Und dass nun ein Zählbyte im Klartext mitläuft, welches an einer festen Position nach dem Addressfeld steht und in Frage und Antwort gleich ist, kann ich glauben. Ob die "Verschlüsselung" besser oder schlechter ist als im alten Protokoll, kann man glaub ich momentan nicht beurteilen, aber spannend ist es allemal. Nochwas zu dem oben genannten RS485-zu-UDP-Konverter: Da er offenbar ein Universal-Teil ist, kennt er ja das Protokoll nicht, was auf der 485 läuft. Daher kann er auch nicht inhaltlich korrekt geschnürte UDP-Pakete versenden. Er puffert einfach den eingehenden Datenstrom, und wenn dieser eine Lücke enthält, oder der Puffer aufgebraucht ist, sendet er die Daten auf Ethernet. Dass in unserem Fall komplette ekey-Frames mit 02 ... 03 in komplette UDP-Pakete transferiert werden, ist eher Glückssache. Es sagt auch nix aus, wenn zwei ekey-Frames in einem UDP-Paket landen. Das heisst nur, dass sie keine wesentliche Lücke aufwiesen. Ein "Stopbit" im obigen Sinne, dass es das Ende eines Frames anzeigt, gibt es nicht. Jedes Byte hat ein Stopbit, aber dieses zeigt einfach nur das Ende des Bytes an.

                      Kommentar


                        Zum "Reset nach n erfolglosen Scans": Hab ich bei mir auch beobachtet, wobei ich nicht sicher bin, nach wieviel Versuchen das passiert. Ich halte das für eine "Aufräum-Maßnahme", für den Fall, dass Scanner und Zentrale sich nicht mehr verstehen, dann wird die Kommunikation neu aufgesetzt. Vielleicht auch als Sicherheitsmaßnahme, so dass ein emuliertes Bedienteil zwar ein paar mal versuchen kann, der Zentrale eine Öffnung unterzujubeln, aber nach ein paar Versuchen die Zentrale zurückfragt. "Hallo Bedienteil, jetzt will ich wissen wer du bist, unterschreib mir mal und wir fangen ganz von vorne an."

                        Kommentar


                          Ich überlege gerade meinen Gelikom Fingerprint Reader durch einen eKey zu ersetzten. Den Gelikom nutzte ich über einen ESP8266 und dem Wiegand Protokoll.

                          Mich würden nun die Langzeiterfahrung mit dem eKey Integra interessieren? Wie zuverlässig funktioniert die Erkennung über den CH-340 Chip und dem Java ekeydecoder am Raspberry?

                          Kommentar


                            Hab zwar nicht den Integra, aber ich hab mir jedenfalls den udp Converter gekauft.
                            Der Java Encoder war leider viel zu unzuverlässig

                            Kommentar


                              Mein "Decoder" in Java läuft bei mir zuverlässig. Das einzige was er nicht gebacken kriegt (weil das Schema noch unbekannt ist), ist das erkennen einer Fehlerkennung. Und das stört mich irgendwie noch am meisten. Weiß auch nicht warum.
                              Praktisch eingebunden in die Hausautomation habe ich den Decoder allerdings noch nicht.

                              "CH-340 Chip"?? Ich hab nen günstigen USB-RS485 Adapter aus der Bucht für 1,20EUR. Das Teil funktioniert ebenfalls zuverlässig. Sowohl am Ekey, als auch an der Lüftungsanlage (die macht auch RS485).

                              Auf der langen ToDo Liste steht nach wie vor das entwickeln eines RS485 Adapters für KONNEKTING und das portieren der Java-Implementierung auf den Arduino. Dann wäre die Sache komplett in KNX realisiert.

                              Kommentar


                                RS485 kann ja auch der ESP. Die Portierung des Codes wäre ja auch einfach. Welcher eKey Reader funktioniert den am besten?

                                Kommentar

                                Lädt...
                                X