Bitte um HILFE.... !! EXPERTEN-RAT gesucht!

[DocCyber]

Guten Abend!

ich stelle fest, dass die Anzeige von Werten in FTUI nicht zuverlässig aktualisiert werden, wenn sich die entsprechenden Device- bzw. Dummy-Daten ändern.

Mal klappt es automatisch innerhalb von rund 3 Sekunden nach dem zugehörigen Event, mal passiert nichts bzw erst nach manuellem Refresh des Browsers.
Ich habe das nun mehrfach bei unveränderter "Umgebung" beobachten können.
Leider ist der Fehler (ist es einer?? - Was sonst??) nicht reproduzierbar.

Was sind die generellen Veraussetzungen, dass eine Änderung von Gerätedaten in FHEM an FTUI weitergegeben wird?

Kennt das noch jemand? Wo können die Gründe liegen?

[gandy]

Hmm,  bei mir ist es oft sehr verschieden, mal läuft alles sehr fluffig, aktualisierte Werte werden instantan angezeigt, Tastendrücke und Seitenwechsel mittels Pagetab sofort umgesetzt. Dann gibt es wieder Phasen, in denen alles eine gefühlte Ewigkeit dauert, sogar die Debugeinblendungen bleiben zum Teil stehen und die Uhrzeit wird minutenlang nicht mehr aktualisiert. Das passiert sehr gern, nachdem der Bildschirmschoner am Tablet längere Zeit aktiv war. Firefox, Chrome und Opera zeigen hier das gleiche Verhalten. Auf dem PC habe ich den Effekt noch nicht beobachten können.

Grüße,
Andy.

[DocCyber]

Ich habe das Problem auf meinem Android-Tablet, auf dem nur FTUI verwendet wird (das ist ja der Sinn von FTUI), aber eben auch auf dem PC, wenn ich die Oberfläche weiterbaue und teste.

Hat das etwas mit event-on-change-reading zu tun, und falls ja: was?

Schade, dass sich sonst niemand dazu meldet, denn ich glaube nicht, dass du und ich die einzigen mit diesem Problem sind.

[All-Ex]

Hallo,

ich habe das auch manchmal und kann es jetzt hier reproduzieren. In FHEM habe ich folgendes DOIF angelegt, das alle 3 Sekunden das Reading "clock" mit der aktuellen Uhrzeit füllt.

test.doif:

Code Auswählen Erweitern

([+3])
({my ($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst) = localtime(time);;
  fhem("setreading test.doif clock $hour:$min:$sec");;})
Beim test.doif noch attr do always und attr notexist 0 hinzufügen.

Aus den Examples habe ich die index_empty.html angepasst (vgl. Anhang) und das Reading aus dem doif per Label-Widget in TabletUI eingeblendet. Dort wird die Uhrzeit aus dem Reading korrekt aktualisiert.

Danach habe ich die index_nav_footer.html aus den Examples genommen (vgl. Anhang) und eine content_sounds.html (vgl. Anhang) eingebunden. In content_sounds.html habe ich ebenfalls das Reading aus dem doif per Label-Widget eingebunden. Wenn ich die index_nav_footer.html lade und unten auf Sounds klicke, wird das Label unter Windows 10 mit Chrome, Firefox und Edge nicht aktualisiert.

Könnt ihr das bei euch nachvollziehen?

[Jojo11]

Hallo,

wenn es um das reine Anzeigen von Werten geht, muss ich sagen, dass mein FTUI seit Monaten sehr stabil läuft. Ich verwende ein Android-Tablet mit fully fullscreen Browser, welches nie den Bildschirm ausstellt. Temperatur und Uhrzeit werden sehr zuverlässig angezeigt. Mir ist noch nie eine Verzögerung aufgefallen.
Vielleicht schläft Dein Android ein. Um das zu verhindern, kannst Du bei neueren Versionen mal die Akku-Sparfunktionen abschalten. Alternativ kannst Du apps installieren, die einen wake-lock erzwingen.
https://developer.android.com/training/scheduling/wakelock.html

schöne Grüße
Jo

[setstate]

Ich verzweifle schon am DOIF

error
   
<pre>{my ($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst) = localtime(time); fhem("setreading test.doif clock $hour:$min:$sec");}: Unknown command {my, try help. Unknown command fhem("setreading, try help. Unknown command }, try help. </pre>

[DocCyber]

Ich arbeite seit Monaten am Aufbau einer Oberfläche mit FTUI.
Mittlerweile stelle ich aber fest, dass auch schon lange fertig gestellte Teile nicht mehr so funktionieren wie zuvor.

Daher auch erneut die Frage: Was sind die Bedingungen dafür, dass Events tatsächlich auch zu einer Aktualisierung der Anzeige in FTUI führen? Es muss doch eine Ursache für die Probleme geben.

Ich weiß aber nicht, wo ich mit der Suche anfangen soll.

[DocCyber]

Vielleicht schläft Dein Android ein.

Ich glaube nicht, dass das der Grund ist, weil....:
Ich habe Türsensoren. Wird die Tür geöffnet, spricht der Sensor an und der zuvor grüne Kringel auf dem Tablet wird rot - dauert vielleicht 2 Sekunden.
Klappt prima ... nur eben jetzt nicht mehr. Ohne dass ich etwas geändert habe.
Und ich habe keine Idee, woran das liegen kann.

[setstate]

Du könntest mal debug auf 5 setzen und dann in der Webconsole nachsehen, ob Events reinkommen und was damit passiert.

[DocCyber]

Du könntest mal debug auf 5 setzen und dann in der Webconsole nachsehen, ob Events reinkommen und was damit passiert.

Dank für den Hinweis. Damit habe ich zumindest mal einen Startpunkt für die Suche...

[DocCyber]

... ob Events reinkommen und was damit passiert.

hmmm - Soweit ich das beurteilen kann, kommt eben nichts an - jedenfalls nicht "freiwiliig", sondern erst beim manuellen Browser-Refresh.

Nachdem ich mal in den Code geschaut habe, verstehe ich es so, dass die longpoll-Funktion als Eventhandler für fhem-Ereignisse fungiert.
Daher macht es mich stutzig, dass das letztes Longpoll-Event schon etliche tausend Tage zurückliegen soll. 

[KaiK]

Das ist exakt die Differenz zw now und 1.1.1970 (Beginn der Unix Zeit).
D.h. longpoll wurde noch nicht aufgerufen in dem Moment deines Screenshots.

[KaiK]

PS: Shortpoll offenbsr jedoch 3 Minuten vorher..

[DocCyber]

... longpoll wurde noch nicht aufgerufen...

So interpretiere ich das auch.

Es ergeben sich 2 Fragen:
1) was ist eigentlich die Ursache für diese große Zeitspanne?
2) ist das Grund für für meine Problem?

[setstate]

Gibt es im Output ein

"Longpoll started"
oder
"Longpoll re-started"
?