Ich möchte gerne einen Dummy mit einem setreading versehen, leider aktualisiert dieser Dummy dieses setreading nicht sofort, sondern erst nachdem ich die Webseite neu geladen habe. Woran kann das liegen oder ist das bei einem setreading normal?
([DY_Licht:"^on$"]) (
setreading DY_Licht status on
)
DOELSEIF ([DY_Licht:"^off$"]) (
setreading DY_Licht status off
)
Die Glaskugel sagt es könnte an "event-on-change-reading" liegen.
Aber ohne ein list des dummy ist das nur Hellsehen.
Gruß
Dan
Setreading erzeugt meines Wissens kein Event. Mit ReadingList/SetList arbeiten sollte funktionieren
Kurz, weil mobil
Zitat von: KernSani am 13 März 2019, 10:33:14
Setreading erzeugt meines Wissens kein Event.
Falsch, "setreading" erzeugt sehr wohl ein Event.
Dagegen erzeugt "setstate" kein Event.
Gruß
Dan
Zitat von: DeeSPe am 13 März 2019, 10:43:16
Falsch, "setreading" erzeugt sehr wohl ein Event.
Dagegen erzeugt "setstate" kein Event.
Gruß
Dan
Stimmt... Sorry habe ich durcheinandergebracht... https://fhem.de/commandref_DE.html#setreading
Es ist egal ob ein event-on-change-reading .* oder event-on-update-reading .* gesetzt wurde, erst nach einem Neuladen der Seite wird es angezeigt.
Schau mal in die commandref zu setreading:
Achtung: setreading generiert kein Event für ein Gerät X, falls es aus einem notify für Gerät X aufgerufen wurde. In so einem Fall könnte man auf "sleep 0.1; setreading X Y Z" ausweichen.
Leider kann ich nicht sagen, ob sich DOIF an der Stelle wie notify verhält, da ich dieses Modul nicht nutze.
als userreading sollte es auch funktionieren.
Hi,
ist das nicht eher dies hier?
Zitatlongpoll [0|1|websocket]
Falls gesetzt, FHEMWEB benachrichtigt den Browser, wenn Gerätestatuus, Readings or Attribute sich ändern, ein Neuladen der Seite ist nicht notwendig. Zum deaktivieren 0 verwenden.
Falls websocket spezifiziert ist, läuft die Benachrichtigung des Browsers über dieses Verfahren sonst über HTTP longpoll. Achtung: ältere Browser haben keine websocket Implementierung.
Gruß Otto
longpoll steht bei mir auf Websocket. Auch wenn ich es auf 1 stelle, ändert sich nichts. Der Wert des readings verändert sich erst nach einem Neuladen. Der State ändert sich sofort.
Moin,
ZitatDer Wert des readings verändert sich erst nach einem Neuladen. Der State ändert sich sofort.
ich meine das gibt es, bestimmte Werte in der Webansicht werden aktualisiert und andere nicht.
Ich meine, da gab es mal eine Aussage von Rudi. Ich habe die gestern bloß nicht gefunden.
Aber bei einem Dummy ändern sich bei mir die Werte mit einem setreading sofort, funktioniert das, wenn du das setreading in einem anderen Browserfenster absetzt?
Gruß Otto
Offensichtlich ist Tabletui (FTUI) im Einsatz, daher könnte sich die Frage stellen, ob es sich um ein grundsätzliches Refresh-Problem handelt?
Das trat in meinem System auf, bevor ich überall im HTML-Code von FTUI die class="prefetch" entfernt habe.
Danach aktualisierte alles wieder korrekt auf der Website.
Ja, ich benutze Tablet UI. Allerdings wird der Wert auch nicht in der FHEM Oberfläche verändert.
Zitat von: steffus am 14 März 2019, 11:09:56
Ja, ich benutze Tablet UI. Allerdings wird der Wert auch nicht in der FHEM Oberfläche verändert.
Da zu den beschriebenen Problemlösungen noch keine Antwort von Dir kam, hier noch einmal entsprechende Zitate:
Zitat von: Beta-User am 13 März 2019, 12:15:23
Schau mal in die commandref zu setreading:
Achtung: setreading generiert kein Event für ein Gerät X, falls es aus einem notify für Gerät X aufgerufen wurde. In so einem Fall könnte man auf "sleep 0.1; setreading X Y Z" ausweichen.
Leider kann ich nicht sagen, ob sich DOIF an der Stelle wie notify verhält, da ich dieses Modul nicht nutze.
Zitat von: frank am 13 März 2019, 12:19:31
als userreading sollte es auch funktionieren.
Zum Vorschlag von Frank, hier mal ein getesteter und funktionierender Test-dummy:
defmod d dummy
attr d setList on off
attr d userReadings status:on|off {ReadingsVal($name,"state","")}Gruß
Dan