HMCCU sparsames Notify einbauen

[Beta-User]

denn die Attribute werden erst gesetzt, wenn X_Attr undef zurückgibt.

...aber du weißt doch nach der Prüfung, was zurückgegeben wird, und alle anderen Infos sind da auch bekannt. Wenn gültig, kann also theoretisch auch direkt die passende sub aus HMCCU aufgerufen werden - man muss nur sicherstellen, dass die exisitert:

Code Auswählen Erweitern


return "invalid attribute value $attrval" if !$valid;
HMCCU_subx($iohash,$name,$attrname,$attrval) if defined &HMCCU_subx;
return;
Aber auch in der jetzigen Form sollte es schon ein deutlicher Performance-Gewinn sein, Danke für's Aufgreifen der Anregungen .

[zap]

Ich habe nur eine Funktion, die bei Änderung von Attributen die Readings refreshed. Wenn die aufgerufen wird, müssen alle Attribute schon den richtigen Zustand haben.
Die Funktion wird nur aufgerufen, wenn der Nutzer ein Attribut interaktiv anpasst, also z.B. nicht beim Start von FHEM.
Die Prüfung bei jedem einzelnen Attribut wäre ziemlich aufwändig und ineffizient.

[Beta-User]

Bisher kann ich nicht erkennen, dass sich das widersprechen würde. Du rufst doch auch schon Funktionen aus HMCCU auf, sehe ich grade (ebenfalls unter Beachtung diverser Rahmenbedingungen):

Beispiel:
https://svn.fhem.de/trac/browser/trunk/fhem/FHEM/88_HMCCUCHN.pm#L287 => HMCCU_SetDefaultSCDatapoints

Was mir sonst bei der Gelegenheit aufgefallen ist:
- Da wir da jüngst an anderer Stelle drübergestolpert sind:

Code Auswählen Erweitern

#L22 => require "$attr{global}{modpath}/FHEM/88_HMCCU.pm";
https://forum.fhem.de/index.php/topic,110125.msg1183527.html#msg1183527 =>

Code Auswählen Erweitern

use HMCCU;
- #L264 "$clHash->{IODev} = $defs{$attrval};" kommt mir für @startup nicht Reihenfolge-unempfindlich vor, und für nach $init_done irritiert mich der fehlende Validitätscheck.

[zap]

Oo.

Danke für den Hinweis mit SetDefaultSCDatapoints. Das könnte die Ursache für einige Probleme sein.

Für require statt use hatte ich einen guten Grund, der mir gerade nicht mehr einfällt. Also probiere ich es mal wieder mit use.

[Beta-User]

...vermutlich muss es "use 88_HMCCU;" sein...

Habe aus Anlass dieses Posts von dir mal in den Code gesehen und fand einige Dinge merkwürdig, angefangen damit, dass die Initialisierungsreihenfolge der Module irgendwie "zufällig" zu sein scheint und HMCCU keine ReadyFn() hat, obwohl es ein (Netzwerk-) IO-Modul ist (siehe dazu (und zu Problemen mit "use ...") ab hier bzw. die dort verlinkten Fundstellen).

Nachdem ich mit CUL_HM&Co. (das in Teilen als Vorbild gedient zu haben scheint) jetzt einige "Erfahrungen" mit dem Initialisierungsthema sammeln "durfte": Falls Interesse besteht, können wir gerne eine Art peer review machen, um diesen Teil und evtl. weitere Kleinigkeiten zu fixen. Es scheint im Übrigen auch durchaus noch eine ganze Reihe anderer Leute zu geben, die die Module (im Unterschied zu mir) nutzen und ggf. auch bessere Perl-Kenntnisse haben wie ich (Warnung: ich höre schon den einen oder anderen rufen: "ich mach mit, aber nur, wenn das gepackaged wird". Fände ich auch sinnvoll, schon alleine wenn ich die Klimmzüge sehe, die statt "use List::Util 1.45 qw(max min uniq);" nötig sind...).

[zap]

Habe aus Anlass dieses Posts von dir mal in den Code gesehen und fand einige Dinge merkwürdig, angefangen damit, dass die Initialisierungsreihenfolge der Module irgendwie "zufällig" zu sein scheint und HMCCU keine ReadyFn() hat, obwohl es ein (Netzwerk-) IO-Modul ist (siehe dazu (und zu Problemen mit "use ...")

HMCCU orientiert sich (wie auch ioBroker oder OpenHab) an der Architektur der CCU. Dort gibt es (mindestens) 2 Kommunikationsebenen.

Oberste Ebene: ReGa => HMCCU
Darunter: RPC => HMCCURPCPROC (je ein Subprozess je RPC-Schnittstelle, wie.z.B.BidCos-RF, HmIP-RF, HmIP-Wired, ...)

Zu den Aufgaben der Module:

HMCCU kommuniziert mit der ReGa-Schicht der CCU: kümmert sich um das Auslesen der CCU und Geräte Konfiguration und das Senden von Befehlen an die CCU.
Die HMCCURPCPROC Subprozesse (RPC Server) empfangen die Events von der CCU (also die Statusänderungen von Geräten) und verteilen diese als Readings an die HMCCUDEV und HMCCUCHN Devices.
HMCCU und HMCCURPCPROC Subprozesse kommunizieren über TCP Sockets miteinander.

Nachdem ich mit CUL_HM&Co. (das in Teilen als Vorbild gedient zu haben scheint)

Ganz und gar nicht. HMCCU verfolgt einen völlig anderen Ansatz. In CUL_HM werden alle Geräte individuell behandelt. HMCCU orientiert sich an Kanalrollen. Selbst neue Geräte, die gerade auf den Markt gekommen sind, können von HMCCU angesprochen werden. Ich muss dazu keinen Code anpassen. Der Nutzer muss halt einige Attribute mehr setzen, wenn eine Rolle noch nicht bekannt ist. Aber grundsätzlich funktioniert das.
In CUL_HM wurde das Rad neu erfunden, obwohl die CCU alle notwendigen Schnittstellen bereitstellt. Klar: dadurch ist man unabhängig von einer CCU, hat halt den Nachteil, dass es nicht mehr funktioniert, sobald der Hersteller (EQ-3) das Protokoll ändert / dicht macht => HmIP.

[Beta-User]

HMCCU kommuniziert mit der ReGa-Schicht der CCU: kümmert sich um das Auslesen der CCU und Geräte Konfiguration und das Senden von Befehlen an die CCU.
Die HMCCURPCPROC Subprozesse (RPC Server) empfangen die Events von der CCU (also die Statusänderungen von Geräten) und verteilen diese als Readings an die HMCCUDEV und HMCCUCHN Devices.
HMCCU und HMCCURPCPROC Subprozesse kommunizieren über TCP Sockets miteinander.

Ok, das ist nun gar nicht meine Welt.
Demnach scheinen aber die beiden Module HMCCU und HMCCURPCPROC je eine Art IO-Modul zu sein, so dass es mich halt prinzipiell wundert, dass weder ReadyFn() noch DevIo zum Einsatz kommen (also nach meinem Verständnis: die bessere Verzahnung der Module mit fhem.pl). Meine Vermutung ist, dass durch Nutzung der FHEM-Standardmethoden die teils berichteten Verbindungsprobleme insbesondere beim Start besser abgefangen werden könnten, aber das mag ja falsch sein...