eKey Fingerscanner per RS485 auslesen: Protokollanalyse

[tuxedo]

Hi,

nein, deine Kiste ist dafür nicht zu schwach. Sieht anhand des Fehlerlogs nach einem Problem mit der Bibliothek für die serielle Schnittstelle (via USB) aus.

Ich empfehle dir, da du ja eh unter LInux arbeitest, statt dem seriellen Parameter den Socket-Parameter zu benutzen. Dazu musst du ser2net installieren und konfigurieren.

Hier mal eine Config für ser2net. Einfach am Ende der Config-File anhängen:

/etc/ser2net.conf

# eKey
4001:raw:0:/dev/ttyUSB1:115200 8DATABITS NONE 1STOPBIT

natürlich ttyUSBx an deinen Fall anpassen. Da ich aktuell schon 3 solcher USB-Devices dran hängen habe (Ekey, Heizung, Lüftung) ist es bei mir nicht nur bei ttyUSB0 geblieben.

Danach ser2net neu starten:

/etc/init.d/ser2net restart

Und dann das Java-Tool mit dem Socketparameter und localhost:4001 aufrufen.

Die Bibliothek für die serielle Schnittstelle scheint auf dem Raspi wohl nicht besonders stabil zu sein. Aber mit ser2net geht's bestens.

Gruß
Alex

P.S. kommende Woche gibt's ne aktualisierte Version des Programms. Dann sind die Logausgaben etwas geschickter.

[Onkelandy]

Oja.. Vom Grundkonzept her klappt schon super! An einem Raspi, wo jetzt das ser2net installiert ist, hängt der Adapter, der andere Raspi fängt diese ab und schickt sie bei Bedarf an KNX. Dort kommen aber nur sporadische komische Sachen hin..

Also genau genommen bekomme ich immer nur entweder wrong tail oder den kompletten Frame angezeigt. Aber nie, dass irgendwie ein Finger erkannt wurde oder sonst was. Auch nicht beim Einlernen eines neuen Fingers am ekey oder so.. Ich denke, ich warte jetzt einfach noch ein bisschen Danke jedenfalls schon mal für die Hilfe!!!

[tuxedo]

