Unterdrückung IODEv Zuordnung wie bei CUL_WS generalisieren

[noansi]

Hallo Rudolf,

hier https://forum.fhem.de/index.php/topic,24436.msg1008647.html#msg1008647 und folgende hat ein User Probleme, meine SlowRf TSCUL_XX Module so zu nutzen, wie seine CUL_XX Entsprechung, insbesondere CUL_WS.

Das hängt damit zusammen, das ich ein Feature in CUL_WS übernommen habe, nämlich unabhängig vom empfangenden IODev die Sensornachrichten zu verarbeiten.

Dummerweise setzt dies vorraus, dass den Sensordevices nicht automatisch ein IODev (als Attribut) von fhem.pl zugeordnet wird.
Das hast Du in fhem.pl in aktuell Zeile 2201f mit

Code Auswählen Erweitern

    $attr{$hn}{IODev} = $hash->{IODev}{NAME}
      if($hasIODevAttr && $hash->{TYPE} ne "CUL_WS");

nur für CUL_WS eingebaut.

Mein Vorschlag wäre, das zu generalisieren mittels einer Moduleigenschaft, die in der _Initialize($) Funktion des Moduls zu setzen wäre, z.B. als $hash->{NoAutoIODevAssign}=1. Diese Eigenschaft könntest Du dann an obiger Stelle statt speziell TYPE "CUL_WS" abfragen.

Damit könnten auch andere Module diese Funktionalität ebenso unkompliziert nutzen, z.B. für Multiempfänger Systemkonfiguration. Und Du müsstest wohl neben fhem.pl nur 14_CUL_WS.pm anpassen.

Damit wäre auch die bisherige autocreate Unterdrückung via autocreate Attrbut "ignoreTypes" nicht mehr zwangsläufig, wenn ein Sensordevice angelegt ist.

Gruß, Ansgar.

[rudolfkoenig]

Mein Vorschlag wäre, das zu generalisieren mittels einer Moduleigenschaft, die in der _Initialize($) Funktion des Moduls zu setzen wäre, z.B. als $hash->{NoAutoIODevAssign}=1. Diese Eigenschaft könntest Du dann an obiger Stelle statt speziell TYPE "CUL_WS" abfragen.

Das waere definitiv ein Fortschritt, und ich habe kein Problem es einzubauen, ich meine nur, dass es nicht optimal ist.

Eine bessere Loesung waere in AttrFn $hash->{IODevMissing} zu entfernen: damit wird AssignIoPort nach der Initialisierung fuer diese Instanz nicht mehr aufgerufen.

Noch effizienter waere AssignIoPort in DefFn gar nicht aufzurufen (das wuerde auch einen sinnlosen und falschen $hash->{IODev} ersparen), stattdessen muss man delete($iohash->{".clientArray"}) in AttrFn und in DefFn ausfuehren.

Wie ist deine Meinung dazu? Uebersehe ich etwas?

[noansi]

Hallo Rudolf,

Wie ist deine Meinung dazu? Uebersehe ich etwas?

Ich sehe leider keinen Kommentar, warum es so rein gekommen ist.

Ich kann nur annehmen, dass es mal darum ging, bidirektionalen Devices möglichst ein existierendes IODev zuzuordnen (was bei mehreren verfügbaren IOs derzeit wohl aber nicht wirklich zwingend zu funktionierender Kommunikation führt)?!?
Fällt Dir dazu noch was zur Historie ein?

Die derzeitige Problematik betrifft rein empfangende Devices, für die wahlweise Redundanzempfang oder IODev gebundener Empfang möglich sein soll, wie es bei CUL_WS möglich ist.

Mein Vorschlag mit Moduleigenschaft würde Nebenwirkungen auf andere Module vermeiden und Modulprogrammierer/-maintainer müssten es aktiv zur Nutzung anwenden.

Es könnte z.B. zu Performance Problemen führen, wenn langsame Module die Empfangsdaten von allen empfangenden IOs verarbeiten müssen, statt nur die, für die explizit das IODev Attribut gesetzt ist, wenn ein Mehrfachempfangsfilter nicht implementiert ist.
Autocreate könnte so was bei Neuanlage von Devices provozieren, existierende Konfigurationen sollten das Attribut ja schon gesetzt haben. Das soll wohl schon der Mehrfachempfangsfilter in Dispatch verhindern.

Noch effizienter waere AssignIoPort in DefFn gar nicht aufzurufen

