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?
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.
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.
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:
([+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?
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 (https://developer.android.com/training/scheduling/wakelock.html)
schöne Grüße
Jo
Ich verzweifle schon am DOIF
Zitat
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>
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.
Zitat von: Jojo11 am 19 November 2016, 19:25:49
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.
Du könntest mal debug auf 5 setzen und dann in der Webconsole nachsehen, ob Events reinkommen und was damit passiert.
Zitat von: setstate am 20 November 2016, 12:19:58
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...
Zitat von: setstate am 20 November 2016, 12:19:58
... 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. :o ???
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.
PS: Shortpoll offenbsr jedoch 3 Minuten vorher..
Zitat von: KaiK am 20 November 2016, 15:40:36
... 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?
Gibt es im Output ein
"Longpoll started"
oder
"Longpoll re-started"
?
Neben der Webconsole gibt es noch Netzwerkanalyse. Findest du den Longpoll Aufruf?
http://fhemserver.local:8083/fhem/?XHR=1&inform=type=status;filter=;fmt=JSON&_=1479658267650
Zitat von: setstate am 20 November 2016, 17:20:13
Neben der Webconsole gibt es noch Netzwerkanalyse. Findest du den Longpoll Aufruf?
Nein (s. Screenshot 974)
Der genannte Link
http://fhemserver.local:8083/fhem/?XHR=1&inform=type=status;filter=;fmt=JSON&_=1479658267650 läuft ins Leere, auch wenn ich
fhemserver.local:8083 durch meine lokale Adresse ersetzte.
[/quote]
Zitat
Gibt es im Output ein
"Longpoll started"
oder
"Longpoll re-started"
?
ja, mehrfach. Ich habe jetzt auch eine longpoll-Fehlermeldung entdeckt (s. Screenshot 975).
(Die kann ich aber nicht mit dem Test-Widget (s. Screenshot 972) in Verbindung bringen und weiß also nicht, ob das etwas mit dem Problem zu tun hat.)
Bei dem Test (@setstate: müsste dir bekannt vorkommen ;)) schalte ich zwischen 4 Optionen um.
Wenn ich den Multiswitch-Dummy im FHEM-Frontend umschalte, sollte das umgehend im FTUI (rechtes Fenster) zu sehen sein.
Das Setzen eines neuen Wertes im FHEM-Frontend sollte m.E. auch in der Konsole des FTUI Fensters irgendeine Reaktion auslösen, und genau das passiert nicht - zumindest sehe ich nichts. Und wie gesagt: Lediglich nach manuellem Refresh ist alles, wie es sein soll. Dann kommt auch wieder die gewohnte Meldung
Longpoll started, aber das ist ja normal. (s.Screenshot 976)
Ich wollte sehen, ob der Filter Parameter bei dir gesetzt ist. Entweder die einzelnen Devices oder .* muss dort gesetzt sein. Leer, wie in meinem Beispiel, geht es nicht. Du kannst aber deinen Aufruf kopieren und in einem neuen Browsertab aufrufen.
Kannst du bei dem Fehler bitte mal den Stack Trace aufklappen, für mehr Details.
In der Netzwerkanalyse kann man auch auf den Aufruf klicken und in einem anderen Fenster sollte man den Response vom Server sehen.
Zitat von: setstate am 20 November 2016, 19:56:42
Kannst du bei dem Fehler bitte mal den Stack Trace aufklappen, für mehr Details.
Ich hatte zwischendurch den Rechner ausgeschaltet; leider kommt der Fehler jetzt nicht mehr - vielleicht NOCH nicht.
Mir ist aber noch aufgefallen, dass ein Aufruf offenbar fehlgeschlagen ist; da gibt es keinen grünen Punkt .
Bei den zugehörigen Kopfzeilen ist u.a. auch
multiswitch genannt, also der Name meines Dummys im Test.
s. hierzu zwei Screenshots.
(Leider habe ich die Entwicklerwerkzeuge bislang noch nicht benutzt und kenne mich damit nicht aus.)
noch ein Nachtrag:
Die Aktualisierung im FTUI erfolgt tatsächlich auch noch automatisch, aber erst exakt 10 Minuten nach einer Änderung im FHEM-UI. (shortpoll-Intervall ist aber 900 s, also 15 Minuten)
Ich habe mal einen Snippet Tester zusammen gebaut. Damit kannst du einzelne Teile deiner Seite antesten.
Links HTML Code (Widgets oder Widget Gruppen), nach Init drücken erscheint rechts das Widget. Unten ist der Console.log Output zu sehen.
Wenn im FHEMWEB dann was drückst, solltest du die Änderung hier sehen inkl. Logging.
www/tablet/ftui_snippet_tester.html
So kannst du checken, welcher Teil deiner Seiten den Ausfall von Longpoll verursachen.
Zitat von: setstate am 21 November 2016, 08:23:28
www/tablet/ftui_snippet_tester.html
Vielen Dank! Das hört sich sehr gut und Erfolg versprechend an.
Wo finde ich das File?
Muss ich es irgendwo herunterladen oder hast du evtl vergessen, die Datei hier anzuhängen?
Bei github unter www/tablet/ftui_snippet_tester.html
Kommt auch mit einem Update mit.
Danke! :)
Das Update mit
update all https://raw.githubusercontent.com/knowthelist/fhem-tablet-ui/master/controls_fhemtabletui.txt
führt hier leider zu einem Fehler:
2016.11.21 09:26:43 1 : RMDIR: ./restoreDir/2016-06-22
2016.11.21 09:26:44 1 : UPD www/tablet/css/fhem-tablet-ui.css
2016.11.21 09:26:44 1 : Got 33342 bytes for www/tablet/css/fhem-tablet-ui.css, expected 33187
2016.11.21 09:26:44 1 : aborting.
Ich habe mir den kurzen HTML-Code manuell von Github geholt und probiere es jetzt mal aus.
Jetzt habe ich die ersten Ergebnisse mit dem Snippet-Tester.
Leider bringt mich das noch nicht weiter, denn ich weiß nicht mehr als das, was gestern schon zu vermuten war: Aus irgendeinem Grund funktioniert Longpoll nicht!!
Änderungen im FHEM-UI werden nicht weitergegeben, erst der Shortpoll (!!) aktiviert das FTUI, s. Logfile (mit ein paar ### Kommentaren ### ).
Übrigens wird das Array {"modules":[]} erst gefüllt, wenn man Init das 2. Mal anklickt.
hmmm...
Wie soll ich prüfen, warum am FTUI keine "Longpoll-Messages" ankommen, wenn das Tool genau dort zum Einsatz kommt, wo eben nichts ankommt?
Vielleicht mache ich hier einen Denkfehler . . . Wenn das der Fall ist, dann kläre mich bitte jemand auf.
Ich habe auch schon daran gedacht, FHEM und FTUI komplett neu zu installieren.
Aber bei der jetzigen "Diagnose" stellt sich die Frage, ob das überhaupt etwas nutzen kann.
Das kriegen wir schon hin ...
Schicke mir nochmal ein neues log.txt vom snippet_tester
Aber bitte:
- frisches Update ziehen
- nur einmal init drücken
- gleich (nach dem Longpoll start) im FHEMWEB das Device schalten, damit ein Event gesendet wird
Das schaue ich mir dann an und überlege, wo wir evtl. noch mehr debug outputs brauchen.
Zitat von: setstate am 22 November 2016, 18:58:15
Das kriegen wir schon hin
dein Optimismus lässt mich wieder hoffen. :)
Zitat
- frisches Update ziehen
Beim letzten Versuch vor zwei Tagen, ein frisches FTUI zu ziehen, bekam ich einen
abort-Fehler....
Zitat von: setstate am 22 November 2016, 18:58:15
Schicke mir nochmal ein neues log.txt vom snippet_tester
s. Anhang
Ich habe es dann nochmals mit einem noch einfacheren Widget wiederholt...
<div data-type="symbol"
data-device="testSymbol"
data-states='["red", "green"]'
data-colors='["red", "green"]'
data-icons='["fa-circle-o", "fa-circle"]'>
</div>
... aber am Ergebnis ändert sich erwartungsgemäß nichts.
Ein Update versuche ich JETZT ...
Hallo zusammen,
ich kann das Problem wie folgt zuverlässig reproduzieren (habe heute Abend ein update durchgeführt):
1. In FHEM einen Dummy mit dem Namen Taster2 anlegen:
define taster2 dummy
2. Aus Github das Beispiel https://github.com/knowthelist/fhem-tablet-ui/blob/master/examples/mobil/index_nav_footer.html (EDIT: Link korrigiert) herunterladen.
3. Aus Github das Beispiel content_sounds.html herunterladen (https://github.com/knowthelist/fhem-tablet-ui/blob/master/examples/subpages/content_sounds.html) und die erste section austauschen, dass es dann so aussieht:
<!DOCTYPE html>
<html>
<head></head>
<body>
<div class="page" id="content4">
<section>
<div data-type="switch" data-device="taster2" data-get-off="!on" data-icon="fa-home" data-get-on="Home"></div>
<div data-type="switch" data-device="taster2" data-get-off="!on" data-icon="fa-bed" data-get-on="Sleep"></div>
<div data-type="switch" data-device="taster2" data-get-off="!on" data-icon="fa-car" data-get-on="Away"></div>
<div data-type="switch" data-device="taster2" data-get-off="!on" data-icon="fa-suitcase" data-get-on="Holiday"></div>
</section>
<section>
<div class="large col-1-3 left-align">Wohnraum</div>
<div data-type="select" data-device="AvReceiver" data-list="inputs" data-get="input" data-set="input" class="col-1-3"></div>
<div data-type="switch" data-device="RadioAtTablet" data-icon="fa-music" class="col-1-3"></div>
</section>
<section>
<div class="large col-1-3 left-align">Volume</div>
<div data-type="slider" data-device='AvReceiver' data-get='volume' data-set='volume' data-max="60" data-width="150" class="col-2-3 horizontal value" ></div>
</section>
<section>
<div class="large col-1-3 left-align">Radio</div>
<div class="col-2-3 right-align">
<div data-type="push" data-device="WebRadio" data-icon="fa-step-backward" data-set-on="Prev" class="inline" ></div>
<div data-type="label" data-device="WebRadio" class="inline">radio</div>
<div data-type="push" data-device="WebRadio" data-icon="fa-step-forward" data-set-on="Next" class="inline" ></div>
</div>
</section>
</div>
</body>
</html>
4. http://server.name/fhem/ftui/index_nav_footer.html laden
5. Auf den Sound-Button unten klicken
6. Die Switches werden nicht aktualisiert.
Leider bekomme ich es nicht hin, das ganze mit dem Logging aus dem snippet_tester zu verbinden.
Der Fehler tritt nicht mehr auf, wenn ich aus index_nav_footer.html den <nav>...</nav> Teil lösche.
... und ich bin jetzt endgültig im Krisenmodus! :'(
Ich habe
1) einen brandneuen RasPi-3 ausgepackt
2) Jessie Lite installiert und frisch aktualisiert
3) FHEM installiert und frisch aktualisiert
4) die (ursprüngliche) fhem.cfg wieder installiert
5) als index.html den snippet-tester verwendet
und erhalte dasselbe Resultat wie zuvor!!!
Wie kann das sein?
Ich hatte noch die Hoffnung, dass es daran liegen könnte, dass FHEM-UI und Tablet-UI auf dem selben Port laufen, aber das Prolem besteht auch bei unterschiedlichen WEB-Ports.
Verzweiflung !!!!!!!
Ich glaube ich habe die Ursache.
für dieses Problem hier: https://forum.fhem.de/index.php/topic,59397.0.html
habe ich damals einen longPoll Filter eingebaut. Das macht aber keinen Sinn, da sich die benutzten Devices auch ändern und diese neuen dann nicht abgefragt werden.
Bitte teste mal diese Version hier, wo ich das wieder ausgebaut habe. Den Filter muss man das statisch im HTML angeben. Zum Beispiel könnte man alle nötigen Devices in einen speziellen FTUI-Room legen und diesen dann als Filter angeben.
Hallo,
das sieht gut aus, zumindest funktioniert jetzt bei mir das Beispiel mit
index_nav_footer.html (siehe 3 Posts weiter oben) :)
Zitat von: setstate am 23 November 2016, 07:12:30
Ich glaube ich habe die Ursache.
Hallo setstate,
zunächst gebührt dir nochmals viel, viel Dank für all deine Bemühungen!
Jetzt habe ich zwei Informationen:
1)
die Variante von
fhem-table-ui.js hat bei mir keine Änderungen gebracht.
2)
Je nachdem, wo FHEM-UI bzw FTUI läuft, funktioniert es! Allerdings nur in einer Art
One-Way Kommunikation.
Ich möchte den "Versuchsaufbau" bzw die Varianten kurz erklären.
a) 2 x Desktop:
Ich öffne (auf meinem Desktop-Rechner) zwei Browserfenster. In einem läuft FHEM-UI, im anderen der Snippet-Tester unter FTUI.
Snippet-Tester starten, dann im FHEM-UI einen neuen Wert setzen und ... warten. Aktualisierung erst nach Shortpoll, also nach 15 Minuten.
b) 1 x Desktop, 1 x Tablet
Auf dem Desktoprechner läuft der Snippet-Tester unter FTUI, auf dem Tablet läuft das FHEM-UI.
[Ich habe diese Variante auch deshalb gewählt, weil ich nur auf dem Desktoprechner die Entwicklertools verwenden kann.]
Ergebnis wie gehabt.
c) 1 x Tablet, 1 x Desktop
Auf dem Desktoprechner läuft jetzt FHEM-UI, auf dem Tablet läuft der Snippet-Tester unter FTUI.
Diese Variante funktioniert - wieder!!
Eigentlich könnte man nun zufrieden sein, wenn nicht auch die Variante a) zuvor auch schon funktioniert hätte. Zu Test- und Entwicklungszwecken ist das nämlich sehr nützlich.
Aber wir sind nun
einen Schritt weiter.
(Es ist übrigens generell unerheblich, ob die beiden UIs auf demselben oder unterschiedlichen Ports aufgerufen wurden.
Auch eine Firewall auf dem Desktop spielt keine Rolle.)
Bei mir blockierte ein fehlerhafter pagebutton das Frontend.
Es fehlte die data-url Angabe.