Status Update GA erzwingen

[XueSheng]

Schau mal in die Antwort des Requests selbst ob der wirklich leer ist. Und/oder schau mal auf das Ende der Request-URL, hier sollte sich der Wert für "i" ändern.

Die Antworten der ersten Requests sind leer! Die erste Antwort hat daher auch 8,2KB (siehe vorherigen Screenshot).
Bei den ersten Anfragen steht am Ende t=0. Erst nach der ersten 8,2KB Antwort kommen dann Requests mit i=Wert.
Also doch nicht normal?

[XueSheng]

Heute wieder das gleiche Szenario. Nach Hause gekommen, jedoch keine aktuellen Werte in der Visu (neue Werte wurden angezeigt, aber die bestehenden waren falsch). Habe dann den Debug über Chrome gestartet. In der Netzwerkübersicht konnte ich sehen, dass die Requests abgearbeitet werden. Ein Refresh oder auch ein "templateEngine.visu.restart();" haben den aktuellen Request abgebrochen und einen neuen ausgelöst. Änderte aber nichts daran, dass die bestehenden Werte der Visu veraltet/falsch waren.
Ein Reload der Seite zeigte das bereits beschriebene Verhalten, dass mehrfach Request mit t=0 rausgeschickt werden (leere Antwort). Bis dann die erste Rückmeldung kommt und das "i=N" gesetzt wird. Nach einem Reload funktioniert dann wieder alles.

Beim ursprünglichen Verbinden mit dem Android Gerät war folgendes in der Console zu sehen:

Document was loaded from Application Cache with manifest http://192.168.X.XXX/visu_dev/cometvisu.appcache
Application Cache Checking event
Application Cache NoUpdate event
MIT Touch Support
Failed to load resource: net::ERR_TIMED_OUT
Failed to load resource: net::ERR_TIMED_OUT
C: #rss_id_1_3_0, Error: , Feed: /rsslog.php?f=security,wiregate&limit=24&j
Failed to load resource: net::ERR_CONNECTION_TIMED_OUT
C: #rss_id_1_3_0, Error: , Feed: /rsslog.php?f=security,wiregate&limit=24&j
Failed to load resource: net::ERR_CONNECTION_TIMED_OUT
C: #rss_id_1_3_0, Error: , Feed: /rsslog.php?f=security,wiregate&limit=24&j
Failed to load resource: net::ERR_CONNECTION_TIMED_OUT
Failed to load resource: net::ERR_CONNECTION_TIMED_OUT
C: #rss_id_1_3_0, Error: , Feed: /rsslog.php?f=security,wiregate&limit=24&j
Failed to load resource: net::ERR_CONNECTION_TIMED_OUT
C: #rss_id_1_3_0, Error: , Feed: /rsslog.php?f=security,wiregate&limit=24&j
Failed to load resource: net::ERR_CONNECTION_TIMED_OUT
C: #rss_id_1_3_0, Error: , Feed: /rsslog.php?f=security,wiregate&limit=24&j
Failed to load resource: net::ERR_CONNECTION_TIMED_OUT
Failed to load resource: net::ERR_CONNECTION_TIMED_OUT
C: #rss_id_1_3_0, Error: , Feed: /rsslog.php?f=security,wiregate&limit=24&j
Failed to load resource: net::ERR_CONNECTION_TIMED_OUT
Failed to load resource: net::ERR_CONNECTION_TIMED_OUT
C: #rss_id_1_3_0, Error: , Feed: /rsslog.php?f=security,wiregate&limit=24&j
Failed to load resource: net::ERR_CONNECTION_TIMED_OUT
C: #rss_id_1_3_0, Error: , Feed: /rsslog.php?f=security,wiregate&limit=24&j
Failed to load resource: net::ERR_CONNECTION_TIMED_OUT
C: #rss_id_1_3_0, Error: , Feed: /rsslog.php?f=security,wiregate&limit=24&j

Chris, kannst Du damit etwas anfangen?

[Chris M.]

Die Antworten der ersten Requests sind leer! Die erste Antwort hat daher auch 8,2KB (siehe vorherigen Screenshot).
Bei den ersten Anfragen steht am Ende t=0. Erst nach der ersten 8,2KB Antwort kommen dann Requests mit i=Wert.
Also doch nicht normal?

Das liegt dann am Backend - die CV selbst macht das dann richtig. Aber wieso?!?
Du nutzt das eibd cgi-bin und nicht OH als Backend, oder?

