Ankündigung

**callidomus** · 10.06.2013, 15:56

Hallo Niko,

erst einmal Sorry für die Erklärungsnot in die Dich SH.py gebracht hat.

Das Problem liegt in den 'exit()' aufrufen. Die haben dazu geführt das die Threads sterben. Das hat dann zu dem zyklischen hinzufügen von Threads geführt. Das sterben der Threads (Unknown finger) ging aber schneller als das hinzufügen.

Der Code in github fängt diesen Umstand jetzt ab.

Bis bald

Marcus

**2ndsky** · 10.06.2013, 16:02

Hallo Marcus,

kein Problem, sowas kommt vor. Aber Danke für die Erläuterung und das Fixen, werde ich heute Abend gleich testen. Das erklärt auch, warum das bei mir nie aufgetreten ist sondern hauptsächlich bei meiner Freundin. Sie hat noch etwas Probleme damit, den Finger auf die korrekte Art und Weise über den Leser zu ziehen. Daher kommt es öfters mal vor, dass der Finger abgewiesen wird und damit scheitern dann auch die korrekt erkannten Versuche danach in eben diesem Verhalten.

Ist das denn der richtige Weg mit dem "exit()" oder macht man das normalerweise anders? Habe das glaub aus einer Logik aus dem Wiki übernommen.

**callidomus** · 10.06.2013, 16:16

Hallo Niko,

exit() und sys.exit() werden jetzt abgefangen und können daher in den Logiken verwendet werden.
Die Methoden an sich sind ok. Manche Programmierer, ich gehöre nicht dazu, finden multiple returns (in diesem Fall exit) blöd. Ich finde es macht den Code übersichtlicher.

Bis bald

Marcus

**2ndsky** · 10.06.2013, 16:23

Hallo Marcus,

Zitat von mknx Beitrag anzeigen

Die Methoden an sich sind ok. Manche Programmierer, ich gehöre nicht dazu, finden multiple returns (in diesem Fall exit) blöd. Ich finde es macht den Code übersichtlicher.

Dann sind wir da ja einer Meinung

Ich dachte nur evtl. sollte man mit return oder ähnlichem aussteigen anstelle von exit.

**Sandman60** · 19.08.2014, 22:23

Hinweis zum Ekey-Fingerprint-UDP

Hallo Marcus, Niko,

sorry für das Ausgraben dieses alten Threads, aber evtl. ja für die Mitleser interessant.

Ich hatte lange das Problem bei mir, dass der von Niko gepostete Code bzgl. Ekey-Fingerprint bei mir Null,Null was bewegt hat. Das Log blieb einfach leer.

Nach dem Update auf die Dev-Versionen des NW-Plugins und einiger anderer habe ich dann plötzlich Fehlermeldungen entdeckt das es wohl ein UTF-8 Problem innerhalb des UDP's gibt und daher die Logik nie angetriggert worden ist.
Nach einer leichten temporären Modifikation des NW-plugins (ersetze decode() durch decode("utf-8", "ignore")) kam dann die Wahrheit ans Licht, nämlich das bei mir warum auch immer der EKEY-UDP-Converter mit dem standardmäßig durch EKEY gesetzten Delimiter = _ wohl Probleme beim decode hat. Daraufhin habe ich diesen in der EKEY-UDP-SW auf Delimiter = ; gesetzt und schon klappt es wunderbar mit dem NW-Plugin und der Logik von Niko.

Daher auch an dieser Stelle meinen besonderen Dank an Euch beide! Bin nun wieder ein paar % weiter in der Migration von meinem <sagichnicht> auf smarthome.py!

@Marcus: Macht es evtl. Sinn den decode("utf-8", "ignore") dauerhaft im NW-Plugin einzubauen? Würde dann eben keine Exception mehr werfen sondern dann eben weiter durchlaufen. Brauche es nun nicht mehr, macht es aber evtl. für die Nächsten einfacher.

Cheers,
Oliver

**callidomus** · 23.08.2014, 20:05

