[FULLY] Support Thread ab 2025

Begonnen von Beta-User, 26 November 2025, 21:31:14

Vorheriges Thema - Nächstes Thema

bertl

#15
Ja, so macht es spaß!

Zitat von: Beta-User am 05 Mai 2026, 16:42:22Übersehe ich bei diesem überschlägigen Vergleich was wichtiges?

Nein, da geht es aus meiner Sicht nur um Kosmetik.
Sobald das Polling wieder aktiviert wird, muss zuerst das "pollInterval" verstreichen, dass ein Update passiert.
Anders würde gleich ein Update angestoßen werden.

Bevor wir uns jetzt bezüglich loop und dessen Auswirkung genauer unterhalten, eine grundsätzliche Frage an dich:
Wie kann der Fall, dass der $disableLevel > 1 wird überhaupt eintreten, speziell in diesem Modul?

Beta-User

#16
Zitat von: bertl am 05 Mai 2026, 19:13:15Wie kann der Fall, dass der $disableLevel > 1 wird überhaupt eintreten, speziell in diesem Modul?
Derzeit tritt dieser Fall ohne Manipulation durch den User nicht ein :) . Da es Leute geben soll, die ihr WLAN nachts abschalten, könnte aber über ein Attribut "disabledForIntervals" nachdenken; das hatte ich im Hinterkopf bei der Umstellung auf IsDisabled() ;) .

Zitat von: bertl am 05 Mai 2026, 19:13:15Anders würde gleich ein Update angestoßen werden.
Muss ich mir ansehen, scheint dann eine indirekte Folge zu sein, bei der wir auch den direkten Weg gehen könnten und sollten...?
EDIT: Du meinst wohl, dass man FULLY_UpdateDeviceInfo() aufrufen soll? Das macht m.E. Sinn.
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

bertl

#17
Zitat von: Beta-User am 06 Mai 2026, 07:30:35über ein Attribut "disabledForIntervals" nachdenken
Ja, dann macht "return if !$interval;" Sinn.
Weil bei einer mögliche Implementierung des "disabledForIntervals" der Timer wieder angestoßen werden würde/müsste.

Zitat von: Beta-User am 06 Mai 2026, 07:30:35Du meinst wohl, dass man FULLY_UpdateDeviceInfo() aufrufen soll?
Nein ich meine nicht "FULLY_UpdateDeviceInfo" sondern "FULLY_GetDeviceInfo".
Beide Funktionen machen ja das gleiche, bis auf das "FULLY_SetPolling".
Und das wird ja in "FULLY_Start" gesetzt.
Daher denke ich, dass das Verschieben von "FULLY_GetDeviceInfo" wie im Post https://forum.fhem.de/index.php?msg=1363144 vorgeschlagen, passen sollte.
Da es ja nur um das Update der Readings geht und nicht um das Polling.
EDIT: "FULLY_Start" wird beim Define und wenn sich Attribute ändern aufgerufen - somit sollte das "FULLY_GetDeviceInfo" keine Probleme machen.

bertl

Spannende Erkenntnis:

Ich habe FHEM neu gestartet und siehe da, FULLY_Start wurde nicht aufgerufen.
Somit gibt es auch kein Polling und das Modul macht nichts, es steht wie ein Stein.

Nach genauerer Analyse habe ich das Problem gefunden.
Beim Startup wird zuerst "FULLY_Define" aufgerufen und nachdem "init_done" noch 0 ist, der Timer zum Aufruf von "FULLY_Start" gestartet.
Im Anschluss wird automatisch "FULLY_Attr" nacheinander mit den bestehenden Attributen aufgerufen.
Und hier werden alle Timer gelöscht und keiner mehr aufgerufen, nachdem "init_done" immer noch 0 ist.

Folgende Änderung in "FULLY_Attr" löst das Problem:
-    RemoveInternalTimer($hash);
-    return InternalTimer(gettimeofday()+1, \&FULLY_Start, $hash, 0) if $init_done;
+    if ($init_done) {
+        RemoveInternalTimer($hash);
+        return InternalTimer(gettimeofday()+1, \&FULLY_Start, $hash, 0);
+    }

Beta-User

 :o Ups...

Habe beides jetzt geringfügig anders sortiert und stelle mir jetzt die Frage, ob man a) setPolling überhaupt in der Form benötigt, und b) ob es tatsächlich ok ist, bei einem deaktivieren Device diese erste Anfrage zu machen?!?

Nun ja, einen Schritt nach dem anderen.
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

bertl

...wird immer besser  :)

ad a) was genau meinst du damit?
ad b) diese erste Abfrage in "FULLY_Start" würde ich nach den disable-Abfragen machen und zusätzlich bei der "$hash->{nextUpdate}" Abfrage auf "disabled" prüfen. Weiters sollte das "FULLY_GetDeviceInfo" innerhalb der Abfrage gestrichen werden.

in etwa so:
@@ -241,12 +241,6 @@
     #if (!exists($hash->{fully}{password})) {
     #}

-    if ( !defined $hash->{nextUpdate} ) {
-        $hash->{nextUpdate} = 'off';
-        FULLY_Log ($hash, 3, "Opening device $hash->{host}");
-        FULLY_GetDeviceInfo ($name);     #review needed. Should this really happen when device ist disabled?
-    }
-
     my $disableLevel = IsDisabled($name);
     if ( $disableLevel == 1 ) { # Return without any further action if the module is disabled
         $hash->{nextUpdate} = 'disabled';
@@ -260,8 +254,12 @@
         return InternalTimer(gettimeofday()+$interval, \&FULLY_Start, $hash, 0);
     }

+    if ( !defined $hash->{nextUpdate} or $hash->{nextUpdate} =~ "disabled") {
+        $hash->{nextUpdate} = 'off';
+        FULLY_Log ($hash, 3, "Opening device $hash->{host}");
+    }
+
     return FULLY_UpdateDeviceInfo($hash); # internally calls setPolling... review of setPolling wrt. to complete code restructuring?
-    #return FULLY_SetPolling($hash, 1);
 }