Heute wieder das gleiche Szenario. Nach Hause gekommen, jedoch keine aktuellen Werte in der Visu (neue Werte wurden angezeigt, aber die bestehenden waren falsch). Habe dann den Debug über Chrome gestartet. In der Netzwerkübersicht konnte ich sehen, dass die Requests abgearbeitet werden. Ein Refresh oder auch ein "templateEngine.visu.restart();" haben den aktuellen Request abgebrochen und einen neuen ausgelöst. Änderte aber nichts daran, dass die bestehenden Werte der Visu veraltet/falsch waren.
Ein Reload der Seite zeigte das bereits beschriebene Verhalten, dass mehrfach Request mit t=0 rausgeschickt werden (leere Antwort). Bis dann die erste Rückmeldung kommt und das "i=N" gesetzt wird. Nach einem Reload funktioniert dann wieder alles.

Das klingt für mich nach einem Android-Problem. Irgendwie scheint der Browser für sich gemerkt zu haben, dass das Netzwerk weg ist und beharrt darauf. Daher die "net::ERR_CONNECTION_TIMED_OUT" Meldungen. Und beim Reload der Browser-Seite versucht er es wieder und dann geht es.

Sollte das der Grund sein - und wir nicht herausfinden wie man das besser löst - könnten wir auch ein Widget bauen, dass die Web-Seite neu laden lässt...

[XueSheng]

Du nutzt das eibd cgi-bin und nicht OH als Backend, oder?

Ich nutze die Standard wiregate Installation, also eibd cgi-bin!

Sollte das der Grund sein - und wir nicht herausfinden wie man das besser löst - könnten wir auch ein Widget bauen, dass die Web-Seite neu laden lässt...

Mit "neu laden" meinst Du den vollen Reload "F5"? Oder das komplette Neuladen der Telegramme, also Request mit "t=0"?

[Chris M.]

Ich meine das "F5", da meine Vermutung ist, dass der Browser nicht mitbekommt, dass er (wieder) eine Verbindung aufbauen kann.

Ich müsste beim Refresh nochmal nachschauen, denke aber, dass der jetzt schon t=0 verschickt.

[XueSheng]

Ich müsste beim Refresh nochmal nachschauen, denke aber, dass der jetzt schon t=0 verschickt.

Wenn ich den Refresh auslöse, wird der aktuelle Request abgebrochen und es wird einer neuer mit "i=N" ausgelöst. Ich konnte keinen neuen Request mit t=0 finden!

[Chris M.]

OK, das macht nur bedingt Sinn. Bzw. ein i=0 braucht zwar mehr Ressourcen - aber die können wir uns zu diesem Zeitpunkt schon leisten.
=> Ich schau mir das mal an - aber mach sicherheitshalber mal ein Issue auf, damit das nicht verloren geht

[XueSheng]

Zwei Issues erstellt: https://github.com/CometVisu/CometVisu/issues/249 https://github.com/CometVisu/CometVisu/issues/250

[itarch]

Hallo kann es sein, dass nun der default browser (neulich ein update auf ver 4.0.10-53 erhalten) im lollipop immer ein art force reload macht nach langen suspend zeiten? Zumindest habe ich derartiges beobachtet. Kann es aber zum aktuellen Zeitpunkt nicht 100% bestätigen. bg

[Chris M.]

Hast Du nur das Gerät aktuallisiert oder evtl. die CometVisu-Version? Insb. dort auf die neueste Git-Version?

[itarch]

Nein kein CV Update Nur den Standard Browser vom Smartphone. Neu CV Version... mal schauen ob ich die finde ... hab mich schon mal hier als git-dau ge-outed ... Wie auch immer seitdem die neue browser version - wie oben beschrieben - installiert ist scheinen wohl die statie auch nach langen inactive phasen aktualisiert zu werden. Ich nutze den Standard Browser nur für die Visu. Diese ist auch als Standard Seite eingetragen. D.h immer wenn ich den Browser starte (nicht das Öffnen aus der Taskleiste) kommen erst die drei Punkte bevor die CV im Browser aufgebaut wird.

[Chris M.]

Nun, keine Ahnung was sich am Browser geändert hat - aber eigentlich sollte das Verhalten gleich geblieben sein.

Bei der Git-Version von vor dem Universal Client (als das, was auch in den 0.9.x Releases drinnen ist) zum aktuellsten Git hat sich jedoch eben genau der Client geändert. Hier wäre ein anderes Verhalten möglich - wenn auch erst mal nicht zwingend gewollt.