Status Update GA erzwingen

[XueSheng]

Ich verwende die Cometvisu hauptsächlich auf Mobilgeräten (Android mit Chrome). Hierbei habe ich häufig das Problem, dass die angezeigten Werte in der CV nicht passen (z.B. Licht wird als "AN" angezeigt, obwohl bereits "AUS" ist).

Grundsätzlich habe ich die CV immer im Chrome geladen. Befindet sich das Gerät jedoch im Standby oder die Netzwerkverbindung ist zwischendurch weg, bekommt die CV offensichtlich nicht alle Statusänderungen mit. Wird das Gerät dann verwendet und Chrome geladen, sieht man zwar sofort die gesamte Visu, allerdings passen dann viele Werte nicht zum tatsächlichen Status. Abhilfe ist bislang die Visu neuzuladen (manchmal muss ich auch zweimal neuladen, bevor die Werte passen). Störend ist hierbei eigentlich nur die Ladezeit, bis man tatsächlich Zugriff auf den Bus hat.
Die Problematik ist meine ich auch bekannt und wurde auch schon in anderen Threads angesprochen (konnte ich jedoch auf Anhieb nicht finden).

Für mich stellt sich jedoch nun die Frage, ob es eine Möglichkeit gibt ein Update der Werte zu erzwingen? Ich würde dann z.B. einen Trigger ("Refresh") in der Visu einbauen, den ich dann mal eben drücken kann, anstatt die komplette Visu neuladen zu müssen.

Wie geht ihr mit dieser Problematik bei mobilen Geräten um?

[swiss]

Naja das Problem wird wohl sein, dass dein Browser auf dem Mobilgerät die Seite Cached. Irgend wann läuft aber sie Verbindung zum Server in ein Timeout. Erst durch den Reload wird eine neue Session gestartet und die Werte werden aktualisiert.

Da eine Lösung zu finden dürfte nicht ganz so einfach sein, da ja durch einen Reload immer die gesammte Seite neu geladen wird.

[XueSheng]

