Zwei Modul instanzen lauschen auf einem UDP Port

[torte]

Hallo zusammen,

bei meinem Modul für die XiaomiSmartHome Komponenten wird auf dem UDP Port 9898 gelauscht.
Wenn das Modul nur eine Instanz hat läuft alles soweit richtig, nur wenn man 2 oder mehr Smarthome Gateways hat kommt es dann dazu
das die Modulinstanzen im wechsel sich die UDP Meldungen der Gateways schnappen.

Code Auswählen Erweitern


2017.06.11 17:54:49 5: MIGATE2: Read> f0b429cc5f08 not matching with my SID 34ce0088d6bc skipping
2017.06.11 17:54:54 5: MIGATE2: Read> Read start
2017.06.11 17:54:54 5: MIGATE2: Read> {"cmd":"heartbeat","model":"gateway","sid":"34ce0088d6bc","short_id":"0","token":"qIDAwl7BS0bUhIjo","data":"{\"ip\":\"192.168.1.131\"}"}
2017.06.11 17:54:54 4: MIGATE2: Read> Heartbeat from 192.168.1.131 received with 34ce0088d6bc
2017.06.11 17:54:54 5: MIGATE: Read> Read start
2017.06.11 17:54:54 5: MIGATE: Read> {"cmd":"heartbeat","model":"gateway","sid":"34ce0088d6bc","short_id":"0","token":"qIDAwl7BS0bUhIjo","data":"{\"ip\":\"192.168.1.131\"}"}
2017.06.11 17:54:54 5: MIGATE: Read> 34ce0088d6bc not matching with my SID f0b429cc5f08 skipping
2017.06.11 17:54:57 5: MIGATE2: Read> Read start
2017.06.11 17:54:57 5: MIGATE2: Read> {"cmd":"heartbeat","model":"gateway","sid":"f0b429cc5f08","short_id":"0","token":"W25BBdpMHMk7yeKb","data":"{\"ip\":\"192.168.1.115\"}"}
2017.06.11 17:54:57 5: MIGATE2: Read> f0b429cc5f08 not matching with my SID 34ce0088d6bc skipping
2017.06.11 17:54:57 5: MIGATE: Read> Read start
2017.06.11 17:54:57 5: MIGATE: Read> {"cmd":"heartbeat","model":"gateway","sid":"f0b429cc5f08","short_id":"0","token":"W25BBdpMHMk7yeKb","data":"{\"ip\":\"192.168.1.115\"}"}
2017.06.11 17:54:57 4: MIGATE: Read> Heartbeat from 192.168.1.115 received with f0b429cc5f08


Im Modul habe ich das jetzt soweit gelöst das ich Meldungen skippe die nicht zur Modulinstanz passen. Das ist aber ja nicht richtig da ich damit dann ja die Informationen
aus dem UDP Paket verwerfe. Wie kann ich also die Daten an die richtige Modul-Instanz weiterleiten.
Hätte da jemand für mich eine Lösung oder Hinweis wie man in diesem Fall vorgeht.

Danke

Grüße
Torte

[CoolTux]

Hallo Torsten,

Ist es nicht egal welches Gateway die Daten empfängt. Entscheidend ist doch das das physikalische Module die Daten über den Dispatcher weiter gibt an die ParseFn des logischen Modules. Da sollte dann die Weiterverarbeitung statt finden. Oder habe ich Dich falsch verstanden?


Grüße

[rudolfkoenig]

Wie CoolTux das indirekt formuliert: sowas wird mit dem zweigeteilten Modulkonzept in FHEM geloest:

- das "phyikalische" Modul ist fuer die Kommunikation mit dem USB-Stick zustaendig (bzw. in diesem Fall oeffnet das UDP-Port), traegt sich in %selectlist ein (DevIo_OpenDev macht das schon), und falls was los ist, wird via ReadFn aufgerufen. Wenn die Daten "sinnvoll" sind (Laenge/Checksum/etc passt), dann ruft ReadFn Dispatch() mit jeweils einer Nachricht auf.

- das "logische" Modul repraesentiert ein per Funk/Kabel/etc angebundenes Geraet. Sein ParseFn wird von Dispatch aufgerufen, wenn die Nachricht laut $modulhash->{Match} passt. Falls man autocreate unterstuetzen will, dann muss das physikalische Modul alle Nachrichten-Regexp/Modul Kombinationen in $modulhash->{MatchList} angeben.

[torte]

mmh.

Ich hab ja 2 Stufiges Konzept. Das logische Modul sind jetzt nur die Sensoren an sich die an einem Gateway angemeldet sind und auch über diese kommunizieren. Das Gateway ist bei mir aber innerhalb des physischen Moduls weil es für mich jetzt das phyische gerät war/ist und das existiert dann ja auch zweimal.

Also müsste das Gateway auch in ein logisches?  um dann beim ReadFn die richtige Instanz zu finden?!

Grüße
Torte

[rudolfkoenig]

Ich meine dein Problem jetzt besser zu verstehen. Ich haette drei moegliche Loesungen:
- die Gateways fuer unterschiedliche Ports konfigurieren (mAn die "richtige" Loesung). Falls das nicht geht:
- eine Instanz des Gatewaymoduls ist fuer alle Gateways zustaendig.
- beim Definieren entdeckt das Gateway-Modul, dass der UDP-Port bereits geoeffnet ist (modul-eigene lokale Variable), und oeffnet keine Zweite. ReadFn sucht anhand einer ID im UDP-Paket den richtigen Gateway-Instanz-hash, so aehnlich, wie die logischen Module in ParseFn das schon machen sollten, und macht damit weiter.

[torte]

Hallo,

danke!!

Hab das nun so gelöst, hoffe das das so der richtige Ansatz ist.

Hab in dem Physischen Modul einem defptr mit einer ID gesetzt.
Im ReadFn wird geprüft ob die ID vom %defs mit der ID aus der UDP Antwort stimmt. Wenn nicht hole ich den Hash aus dem defptr und rufe damit meine
Reading Funktion auf.

Code Auswählen Erweitern


$modules{XiaomiSmartHome}{defptr}{$rsid}->{SID} ne $hash->{SID} ){
$self = $modules{XiaomiSmartHome}{defptr}{$rsid};
Log3 $name, 5, "$name: Read> Change HASH Ref to $self->{NAME}";
XiaomiSmartHome_Reading ($self, $buf);



Den Port kann man leider selber nicht ändern deswegen ging Option 1 nicht.

Grüße
Torte

[torte]

@cooltux, soorrry hab deine Antwort übersehen 

[CoolTux]

Kein Thema. Verstehe das eigentliche Problem leider immer noch nicht so ganz. Obwohl es mich ja interessiert, ich aber im Moment auch keine Zeit habe. 

[torte]

Jedes GW hat ja auch eigene Readings für die LED, Klingelton usw. und wenn die Reporten dann schnappt sich mal die eine Modul-Instanz mal die andere die UDP Antwort.

Leider geht ja alles über den selben Port. Wenn ich zb. dem einem GW sage UpdateAll, quasi hole alle Stati von den Sensoren, dann antwortet dieses,
aber die Modul-Instanz vom falschen Gateway schnappt sich die UDP Antwort.

Mir war nur nicht klar ob ich im physischen Modul auf den defptr machen kann/darf um dann mir die richtige Modulinstanz rauszusuchen.

Grüße
Torsten