Schau mal dass du dir einen 120Ohm Widerstand besorgst (z.B. http://www.ebay.de/itm/371315151733?...%3AMEBIDX%3AIT im 50er Pack). Den schraubst du dann am Adapter zwischen die beiden Datenleitungen.

Wenn du diese Diskussion hier verfolgst, dann siehst du, dass ich (seltsamerweise erst nach einiger Zeit) selbes Problem hatte. Mit dem Abschlusswiderstand hat dann alles gepasst.
Da dein RS485-USB-Adapter wie meiner aussieht, gehe ich mal nicht davon aus dass das eine Variation ohne Bias-Widerstände ist und du auch hier noch "nachbessern" musst. Wenn du auf Nummer sicher gehen willst: Mess mal mit einem Multimeter die Spannung zwischen den beiden Datenleitungen (ohne angeschlossene Leitungen und Abschlusswiderstand). Meine liegt bei 4,6..4,77V (je nach Adapter, hab mehrere).

Mit dem Widerstand sollten die "Wron tail" Meldungen weniger werden oder sogar komplett verschwinden und die Finger werden erkannt.

[UweH]

... einen 120Ohm Widerstand ... zwischen die beiden Datenleitungen. ...
Mit dem Widerstand sollten die "Wron tail" Meldungen weniger werden oder sogar komplett verschwinden

Eine RS485 ist für stabile Kommunikation unter schwierigen Bedingungen konzipiert. Das funktioniert auch, wenn sie richtig ausgelegt ist. Bei "wrong tail Meldungen weniger werden" runzelt sich meine Stirn: Da stimmt die Auslegung nicht. Hab noch 'was gefunden, was den Zusammenhang zwischen dem Abschluss, dem undefinierten Bereich, ungültigen Daten und dem Bias gut erklärt.
http://www.ni.com/support/serial/resinfo.htm
Mein Vorschlag wäre die Reduzierung der Bias-Rs von 2k2 auf 680 im Dongle oder eine zusätzliche externe Beschaltung mit 2 x 1k.

[tuxedo]

Natürlich ist das einfache einsetzten eines 120 Ohm Widerstandes hier nicht "100% ideal". Aber es funktioniert erstmal (mit diesem Dongle).
Der Dongle ist wirklich sehr klein aufgebaut und nicht jeder kann SMD Widerstände in der Größe 0603 auslöten und ersetzen, oder weitere Widerstände auf den vorhandenen Pads noch ergänzen. Auch lässt das Gehäuse prinzipiell keine anderen Widerstände als SMD zu (sonst geht's nicht mehr zu).

Mir wäre es auch lieber wenn ich keine Fehl-Bytes mehr hätte. Aber bis auf weiteres reicht der 120Ohm Abschlusswiderstand. Wenn ich mal wieder Zeit habe, dann probiere ich meinen Ersatz-Dongle entsprechend zu modifizieren oder ich suche einen Adapter der größer aufgebaut ist und modifiziere dann ggf. diesen..

[Onkelandy]

Hallo zusammen!
Ein paar wrong tail Meldungen kommen auch mit dem 120 Ohm Widerstand, den ich einfach in beide Schrauben geklemmt habe.. soweit gehe ich aber mal davon aus, dass dies kein großes Drama ist Die Erkennung der Finger funktioniert nach ersten Tests schon mal super. Auch die Übertragung vom einen Raspi auf den anderen, wo dann eibd und smarthome.py läuft, funktioniert perfekt. Und schließlich kommen auch die Signale am KNX an - also Leute, das ist ziemlicher Hammer!! DANKE.

Eine kleine Frage hätte ich aber noch. Ich würde gerne das JAR file über ein Service einbinden, das ich dann einfach mit start/stop managen kann. Habe dazu auch schon ein entsprechendes einfaches Script gefunden, das das Ganze mit "nohup java -jar blabla" aufruft, laut zB hier: http://stackoverflow.com/questions/1...ground-process

Ein Problemchen ergibt sich dabei: die properties-Dateien müssen wohl in dem Verzeichnis liegen, von wo aus das Script aufgerufen wird. Ist natürlich leicht zu beheben, aber optimaler wäre, optional ein Verzeichnis angeben zu können, wo die Dateien liegen. Beim Java Aufruf selbst scheint das nicht möglich zu sein?

Exception in thread "main" java.io.FileNotFoundException: finger.properties (No such file or directory)

Jedenfalls nochmals großes Dankeschön!!! Und wenn's das angekündigte neue JAR File schon gibt, gerne her damit

[tuxedo]

Ein paar wrong-tail kommen bei mir auch noch. Aber die Fingererkennung ist schon sehr zuverlässig. Führe allerdings noch keine Statistik ob tatsächlich mal ein Fingerhash nicht erkannt wird obwohl ein Finger erfolgreich gescanned wurde.

Ein Start-Script ist in Arbeit, und die Pfad-Angabe zur Properties-File kommt ebenfalls. Vllt. noch diese Woche.

Gruß
Alex

[Onkelandy]

Soweit funktioniert das Script schon ganz prima.. Im /etc/init.d Verzeichnis dann auch als Autostart..

#!/bin/sh
SERVICE_NAME=eKeyDecoder
PATH_TO_JAR=/usr/smarthome/ekey/ekey.jar
LOGFILE=-Djava.util.logging.config.file=/usr/smarthome/ekey/log.properties
PID_PATH_NAME=/tmp/ekeyDecoder-pid

case $1 in
    start)
        echo "Starting $SERVICE_NAME ..."
        if [ ! -f $PID_PATH_NAME ]; then
            cd /usr/smarthome/ekey
            nohup java $LOGFILE -classpath /usr/smarthome/ekey -jar $PATH_TO_JAR -socket 10.0.0.152:4001 >>/var/log/javawrapper.log 2>&1 &
                        echo $! > $PID_PATH_NAME
            echo "$SERVICE_NAME started ..."
        else
            echo "$SERVICE_NAME is already running ..."
        fi
    ;;
    stop)
        if [ -f $PID_PATH_NAME ]; then
            PID=$(cat $PID_PATH_NAME);
            echo "$SERVICE_NAME stoping ..."
            kill $PID;
            echo "$SERVICE_NAME stopped ..."
            rm $PID_PATH_NAME
        else
            echo "$SERVICE_NAME is not running ..."
        fi
    ;;
    restart)
        if [ -f $PID_PATH_NAME ]; then
            PID=$(cat $PID_PATH_NAME);
            echo "$SERVICE_NAME stopping ...";
            kill $PID;
            echo "$SERVICE_NAME stopped ...";
            rm $PID_PATH_NAME
            echo "$SERVICE_NAME starting ..."
            cd /usr/smarthome/ekey
            nohup java $LOGFILE -classpath /usr/smarthome/ekey -jar $PATH_TO_JAR -socket 10.0.0.152:4001 >>/var/log/javawrapper.log 2>&1 &
                        echo $! > $PID_PATH_NAME
            echo "$SERVICE_NAME started ..."
        else
            echo "$SERVICE_NAME is not running ..."
        fi
    ;;