Das teste ich mal.

Gruß, Ansgar.

[noansi]

Hallo Rudolf,

stattdessen muss man delete($iohash->{".clientArray"}) in AttrFn und in DefFn ausfuehren.

Das verstehe ich noch nicht.
AttrFn könnte sich $iohash beim Setzen oder Löschen versuchen zu bilden. Aber wo keines per AttrFn gesetzt oder gelöscht wird, da kann es doch nicht wirken??? Und CommandAttr manipuliert die ohnehin nachdem AttrFn aufgerufen wird.

DefFn kennt $iohash noch gar nicht???

Gruß, Ansgar.

[noansi]

Hallo Rudolf,

Noch effizienter waere AssignIoPort in DefFn gar nicht aufzurufen

Das scheint zu funktionieren.

Sobald dann natürlich ein IODev via Attribut definiert wird, dann wird bei Eintreffen einer Sensormessage über ein anderes IODev wieder versucht ein neues IODev-unspezifisches device anzulegen.

Ich denke, der Name für das AutoCreate Device muss noch um den IO-Namen ergänzt werden. Dann wird es möglicherweise einfacher, es IODev-spezifisch zuzuordnen, wenn man das machen will.

Vielen Dank für den Gedankenanstoss.

Gruß, Ansgar.

[rudolfkoenig]

Ich kann nur annehmen, dass es mal darum ging, bidirektionalen Devices möglichst ein existierendes IODev zuzuordnen

Hier wollte ich nur ermoeglichen, mehr als 8 CUL_WS zu betreiben (die Dinger waren billig, und funktionieren immer noch gut).
Sonst ist die FHEM-Philosophie: Input-Device ist egal, Output wird per IODev festgelegt. In diesem Fall wurde Input auch durch IODev festgelegt.

DefFn kennt $iohash noch gar nicht???

Wo du Recht hast...
Man muss $iohash->{".clientArray"} loeschen, sonst wird nach dem allerersten Empfang einer CUL_WS Nachricht in Dispatch immer die zweite (ineffiziente) Schleife mit LoadModule durchgelaufen. Ich habe aber jetzt genau hier delete($hash->{".clientArray"}) eingebaut, die CUL_WS Sonderbehandlung aus fhem.pl entfernt, und AssignIoPort aus CUL_WS.pm geloescht. Auch deine Aenderung sollte damit selbst in diesem Sonderfall richtig funktionieren.

Ich denke, der Name für das AutoCreate Device muss noch um den IO-Namen ergänzt werden. Dann wird es möglicherweise einfacher, es IODev-spezifisch zuzuordnen, wenn man das machen will.

Das ist richtig, aber nur, wenn man eine IODev-Input-Bindung haben will, und das ist bei CUL_WS nicht immer beabsichtigt.
In anderen Faellen (z.Bsp. MQTT2) wird im UNDEFINED Event auch der Name des IODevs mitgegeben, und DefFn ruft AssignIoPort mit diesem als "proposed" auf.

[noansi]

Hallo Rudolf,

(die Dinger waren billig, und funktionieren immer noch gut).

Kann ich nur bestätigen. Leider gibt es sie nicht mehr zu kaufen.

und AssignIoPort aus CUL_WS.pm geloescht

Das hast Du auch in anderen Modulen noch drin, CUL_EM zum Beispiel. Falls es nicht beabsichtigt ist, dann wäre es vermutlich sinnvoll auch dort noch AssignIoPort zu löschen.
Deine Änderungen muss noch testen.

wenn man eine IODev-Input-Bindung haben will, und das ist bei CUL_WS nicht immer beabsichtigt.

Und der User benennt sie ohnhin noch um.
Ich habe es bei mir mal rein gepackt, weil es auch beim Setzen von IODev, ohne den Namen des Devices zu ändern, UNKNOWN Log Meldungen vermeiden hilft. Der automatisch generierte Name existiert dann schon.

Gruß, Ansgar.

[rudolfkoenig]

Das hast Du auch in anderen Modulen noch drin, CUL_EM zum Beispiel.

Stimmt, stoert aber nicht, da dieses Feature (Geraete _zusaetzlich_ auch nach IODev zu unterscheiden) nie implementiert wurde.

[noansi]

Hallo Rudolf,

Man muss $iohash->{".clientArray"} loeschen, sonst

Sieht nach einer guten Stelle dafür aus.

Danke!

Gruß, Ansgar.