Ankündigung

**binderth** · 06.01.2016, 12:29

Zitat von Sandman60 Beitrag anzeigen

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.

Hallo Oliver,

Länge Payload
Den Payload kann ich Dir schnell erklären. Du verwendest beim Datenpaket die "home"-Variante. Ich habe einen Multi-REG (ArtNr 101163 multi SE REG 4) von eKey, da ich später mal mehrere Fingerprint-Sensoren anschliessen möchte, bzw. vier Ausgang-Relais haben wollte. Der braucht zwingend die "multi"-Variante, die im Gegensatz zur home-Variante noch weitere Informationen überträgt (u.a. noch Benutzername, Benutzerstatus, Schlüssel-IDs, ...). Daher ist der Payload dann auch entsprechend länger.

Triggern Logik
Da habe ich noch immer einen Knoten im Hirn. Egal, ob der Payload länger oder kürzer ist, er kommt doch am Plugin gar nicht vorbei, so wie ich es konfiguriert habe (und ich denke, das ist dieselbe Konfig wie bei Dir?).
Wenn ich mir das Plugin so genau ansehe (bin kein Entwickler, daher kann ich durchaus was übersehen), passiert doch folgendes:

UDP-Paket wird vom eKey CV LAN auf einem bestimmten Port gesendet
etwa so: $ echo "1;0001;TOM;1;7;1;80207xxx;TUER;1;-" | nc -uw 1 XX.XX.XX.XX 56000`

Das Plugin ist entsprechend konfiguriert und schleust das alles erstmal an die Klasse durch und interpretiert u.a. den Payload

Code:

[nw]
	    class_name = Network
	    class_path = plugins.network
	    udp_acl= *
	    port = 56000
	    udp = yes

der UDPdispatcher erkennt die Verbindung

Code:

2016-01-06 12:01:07,953 DEBUG    Main         UDPDispatcher: incoming connection from xx.xx.xx.xx:56000 to 0.0.0.0:56000-- __init__.py:handle_connection:109

der Payload wird geparst und erwartet dabei aber drei Parameter wie dokumentiert "key|id|value"

da der eKey nur "value" liefert und kein "key" und auch kein "id" mitliefert, interpretiert das Plugin das Paket als "unbekannt" und verwirft alles

Code:

2016-01-06 12:01:07,959 INFO     Main         Ignoring input 1;0001;TOM      ;1;8;1;80207xxxx;TUER;1;-. Format not recognized. -- __init__.py:parse_input:184[FONT=arial][/FONT]

damit ist erstmal Schluss und der UDP-Aufruf erreicht gar nicht erst die Logik-Ebene

Du musst also irgendwie einen Weg gefunden haben, den Payload direkt ohne Prüfung auf "key|id|value" an die Logik zu schicken!

Gruß,
Thomas.

**binderth** · 06.01.2016, 12:32

Zitat von mumpf Beitrag anzeigen

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

Das hatte ich auch schonmal versucht - aber auch hier dasselbe Spiel wie bei der Logik, der Payload kommt gar nicht erst am Plugin-Parser vorbei?

Code:

2016-01-06 12:31:12,763 INFO     Main         Ignoring input 1;0001;TOM      ;1;8;1;80207xxxx;TUER;1;-. Format not recognized. -- __init__.py:parse_input:184

irgendwas ist bei Euch zwei anders konfiguriert...
Und ja - ich hab auch mal Euren "home"-Payload mit ";" und mit "#" und mit "_" als Delimiter versucht!

Code:

2016-01-06 12:33:50,978 INFO     Main         Ignoring input 1;0001;1;99999999999999;1;1. Format not recognized. -- __init__.py:parse_input:184

Gruß,
Thomas.

**mumpf** · 06.01.2016, 16:06

Hi,

ich verstehe nicht, warum Du immer den generischen Listener ins Spiel bringst, den willst Du doch gar nicht haben. Irgendwo reden wir aneinander vorbei...

Hast Du vielleicht die Ports verwechselt? Schickst Du die Daten immer an die 2727? Der Port braucht natürlich die payload wie oben beschrieben.

Ich habe jetzt mal nachgeschaut, Du schreibst gleich in Deinem ersten Post, das Du in der plugin.conf port = 56000 genommen hast, und das auch der Port ist, den Du bei nw_udp_listen nutzt. Das ist natülich quatsch! Der Port in der plugin.conf ist der, auf den der generische Listener des nw-Plugin hört (default 2727, am besten erstmal so lassen und gar keine port angabe machen, auch nicht port = *). Damit kannst Du dann per udp generische Kommandos an sh.py schicken, die müssen dem Format der payload entsprechen.

Deine Logik soll aber auf das hören, was über 56000 kommt! Deswegen gibst Du in der logic.conf ein nw_udp_listen = 56000 an und nur da!

Es sind einfach 2 verschiedene Sachen, und durch den gleichen Port hast Du sie zusammen gebracht, wobei dann wohl immer der generische Listener gewonnen hat.

Gruß, Waldemar

**binderth** · 06.01.2016, 18:17

Zitat von mumpf Beitrag anzeigen

Hi,

ich verstehe nicht, warum Du immer den generischen Listener ins Spiel bringst, den willst Du doch gar nicht haben. Irgendwo reden wir aneinander vorbei...

Hast Du vielleicht die Ports verwechselt? Schickst Du die Daten immer an die 2727? Der Port braucht natürlich die payload wie oben beschrieben.

Ich habe jetzt mal nachgeschaut, Du schreibst gleich in Deinem ersten Post, das Du in der plugin.conf port = 56000 genommen hast, und das auch der Port ist, den Du bei nw_udp_listen nutzt. Das ist natülich quatsch! Der Port in der plugin.conf ist der, auf den der generische Listener des nw-Plugin hört (default 2727, am besten erstmal so lassen und gar keine port angabe machen, auch nicht port = *). Damit kannst Du dann per udp generische Kommandos an sh.py schicken, die müssen dem Format der payload entsprechen.

Deine Logik soll aber auf das hören, was über 56000 kommt! Deswegen gibst Du in der logic.conf ein nw_udp_listen = 56000 an und nur da!

Es sind einfach 2 verschiedene Sachen, und durch den gleichen Port hast Du sie zusammen gebracht, wobei dann wohl immer der generische Listener gewonnen hat.

Gruß, Waldemar

Hmm. Ich glaub, jetzt hast Du mich verloren...

Nochmal langsam. Lt. Doku ist es so

plugin.conf

ip: specifies the listening IP address. By default it listens on all addresses.
port: specifies the listening port for generic incoming TCP and UDP connections. By default it listens on 2727.
udp: by default the plugin doesn’t accept incoming UDP connections. You have to set this attribute to ‘yes’ to accept them.
udp_acl: with this attribute you could specify a list or a single IP address to allow UDP updates from. By default it accepts every incoming request.

Deswegen ist meine plugin.conf so:

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
    udp_acl= *
    port = 56000
    udp = yes

Wenn ich im Debug hochfahre, ist das so auch im Log:

Code:

2016-01-06 17:59:52,917 DEBUG    Main         Plugin: nw -- plugin.py:__init__:43
2016-01-06 17:59:52,999 DEBUG    Main         Adding listener on: udp:0.0.0.0:56000-- __init__.py:add_listener:151
2016-01-06 17:59:53,087 DEBUG    Main         UDPDispatcher: binding to 0.0.0.0:56000(UDP) -- connection.py:connect:161

Damit sollte das Plugin nun auf Port 56000 von allen beliebigen IP-Adressen hören - was es auch lt. meinen Tests soweit tut.

=> Haken dran.

logic.conf
Jetzt möchte ich, dass direkt eine Logik anspringt, deswegen sieht meine logic.conf so aus

Code:

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

Damit sollte also eine beliebige IP-Adresse als Sender auf Port 56000 das Paket schicken dürfen. Das klappt auch (fast):

Code:

2016-01-06 18:08:59,281 DEBUG    Main         UDPDispatcher: incoming connection from xx.xx.xx.xx:56000 to 0.0.0.0:56000-- __init__.py:handle_connection:109
2016-01-06 18:08:59,286 INFO     Main         Ignoring input 1;0001;TOM      ;1;8;1;80207xxxx;TUER;1;-. Format not recognized. -- __init__.py:parse_input:184

Daher mein Hinweis, dass lt. Doku vom Sender (in dem Fall das CV LAN) ein Datenpaket mit aufbau "key|id|value" erwartet wird. Da das CV LAN natürlich "key|id|" nicht voranstellt, fliegts hier auf die Nase.

Wo Du mich verloren hast, war Deine Aussage, ich hätte einen "gegnerischen Listener" konfiguriert? ...aber vielleicht verstehe ich nur das Konzept des UDP nicht. Ich dachte ein Sender (in dem Fall CV LAN) schickt auf einem Port (in dem Fall 56000) eine Nachricht (in dem Fall "1;0001;TOM;1;8;1;80207xxxx;TUER;1;-"). Wenn das network-Plugin auf die IP-Adresse des Senders mit dem Port beim Empfänger zurecht kommt, wird die Nachricht bearbeitet. Das passiert ja bei mir - allerdings leider mit dem bekannten Fehler.

oder ich hab wirklich nen riesen Knoten im Hirn!

Aber Danke trotzdem für Eure Hilfe!

**binderth** · 06.01.2016, 18:43

AH! ich habs jetzt nochmal mit folgender plugin.conf probiert:

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
    udp_acl= *
    port = *
    udp = yes

Fragt mich nicht, was jetzt passiert ist, aber damit klappt es. Ich hatte das ja gestern getestet und hatte keinerlei UDP-Reaktion erhalten. Jetzt aber klappts!!!!

oh mann. Soooo simpel.
Zur Sicherheit hier nochmal meine logic.conf

Code:

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

Damit läuft nun alles so, wie es soll:

Code:

2016-01-06 18:31:03,452 DEBUG    Main         Plugin: nw -- plugin.py:__init__:43
[COLOR=#008000]2016-01-06 18:31:03,539 DEBUG    Main         Adding listener on: udp:0.0.0.0:* -- __init__.py:add_listener:151
2016-01-06 18:31:03,630 DEBUG    Main         UDPDispatcher: binding to 0.0.0.0:* (UDP) -- connection.py:connect:161[/COLOR]
[COLOR=#FF0000]2016-01-06 18:31:25,925 DEBUG    Main         Adding listener on: udp:0.0.0.0:56000-- __init__.py:add_listener:151
2016-01-06 18:31:25,939 DEBUG    Main         UDPDispatcher: binding to 0.0.0.0:56000(UDP) -- connection.py:connect:161[/COLOR]

...
2016-01-06 18:32:03,788 DEBUG    Main         UDPDispatcher: incoming connection from xx.xx.xx.xx:56000 to 0.0.0.0:56000-- __init__.py:handle_connection:109
2016-01-06 18:32:03,794 DEBUG    Main         Triggering fingerprint - by: network source: xx.xx.xx.xx dest: None value: 1;0001;TOM;1;7;1;80207xxx;TUER;1;- -- scheduler.py:trigger:162
2016-01-06 18:32:03,801 INFO     fingerprint  Payload = 1;0001;TOM;1;7;1;80207xxx;TUER;1;- -- fingerprint.py:<module>:15
2016-01-06 18:32:03,807 INFO     fingerprint  Source = 192.168.178.22 -- fingerprint.py:<module>:18
2016-01-06 18:13:05,001 INFO     fingerprint  Benutzer TOM wurde mit Finger 7 als Schlüssel-ID 2 am Fingerprintsensor TUER richtig erkannt. -- fingerprint.py:<module>:79

Danke für die Anschupser.

Waldemar: ist es so, dass in der plugin.conf dein "gegnerischer Listener" konfiguriert wurde? oder meintest Du den "generischen Listener", weil dann habe ich nun wohl das Konzept des network-plugin endgültig verstanden.
Die "generischen Listener" (oben grün im Log markiert) arbeiten in der Tat mit den dreifachen Paramentern "key|id|value", wenn Du aber einen weiteren eigenen Listener (ich hier in der logic und oben rot markiert) einbaue, dann ist ihm das ganze generische egal und er nimmt einfach den Payload und arbeitet mit diesem.

**mumpf** · 06.01.2016, 18:54

Hi,

ich habe immer nur vom generischen Listener geschrieben (den gegnerischen hast Du draus gemacht) und nichts anderes gesagt, als Du in Deinem Resumé... gut dass es klappt. Ich würde aber immer noch den port = * weglassen...

Gruß, Waldemar

**Sandman60** · 06.01.2016, 21:28

GELÖSCHT... port=* raus und nur udp_acl = * stehen lassen...

**mumpf** · 06.01.2016, 22:52

Hallo Oliver,

dann ist ja gut

Hatte zwischendurch auf dem Handy Deine Antwort gelesen und wollte eigentlich jetzt eine längere Erklärung abgeben, was Du missverstanden hast. Ich hätte natürlich solche Worte wie "Blödsinn" nicht gebraucht.
Mit Deiner aktuellen Antwort sind wir uns ja einig...

Gruß, Waldemar

**Haiphong** · 02.11.2018, 19:14

Hallo Kollegen,

wenn ein „Ekey home AF“ über den „ekey home converter LAN RS-485“ in SH eingebunden wird,
ist die Ekey Steuereinheit dann – bzgl, Steuerung - Nebensachen ??

Kann jeder der 99 Finger eine KNX Adresse – per UDP - ansteuern ??

Danke, JG

Ankündigung

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

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar