DevIo_Open & fhem shutdown restart

Begonnen von olwaldi, 03 Oktober 2026, 11:02:23

Vorheriges Thema - Nächstes Thema

Beta-User

Zitat von: olwaldi am 09 Oktober 2026, 07:21:17Ich habe nochmal kurz über das initiale Notify nachgedacht, und vom Prinzip her finde ich das schon OK so, wenn es denn schon solch einen etablierten Mechanismus gibt. Ursprünglich hat DENON_AVR intern Alles inkl. Attributsetzen via notify erledigt, das war sicher nicht notwendig.
Eine NotifyFn(), die nichts anders macht, wie beim Start von FHEM initial irgendwelche Anfragen zu starten, ist zwar funktional (und das war früher (!) auch der empfohlene Weg). Von daher kann man sich zurücklehnen und alles lassen wie es ist.

ABER: Notwendig ist es nicht, und das nach InternalTimer umzubauen, ist kein wirklicher Aufwand. Dafür muss fhem.pl nicht bei jeder Änderung schauen, ob das DENON_AVR davon was wissen will, wenn "jemand" einmal mehr die Tabelle mit den zu benachrichtigenden Devices neu aufbauen lässt. Das passiert tendenziell häufiger...
Und man kann dieselbe Funktion auch für "enable" verwenden, was für den Teil Übersicht schafft.

Nur meine Meinung :) .
Server: HP-elitedesk@Debian 13, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

rudolfkoenig

Der Haken an NotifyFn ist, dass es relativ "teuer" ist, d.h. unnoetig viel CPU verbraucht, da es fuer alle Events aufgerufen wird.

Man kann die Aufrufe zwar einschraenken (Stichwort setNotifyDev bzw. $hash->{NOTIFYDEV}) oder nach der Initialisierung NotifyFn entfernen, aber das ist aufwendiger als InternalTimer(1, "Module_InitiFn", $hash, 0);

olwaldi

Jetzt hab' ich's endlich kapiert und die NotifyFn wieder komplett gestrichen... Das DENON_AVR_Define beende ich jetzt einfach mit
InternalTimer(1, "DENON_AVR_Connect", $hash, 0);
return;
Keine Notify-Regristrierung nötig, keine NotifyFn, kein if-then-else bzgl. init_done. Getestet und funktioniert wie gewünscht.

Danke für's Insistieren, Michael

Beta-User

 :)

Zwei Anmerkungen:
- Den Timer mit der "vergleichseise hohen" Prio von "so bald als möglich" einzureihen, würde ich nochmal überdenken. Es reicht doch auch "jetzt und 5 Sekunden", dann haben andere "wichtige" Module die Option, sich vorher aufrufen zu lassen.
- Wenn die von dir genannte Funktion die "allgemeine Start-Funktion" des Moduls ist, ist das ok. Wenn vorab aber noch das eine oder andere an Vorprüfungen rein sollte (insbesondere auf IsDisabled()), würde ich noch einen "wrapper" (DENON_AVR_Init, DENON_AVR_Start oder so) davor setzen.
Server: HP-elitedesk@Debian 13, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors