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);