Hallo Oliver,

Zitat von Sandman60 Beitrag anzeigen

@Marcus: Macht es evtl. Sinn den decode("utf-8", "ignore") dauerhaft im NW-Plugin einzubauen? Würde dann eben keine Exception mehr werfen sondern dann eben weiter durchlaufen. Brauche es nun nicht mehr, macht es aber evtl. für die Nächsten einfacher.

ich denke, es schadet nicht. Ich habe es in develop eingebaut.

Bis bald

Marcus

**binderth** · 05.01.2016, 22:51

Ich kram den alten Thread mal wieder hoch.

Auch ich hab von eKey den Fingerprint-Reader mitsamt multi REG und eben dem "CV LAN". Der schickt inzwischen fleissig UDP-Telegramme und ich krieg die aber nicht in die Logik...
ich hab das network-Plugin aus dem develop.

Ich hab mal das von Niko verwendete Grundgerüst als Ausgangslage verwendet:

plugin.conf

Code:

[nw]
    class_name = Network
    class_path = plugins.network
    # ip = 0.0.0.0
    # tcp = yes
    # tcp_acl= 127.0.0.1 | 192.168.0.34
    port = 56000
    udp = yes
    udp_acl= *

Frage hierzu gleich: ohne den Eintrag "port" passiert lt. Log erstmal gar nichts, soll das so? Aktuell kein Problem, aber wenn ich mal einen anderen UseCase habe, wo UDP/TCP Nachrichten versendet werden sollen, wäre das auf einem anderen Port sauberer?

items.conf

Code:

[I]leer[/I]

Da brauche ich erstmal nichts, weil ich kein item brauche, sondern nur logic.

logic.conf

Code:

[fingerprint]
    filename = 'fingerprint.py'
    # nw = yes
    nw_udp_listen = 0.0.0.0:56000  # port number

da bin ich mir nicht ganz sicher, obs das "nw=yes" braucht?

fingerprint.py

Code:

[I]ist soweit fast identisch wie Nikos oben - ist ja der gleiche String, der gesendet wird.[/I]

Ich erhalte aber gleich direkt im Log einen entsprechenden Eintrag:

smarthome.log

Code:

2016-01-05 22:24:23 INFO     Main         Ignoring input 1#0001#TOM#1#7#1#80207xxx#TUER#1#-. Format not recognized.

Wie krieg ich den ungefiltert in die logic rein? Einfluss auf das UDP-Paket hab ich natürlich keines?
Danke für einen Anstupser!

Thomas.

**Sandman60** · 05.01.2016, 23:12

Hi Thomas,

rein "out of the brain"... Bei mir hat das ewig nicht funktioniert da mein EKEY ein anderes Trennzeichne verwendet hat und dadurch hat die Payload nicht gepasst bzw. war nicht valide. Erst als ich im Ekey-Tool das verändert habe lief es. Schau Dir mal den Artikel hier an, evtl. ist das ja auch Dein Problem.

Bei mir sieht die plugin.conf so aus (für x.y steht natürlich eine valide IP):

Code:

[nw]
    class_name = Network
    class_path = plugins.network
    udp_acl= 127.0.0.1 | 192.168.x.y
    port = *
    udp = yes

logic.conf (für xxxx steht natürlich ein valider Port), nw=yes muß sein:

Code:

[Logic_Ekey]
    filename = ekey.py
    nw_udp_listen = xxxx  # port number
    nw = yes

Hoffe die Infos helfen Dir weiter.
Cheers,
Oliver

**binderth** · 05.01.2016, 23:43

Zitat von Sandman60 Beitrag anzeigen

Hi Thomas,

rein "out of the brain"... Bei mir hat das ewig nicht funktioniert da mein EKEY ein anderes Trennzeichne verwendet hat und dadurch hat die Payload nicht gepasst bzw. war nicht valide. Erst als ich im Ekey-Tool das verändert habe lief es. Schau Dir mal den Artikel hier an, evtl. ist das ja auch Dein Problem.

