[FULLY] Support Thread ab 2025

[bertl]

Ja, so macht es spaß!

Ü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]

Wie 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() .

Anders 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.

[bertl]

ü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.

Du 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.