Das Problem ist soweit klar. Daher ja auch die Idee das Auslesen der Werte (manuell) zu erzwingen (ohne reload der Seite. Gibt es dazu eine Möglichkeit?

[Chris M.]

Man kann sicher ein Plugin schreiben, dass einen reinen Daten-Reload erzwingt. Kann ich mir mal am Wochenende ansehen.

Davon unabhängig wäre es natürlich sehr interessant hier über den Mechanismus, der zu veralteten Daten führt, mehr zu erfahren. Eigentlich sollte das nicht passieren können, da intern ein Watchdog mitläuft - allerdings braucht der natürlich einige Zeit (waren das 5 Minuten?) bis der merkt das etwas falsch läuft...

[XueSheng]

Das Problem mit veralteten Daten kommt bei mir wie gesagt nur auf Mobilgeräten vor (getestet mit Android 4.x und Chrome). Auch im Heimnetz mit stabilem WLAN. Die Geräte scheinen aber im Standby keine Änderungen mitzubekommen, obwohl das WLAN aktiv bleibt.

Ich meine es hieß mal der Watchdog würde auf 60 Sekunden eingestellt sein. Wobei mir selbst 30 Sekunden zu lange wären .

Das eigentliche Problem ist doch, dass auch Buttons in solchen Situationen nicht mehr funktionieren (bei getrennten GA für read/write). Ein "Reload" Button wäre natürlich nur ein Workaround.

Ich habe keine Ahnung wie der Watchdog funktioniert, aber wäre ein sehr kurzes Intervervall (z.B. 10 Sek.) denn problematisch?

[swiss]

Leider wird sich das Problem mit dem Browser kaum lösen lassen. Denn um Energie zu sparen werden im Standby diverse Applikationen wie z.B. auch der Browser einfach eingefrohren. Dies führt also zwangsläufig dazu, dass die Verbindung zum Backend unterbrochen wird und damit backend seitig in ein Timeout läuft. Ein erneuter Aufbau der Verbindung wird dann nur noch über einen Reload möglich sein...

Eventuell könnte man das Problem in der Andoid App lösen... Denn da könnte man beim reaktivieren des Mobilgerätes einfach die Werte nachladen lassen und damit die Session wieder aufbauen.

[Chris M.]

Das Problem mit veralteten Daten kommt bei mir wie gesagt nur auf Mobilgeräten vor (getestet mit Android 4.x und Chrome). Auch im Heimnetz mit stabilem WLAN. Die Geräte scheinen aber im Standby keine Änderungen mitzubekommen, obwohl das WLAN aktiv bleibt.

Ich meine es hieß mal der Watchdog würde auf 60 Sekunden eingestellt sein. Wobei mir selbst 30 Sekunden zu lange wären .
[...]

Ich habe keine Ahnung wie der Watchdog funktioniert, aber wäre ein sehr kurzes Intervervall (z.B. 10 Sek.) denn problematisch?

Das macht leider hier keinen Sinn:
Die Idee hinter dem COMET-Pattern ist, dass die Verbindung aufgebaut wird und so lange offen schläft, bis ein Datenpaket kommt. So kann in Echtzeit der Wert in der Visu dargestellt werden bei quasi keinem Ressourcen-Verbrauch.
Das Gegenteil ist Polling, da fragt der Client ununterbrochen beim Server nach Neuigkeiten nach - das macht extrem viel Kommunikation für quasi keinen Inhalt. Und wenn sich doch mal was beim Server ändert ist nach Murphy der Zyklus gerade rum und man darf bisschen warten bis dieser Status endlich bei der Visu angekommen ist.

Wenn man nun von der reinen Theorie zur Praxis geht, dann sieht man, dass man auch bei COMET ein Timeout braucht. Denn jede offene Verbindung bindet ein paar (wenige) Ressourcen auf dem Server. Und wenn der Client sich einfach beendet ohne zu verabschieden bleiben die Ressourcen bis in alle Ewigkeit reserviert...
=> Es gibt ein Timeout auf dem Server, dass nach einiger Zeit (waren, glaub ich, 60 Sekunden) die Verbindung beendet.
Direkt im Anschluss eröffnet der Client natürlich wieder eine neue Verbindung.
Außerdem - und das macht der Watchdog - überwacht sich der Client ob innerhalb einer gewissen Zeit (ich glaube das waren die 5 Minuten) eine Kommunikation stattgefunden hat, wenn nicht macht der Client ein Reset und lädt die Daten wieder von vorne.

Diese Zeiten kann man natürlich auch deutlich kürzer gestaltet - landet dann aber irgendwann beim Polling...

Die richtige Lösung (keine Ahnung ob und wie das geht) wäre dem Client beizubringen mit der Suspend-Situation umzugehen.
Beim Suspend werden ziemlich sicher keine JavaScript Timer mehr laufen (sonst würde der WatchDog das automatisch lösen) - die große Frage ist, ob man irgend etwas automatisch nach dem Resume laufen lassen kann...

Dies führt also zwangsläufig dazu, dass die Verbindung zum Backend unterbrochen wird und damit backend seitig in ein Timeout läuft. Ein erneuter Aufbau der Verbindung wird dann nur noch über einen Reload möglich sein...

Ein reiner Reload der Daten sollte schon reichen. (Außer Du willst auch noch Konfig-Änderungen automatisch mitbekommen...)

[Chris M.]

So, probier mal Revision 2230.

Das Widget heißt "reload" und ist dem Trigger angelehnt. Der Text im Button selbst kann per Parameter "value" gesetzt werden und mit den üblichen Methoden (mapping, styling) formatiert werden.

[MicHau]

Ich habe nur die Commit-Mail gesehen und kann es nicht in der IDE nachvollziehen, aber: XSD auch geändert??

[Chris M.]

Nö, das XSD ist noch alt - ich wollte das Widget erst mal testen lassen. (Ich habe das Problem nicht, dass das Widget lösen sollte...)

[MicHau]

Ich wollte gerade die XSD nachziehen, dabei bin ich darüber gestolpert, dass es ein solches "Reload"-Widget schon gibt:

  this.addCreator('reload', {
    create: function( element, path, flavour, type ) {
      var e = $(element);
      var addresses = self.makeAddressList(e, null);
      var updateFn = function(event, data) {
        var thisTransform = addresses[ event.type ][0];
        var value = templateEngine.transformDecode( thisTransform, data );

        if (value > 0) {
          window.location.reload(true);
        }
      };
      for (var addr in addresses) {
        // only when read flag is set
        if (addresses[addr][1] & 1) e.bind(addr, updateFn);
      }
    }
  });

Ein neuer Name muss her. Das neue Widget heißt jetzt "refresh" und die XSD ist auch angepasst.

[XueSheng]

So, probier mal Revision 2230.

Das Widget heißt "reload" und ist dem Trigger angelehnt. Der Text im Button selbst kann per Parameter "value" gesetzt werden und mit den üblichen Methoden (mapping, styling) formatiert werden.

Danke für das Update. Ich pflege das jetzt mal in meine Visu ein und teste das ein paar Tage. Gebe dann nochmal eine Rückmeldung!

[Chris M.]

Ich wollte gerade die XSD nachziehen, dabei bin ich darüber gestolpert, dass es ein solches "Reload"-Widget schon gibt:

Argh! Wer macht den so was?!? Ein Widget nicht in seiner eigenen Datei - das findet doch niemand. (Ich hoffe mal das ich das nicht selbst war...)

Ich hab's gleich mal bereinigt.

Ein neuer Name muss her. Das neue Widget heißt jetzt "refresh" und die XSD ist auch angepasst.

Der Name ist auch gut. Danke!

[Dirk42]

Hmm... und was macht dann nun das "reload"? Das schaut auch verdächtig nach irgendwas mit Neuladen der Seite aus...

Danke für Eure ganze Arbeit & Tüftelei! Noch ist meine CometVisu in der Bastelphase, es macht aber schon echt Spaß Licht & co per WLAN und über VPN kontrollieren und ändern zu können!

[swiss]

Hmmm.... Wenn ich das richtig gelesen habe ist das ein verstecktes Widget in der common.js das die Visu über eine GA gesteuert neu lädt. Ich meine mich dunkel daran zu erinnern, dass dies nicht von Chris sondern von Julian oder wars Thorsten?... kam, weil er nach einer Configänderung nicht immer alle Panel und Geräte von Hand reloaden wollte. Es ist also quasi ein "Fern Reload"

EDIT: Nö habs gefunden. War ein Input von Carsten (netsrac) implementiert von MicHau vor knap einem Jahr
-> https://knx-user-forum.de/cometvisu/30289-force-reload-ga.html