AssignIoPort bei Zwei-Modul Systemen mit Dispatch()

Begonnen von Ralf9, 09 Oktober 2015, 22:24:18

Vorheriges Thema - Nächstes Thema

justme1968

die module aus Clients werden nicht (automatisch) geladen. in computeClientArray wird Clients mit Match der zur zeit geladenen module zusammengeführt. die geladenen module sind die für die es zum jeweils aktuellen zeitpunkt ein definiertes device gibt. hier wird als reihenfolge dir nummer am anfang des modul file namen verwendet. d.h. du hast auch hier einfluss auf die reihenfolge. wobei ich mir nicht sicher bin ob es geschickt ist etwas von der reihenfolge abhängig zu machen (siehe unten).


du hast recht. das laden passiert nur ein mal.

das dies der vorgesehene weg ist heisst ja nicht das das andere unter bestimmten randbedingungen (nur empfangen, nicht senden, FingerprintFn nur im physikalischen modul, nicht im logischen) auch funktionieren kann. es heisst aber das es vermutlich der effizienteste weg ist da z.b. normalerweise nur auf die beim anwender auch tatsächlich vorhanden und definierten devices gematched wird und auf die 10 anderen die das modul zwar kann aber für die noch nichts empfangen wurde. du weisst ja nicht ob ein anwender das erste oder das 10. aus der liste einsetzt.

gruss
  andre

hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

Sidey

Hi Andre,

Jetzt ist der Groschen bei mir gefallen. Ich denke jetzt habe ich es verstanden.

Die MatchList hat den Zweck ein Modul bei Bedarf laden zu können.
Damit nicht wahllos irgendwas geladen wird, gibt es eine Regex die verständlicher Weise im IO Dev Modul definiert wird.
Damit die ankommende Nachricht nicht verloren geht, wird parsefn aufgerufen.

Die Clientliste enthält die bereits geladenen und vom Autor des IO Dev Modules vorgesehenen Module. In einem versteckten Imternal stehen die geladenen Module, welche nur auch in Clientlist spezifizierte sein können.
Ab dem Zeitpunkt, wo ein Modul geladen ist, gilt die Match Regex aus dem logischen Modul.

Man könnte den clientArray demnach auch durch ein paar split und concat Befehle aus der MatchList erzeugen.

Nur mit der MatchList zu arbeiten geht, dafür ist diese aber nicht gedacht.

Ich werde mal versuchen das ins Wiki einzubauen.

Sidey
Signalduino, Homematic, Raspberry Pi, Mysensors, MQTT, Alexa, Docker, AlexaFhem,zigbee2mqtt

Maintainer von: SIGNALduino, fhem-docker, alexa-fhem-docker, fhempy-docker

justme1968

hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

herrmannj

Hi,

erlaube mir mich einzuklinken, hänge da auch gerade:

Aufgabe:
ich möchte testweise ein modul für spezielle WMBUS Nachrichten erstellen die vom 36_WMBUS nicht dekodiert werden.

Idealerweise möchte ich nicht 01_CUL oder 36_WMBUS patchen.

Ziel: ich erstelle das Modul (testlevel), definiere die Instanzen von Hand (auf autocreate verzichte ich vorerst)

Danach soll "dispatch" CUL Nachrichten mit
"^b.+{24}A0.*" an den (meinen) Prototypen leiten und
"^b.*" weiterhin an 36_WMBUS

Reicht es das modul 35_whatever zu nennen (also kleinerer prefix) und im intitialize $hash->{Match} = "^b.+{24}A0.*" zu setzen ?

Danke und vg
joerg
joerg

rudolfkoenig

Nein. Wenn du sicherstellst, dass 35_whatever geladen ist (z.Bsp. via define), dann musst du noch $clientsWMBus mit whatever erweitern. Sonst musst du zusaetzlich zu Match und clientsWMBus auch noch matchListWMBus erweitern.

Btw: ich glaube dein regexp ist fehlerhaft, + und {24} vertragen sich mWn nicht.

justme1968

du musst in die Clients liste von 00_CUL. sonst wird deine Match garnicht erst ausgewertet.

wen du ohne autocreate arbeitest und du dein modul von hand lädst müsste es eigentlich gehen wenn du im der DefFn deines moduls vor dem AssignIoPort aufruf die Clients liste der cul instanz die du verwenden willst patchst. das sollte zum testen gehen. sauber ist aber anders :)

autoload geht aber nicht ohne das dein modul in der MatchList steht.

eine andere möglichkeit die mir einfällt die eventuell geht ist wenn du zur laufzeit $modules{WMBUS}{ParseFn} durch deine ersetzt bei nicht passenden nachrichten wieder das original aufrufst. nicht wirklich sauberer aber das hätte den vorteil das die ein rfmode umschalten oder reconnect beim cul nicht Clients wieder zurück setzt.

gruss
  andre
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

herrmannj

Iss ja erstmal "nur" POC.

Also, $hash->{MatchList} vom CUL zur Laufzeit "patchen"

Der erste char ("J:WMBUS"     => "^b.*" / hier das "J") gibt die Reihenfolge an ?

Danke.
vg
joerg

justme1968

MatchList musst du anpassen wenn autload funktionieren soll. Clients musst du anpassen damit Dispatch funktioniert.

gruss
  andre
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

herrmannj

oh. sorry. ok dann hab ichs (glaub ich) verstanden

danke und Grüße
Jörg

herrmannj