Wer manipuliert hier den Status?

[Damian]

Ich habe das Problem, dass der Status eines Devices verschwindet, wenn man per FHEM-Widget z. B. select ein Reading des eigenen Devices verändert. Per F5 Aktualisierung kann der Status wiederhergestellt werden. Das Problem tritt in FW_detailFn nicht auf. Bei Readings fremder Devices gibt es dagegen kein Problem. Das Modul selbst verändert den Status nicht.

Zum Nachvollziehen folgende Definition mit dem FHEM-Widget select:

Code: [Auswählen]

defmod di_tester DOIF {}
attr di_tester room Labor
attr di_tester uiState {package ui_Table}\
widget([$SELF:test,"off"],"select,on,off")
attr di_tester uiTable {package ui_Table}\
widget([$SELF:test,"off"],"select,on,off")

setstate di_tester initialized
setstate di_tester 2022-03-09 22:19:26 test on

[Damian]

Vielleicht anders ausgedrückt, ohne auf die internen Abläufe einzugehen:

Mechanismen, die mit FW_detailFn funktionieren, funktionieren mit summaryFn nicht.

Was muss der Entwickler bei Nutzung von summaryFn beachten?

[rudolfkoenig]

Soweit ich sehe, existiert das Problem sowohl in der Uebersicht, wie auch in der Detailansicht.

fhemweb.js ruft bei der Initialisierung der Seite fuer alle div.fhemWidget Elemente FW_replaceWidget auf.
Bei Statusaenderung wird die Seite nicht neu aufgebaut, sondern nur der neue Wert hingeschickt.
Falls das Statuswidget setValueFn hat, dann wird sie mit dem Wert aufgerufen, ansonsten das HTML mit dem Wert ersetzt.
Bei dieser Ersetzung wurde FW_replaceWidget nicht aufgerufen.

Ab sofort wird FW_replaceWidget auch nach der Ersetzung aufgerufen.

[Damian]

Ab sofort wird FW_replaceWidget auch nach der Ersetzung aufgerufen.

Danke, das war´s. Jetzt verhält sich die Statusansicht genauso (korrekt), wie die Details-Ansicht - das wird viele DOIF-User freuen