esac

Muss mir jetzt noch überlegen, ob ich mein zweites Relais, das derzeit die Garage öffnet, für eine entsprechende Logik und somit Zutrittverwaltung (Person XYZ darf nur dann und dann rein) opfere..

[tuxedo]

Soweit funktioniert das Script schon ganz prima.. Im /etc/init.d Verzeichnis dann auch als Autostart..

....

Muss mir jetzt noch überlegen, ob ich mein zweites Relais, das derzeit die Garage öffnet, für eine entsprechende Logik und somit Zutrittverwaltung (Person XYZ darf nur dann und dann rein) opfere..

Script hab ich schon fertig, muss nur noch parametrisiert und commited werden.
Das Garagentor wird bei mir später am KNX-Bus hängen und sich darüber öffnen/schließen/ansteuern lassen (das gibt wohl eine weitere Anwendung ). Von daher habe ich das zweite Relais noch frei und wird genau für die Anwendung (Garagentor, Zeitgesteuerte Zutrittsverwaltung, ...) genutzt, bzw. "frei gelassen".

[tuxedo]

So, habs doch gleich umgesetzt:

http://jenkins.root1.de/job/ekey%20D...$ekey-decoder/

Dort findet man immer den aktuellsten Build. In den zip/tar.gz/tar.bz2 Archiven ist alles enthalten:

Die JAR, die Config-Files sowie das Start-Script.

Das Start-Script geht von einem Pfad /opt/ekeydecoder aus wo die JAR sowie die Configs liegen sollten.

MIttels rcconfig (apt-get install rcconfig) kann man das Start-Script bequem für den Systemstart einschalten.

Ggf. sollte man dran denken eine config für die Logfile-Rotation für /var/log/ekeydecoder.log anzulegen....

[tuxedo]

Werde da heute nochmal nachlegen müssen. Mit dem KNX Teil stimmt noch was nicht. Da kommt es zu einer java.lang.ClassNotFoundException ...

[tuxedo]

Neue Version online... Kann nun automatisch einen reconnect ausführen falls die Verbindung mal abreisst (Netzwerkprobleme, Adapter kurz abgesteckt, ...)

---> http://jenkins.root1.de/job/ekey%20D...$ekey-decoder/

[Onkelandy]

Soweit funktioniert die aktuelle Version absolut sauber und problemlos - vielen Dank!
Wie oft oder lange versucht eigentlich das Tool, die Verbindung wiederherzustellen? Bei mir schalte ich nämlich den Raspi, der am ekey hängt über Nacht ab. Problem lässt sich einfach durch einen Restart des Java Tools am Morgen lösen.. wollte aber trotzdem mal nachfragen

[tuxedo]

Wenn der Datenstrom abreisst, wird 5sek gewartet und dann erneut versucht die Verbindung aufzubauen. Und das geschieht in einer Endlosschleife. Eigentlich muss nichts neu gestartet werden.

Wieso schaltest du den Pi über Nacht ab? Stromsparen? Bis sich die Zeitschaltuhr oder sogar der Aktor-Kanal für diese Aktion bezahlt macht dauert's aber schon ein paar Jahre. Wenn nicht sogar Jahrzehnte.

[Onkelandy]

Hmmm.. okay, irgendwie hat's bei mir aber immer in der ersten Nacht des Abschaltens die Verbindung gekappt, sodass auch nichts mehr ins Logfile geschrieben wurde. Gelaufen ist das Java Tool schon noch, aber eben nach wie vor ohne Verbindung. Aber wie gesagt, im Prinzip egal

Ja, Danke für den Hinweis, hehe. Ich hab an der Steckdose nicht nur den Pi, sondern auch noch den Router, etc. dran hängen. Aber im Prinzip überleg ich mir das eh nochmals, ob ich den Pi nicht wieder weg nehme von der geschaltenen Dose, hehe.