Bei mir sieht die plugin.conf so aus (für x.y steht natürlich eine valide IP):

Code:

[nw]
class_name = Network
class_path = plugins.network
udp_acl= 127.0.0.1 | 192.168.x.y
port = *
udp = yes

logic.conf (für xxxx steht natürlich ein valider Port), nw=yes muß sein:

Code:

[Logic_Ekey]
filename = ekey.py
nw_udp_listen = xxxx # port number
nw = yes

Hoffe die Infos helfen Dir weiter.
Cheers,
Oliver

Danke für die Hilfe,

aber wenn ich "port = *" in der plugin.conf eingebe, passiert gar nix (=kein Eintrag im Log), erst wenn da wieder der Port ohne Wildcard steht, gehts weiter. Aber auch mit aktiviertem "nw=yes" in der logic.conf (hatte ich vorher natürlich auch probriert) erhalte ich nach wie vor den genannten Fehler.

In der CV LAN-Konfigurations-Software kann ich den Delimiter zwar ändern, aber das hat zwei Probleme

den Durchschuss "|" kann ich dort gar nicht eingeben, den nimmt das Programm eh nicht an.
den notwendigen Aufbau mit "item" oder "logic" als ersten Parameter krieg ich dadurch auch nicht hin.
(ich hab mal versucht einfach den Payload von eKey manuell zu übertragen, aber ich müsste "logic|fingerprint|1#0001#TOM#1#7#1#80207xxx#TUER#1#-" versenden, und das rote verschickt der eKey ja nicht! Damit kann ich dann die Logik antriggern und den Payload weiterverarbeiten...

Wie hast Du oder Niko es denn dann geschafft, den eKey-Payload "AS IS" in die Logik zu kriegen? Da muss noch ein anderer Trick dahinter stehen, befürchte ich.

Gruß,
Thomas.

**Sandman60** · 06.01.2016, 00:08

Hi Thomas, wie gesagt ich habe den Delimiter auf ; (Strichpunkt) geändert, sowohl in der Logik als auch im EKEY. Danach lief es einwandfrei. Vor die Payload muß auch nichts gestellt werden. Bei mir sieht die payload allerdings auch wesentlich einfacher aus, k.A. ob die bei deinem Ekey anders ist, aber bei mir sind da bspw. nur Zahlen drinnen, kein ASCII usw. Hast Du es schon mal mit dem Delimiter ; versucht?

**Sandman60** · 06.01.2016, 00:11

BTW: Bist Du auf der Develop und hast die Änderung von oben (decode("utf-8", "ignore")) auch drinnen? Hatte bei mir zumindest mehr in das Log gebracht.

**binderth** · 06.01.2016, 00:48

Zitat von Sandman60 Beitrag anzeigen

Hi Thomas, wie gesagt ich habe den Delimiter auf ; (Strichpunkt) geändert, sowohl in der Logik als auch im EKEY. Danach lief es einwandfrei. Vor die Payload muß auch nichts gestellt werden. Bei mir sieht die payload allerdings auch wesentlich einfacher aus, k.A. ob die bei deinem Ekey anders ist, aber bei mir sind da bspw. nur Zahlen drinnen, kein ASCII usw. Hast Du es schon mal mit dem Delimiter ; versucht?

Der Delimiter ";" hilft mir auch nicht weiter. Aktuell bricht das Plugin ab, weil es eben keine Zuordnung zu "logic", "item" oder "log" findet. Meiner Meinung nach hier

plugins.network-Klasse Z. 176ff

Code:

    def parse_input(self, source, dest, data):
        if dest in self.generic_listeners:
[B][COLOR=#FF0000]            inp = data.split(self.input_seperator, 2)  # max 3 elements[/COLOR][/B]
            if len(inp) < 3:
                logger.info("Ignoring input {}. Format not recognized.".format(data))
                return False

Da passt auch kein "1;0001;TOM;1;7;1;80207xxx;TUER;1;-" durch, weil die Klass ja drei Paramenter per "|" getrennt erwartet, und ohne der Payload unerwartet ist.

Wenn ich hier weitersehe (ab Zeile 186ff), können auch die anderen Infos nicht weitergegeben werden, sofern kein "logic", "item" oder "log" als erster Parameter für die generischen Listener übertragen werden:

Code:

[COLOR=#FF0000][B]            if typ == 'item':[/B][/COLOR]
                (...)

[COLOR=#FF0000][B]            elif typ == 'logic':[/B][/COLOR]
                (...)

[COLOR=#FF0000][B]            elif typ == 'log':[/B][/COLOR]
                (...)

            else:
               [B] logger.error("Unsupporter key element {}. Data: {}".format(typ, data))[/B]
                return False

Entweder muss der Payload irgendwie bevor er ins Plugin rauscht bearbeitet werden und die beiden Parameter "logic|fingerprint" vorangestellt werden (der eKey liefert ja keine "logic|fingerprint|" als Präfix). Weil ja wie gesagt, per "logic|fingerprint|eKey-payload" läuft alles wie es soll.
...oder ich hab irgendwas anderes übersehen...

PS: ja, ich bin auf develop, ich finde zwar kein "decode("utf-8", "ignore")", aber dafür ein paar "data.decode(errors="ignore")"...? Die im master nicht zu finden sind. Meinst Du das?

Danke für Die Hilfe!
Thomas.

**mumpf** · 06.01.2016, 02:28

Hi Thomas,

ich habe es noch nie direkt übers Antriggern von Logik probiert, aber mein Vorgehen könnte ein Workaround für Dich sein. Ich habe ein Item vom typ str, das auf die UDP-Pakete hört und die Logik wird dann vom Item getriggert.

item:

Code:

[Main]
    [[Ekey]]
        name = eKey string
        type = str
        nw_udp_listen = <ip>:<port>
        enforce_updates = True

logic.conf:

Code:

[ekey]
    filename = eKey.py
    watch_item = Main.Ekey

Vielleicht klappt es so...

Gruß, Waldemar

**Sandman60** · 06.01.2016, 08:59

Hmmm, ich steh irgendwie auf dem Schlauch... Also, bei mir wird das Plugin durch die LOGIK getriggert, welche in der logic.conf steht (s.o.). Dort "hört" die Logik auf das nw-plugin.

Code:

[Logic_Ekey]
    filename = ekey.py
    nw_udp_listen = xxxx  # port number
    nw = yes

Items hab ich keine konfiguriert, sind m.E. auch nicht notwendig. Hatte ich mal zum testen, waren aber weder notwendig noch hilfreich. Klar habe ich welche konfiguriert, allerdings für spätere Auswertungen wie User usw., diese werden aber im Logikfile ekey.py verwendet, Code analog zu Niko.

Was mich immernoch irritiert ist Deine Payload. Bei mir sieht die bspw. so aus (habe die Seriennummer mit 99999999999999 unkenntlich gemacht), wenn bspw. User 1 mit Finger 9 sich erfolgreich angemeldet hat. Ich habe aber, ebenso wie Niko, den UDP-Converter:

Code:

1;0001;1;99999999999999;1;1

Beim Tracen oder manuellen auslösen wird sonst auch nichts übergeben.

Bzgl. decode: Ja, das müßte es gewesen sein, lässt sich leider aktuell bei mir nicht mehr nachvollziehen. Hast Du mal SH.PY im Debug-Mode gestartet und geschaut was dann beim Dispatching gemeldet wird? Da sollte ja ein "{}: incoming connection from {} to {}" kommen, dann siehst Du die Payload. Bei mir kam da damals eben gar nix wenn der Delimiter nicht auf ; gestanden war.

Ankündigung

zeitlich verzögerte Ausführung einer Logik getriggert via UDP Telegramm

zeitlich verzögerte Ausführung einer Logik getriggert via UDP Telegramm

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar