Item update

[loeserman]

Hallo zusammen,
ich habe mehrere Tablets im Haus verteilt, die alle eine Gesamtübersicht anzeigen. Seit der Version 2.9 habe ich nun das Problem, dass die Updates langsamer sind. Soweit so gut und auch noch nicht so schlimm. Das ist immer dann besonders bemerkbar, wenn das Tablet mal inaktiv war und wieder angeht. Die Verbindung steht dann noch und die Seite wird dann auch nicht neu geladen aber es dauert eine längere Zeit, bis die Items wieder zum aktuellen Stand passen.

Zum Test habe ich mir vom SmarthomeNG mal einen Zeitstempel in ein Item schreiben lassen, welches sich jede Sekunde aktualisiert. Dieses habe ich dann in der Visu anzeigen lassen. Im Normalfall sieht man daher in der Visu, wie dieses dann Sekundenweise hochzählt. Dabei habe ich dann gesehen, dass wenn das Tablet aus war und wieder angeht, dieses Item anscheinend den gesamten Verlauf nachholen muss, den es verpasst hat. Ich denke, dass ist bei den anderen Icons auch so. Man kann erkennen, wie die Zeit hochrennt, bis es dann irgendwann in der aktuellen Ist Zeit angekommen ist. Danach läuft es dann im Sekundentakt weiter, wie erwartet.

Gibt es eine Möglichkeit, dass in einem solchen Fall nicht der gesamte Zeitverlauf nachgeladen wird, sondern einfach alle Items einmalig in der Visu aktualisiert werden?

Danke und Gruß
loeserman

[wvhn]

Welche Version verwendest Du genau?
Besteht das Problem weiter, wenn Du auf der Config-Seite die Option "Auto Reconnect" abschaltest? (das kannst Du auch pro Gerät individuell konfigurieren).

psilo hat das gleiche Problem vor einiger Zeit auf Gitter gepostet. Vielleicht gibt es da neue Erkenntnisse?

Gruß
Wolfram

[psilo]

wvhn ich hab das problem übrigens immer noch.kann aber damit leben

[NGem]

Grüße,

ich kann dies ebenfalls bestätigen.
Selbst Diagramme haben diesen Effekt. Was tatsächlich schon fast cool aussieht, wenn das Update sonst alle 5 Sek kommt, jetzt aber wie in Zeitraffer abläuft.

Ich betreibe smartVISU 2.9.2, allerdings nicht mit shng sondern fhem. Vielleicht hilft das ja bei der Eingrenzung.

[wvhn]

Ich kenne das mit meinen iGedöns Geräten nicht. Welche Plattform verwendet Ihr: Android?

Was passiert, wenn "auto reconnect" in der config abgeschaltet wird?

[NGem]

Ich kenne das mit meinen iGedöns Geräten nicht. Welche Plattform verwendet Ihr: Android?

Effekt habe ich auf Android. Auf Windows-Rechner nicht. Apple ist nicht im Haushalt vertreten.

Was passiert, wenn "auto reconnect" in der config abgeschaltet wird?

Ich nutze nicht shng, sondern fhem. Da gibt es die Funktion "auto reconnect" nicht. Vielleicht hilft das ja zur Abgrenzung.

[loeserman]

Hallo zusammen,
ich habe die folgende Version SmartVisu 2.9.2
Bei SmarthomeNG habe ich die Version 1.7.2.master (3828810e)

Meine Endgeräte sind alles Android Geräte. Allerdings kann ich das Verhalten auf meinem Surface auch nachvollziehen (Windows 10 mit Chrome).

Das Reconnect habe ich mal ausgeschaltet (geht aber nur global) bei den weiteren Einstellungen für Page und Gerät habe ich die Auswahl nicht. Hier steht Echtzeitdaten An/Aus. Ist das das gleiche wie Reconnect? Das habe ich auch mal deaktiviert. Hat aber leider nichts gebracht.

Leider ist das bei mir sehr störend. Wenn die Tablets immer erstmal die ganze Nacht nachladen, dann dauert das schon mal mehrere Minuten, bis der reale Zustand angezeigt wird. Und leider sieht man das auch nicht gleich, dass er eigentlich noch gar nicht aktuell ist.

Kann es auch damit zusammenhängen, dass ich eben ein Item jede Sekunde ändere und damit auch sehr viele Werte da sind. Normalerweise geht ja nur hier und da mal eine Lampe an. Auf der anderen Seite melden ja Strommessgeräte und Heizungsregler auch immer wieder mal Werte auf den Bus, die dann nachgeladen werden müssten.

Vielleicht kommen wir der Ursache ja noch auf die Schliche, da ich das in der Version 2.8 eigentlich nicht kannte. Oder ich habe das da nie bemerkt.

[loeserman]

Noch eine Kleinigkeit.
Die Echtzeitdaten in der Rubrik Gerät kann ich übrigens nicht ausschalten. Immer wenn ich es auswähle, dann den Slider auf Aus setze und dann speichere, dann ist es danach wieder an, wenn die Seite neu geladen wurde. Unter der Rubrik Seite 'xyz' geht es ohne Probleme.

Gruß
Christop

[Sipple]

Was passiert denn wenn du nach dem Reaktivieren der Tablets nicht wartest bis die Updates durch sind sondern manuell einen Reload anwirfst? Z.B. auf das smartVISU Symbol oben rechts drücken. Ist dann nach dem neuen Seitenaufbau sofort alles aktuell?

[wvhn]

smartVISU abonniert die items und Serien (Plots) beim Backend. Das Backend sendet dann jede Änderung eines items bzw. jeden neuen Datensatz eines Plots. Wenn beim Suspend bzw. "Doze"-Modus der Websocket nicht geschlossen wird, dann schreibt das Backend dies pflichtgetreu in den Puffer des Websockets und SV holt dies beim Wecken des Tablets brav alles ab.

Sinnvoller wäre es natürlich, den Websocket zu schließen und einfach beim Wecken die Daten neu anzufordern, indem die Websocket-Kommunikation neu gestartet wird. iOS/iPad OS und Android unterscheiden sich hier offenbar stark in der Vorgehensweise. Verzögerungen beim Wecken kann ich bei iOS auch bei größeren Datenmengen (Plots) nicht feststellen. Leider habe ich noch nicht die passende Literatur gefunden, um dies näher analysieren zu können. Hilfe ist also willkommen.

Helfen könnte es, in Android den Browser vom Doze-Modus auszuschließen. Bei fest eingebauten Tablets, die eh an einer Stromversorgung hängen, wäre das sicher vertretbar.

Gruß
Wolfram

[loeserman]

Also wenn ich die Seite neu lade, dann erhalte ich schon die aktuellen Werte. Aber der Seitenaufbau dauert natürlich eine Weile und dann werden auch noch kurz Werte nachgeladen aber eben nur ein paar Sekunden. Nach Deiner Erklärug denke ich wird der Websocket aufgebaut, bevor mit dem Laden der Seite fertig ist und die Werte werden dann eben noch geholt. Man sieht das an der Uhrzeit aus dem Item, welche dann noch schnell hochläuft.

Allerdings passiert bei mir nichts, wenn ich oben rechts auf das smartVISU Logo drücke. Sollte der dann wirklich die Seite neu laden? Also richtig neu laden?

Kann ich mit einem Skript oder so den Socket schließen und neu aufrufen? Dann würde ich das einfach mal probieren.

Gruß
Christoph

[wvhn]

Die Frage nach dem Skript in shNG müsste Msinn beantworten. Grundsätzlich wäre natürlich auch denkbar, dass der Websocket von shNG aus geschlossen wird, wenn eine gewisse Zeit keine Kommunikation stattfindet. Das sollte dann konfigurierbar sein, damit die Clients, die den Suspend-Modus besser im Griff haben, als Android, keine Nachteile erfahren.

Grundsätzlich bin ich der Meinung, dass man dies auf der Seite des Clients lösen sollte. Wenn der Browser einen Event triggern würde, bevor das Tablet in den Doze-Modus geht, könnte man den Websocket aktiv schließen. Hierzu habe ich bisher aber keine Literatur gefunden.

Gruß
Wolfram

[Msinn]

Das schließen und neu öffnen des Websockets müsste sinnvollerweise im Browser passieren.

In shng könnte man nur nach einer Zeit ohne Anfragen den Websocket schließen. Das würde aber evtl. auch Browser betreffen, die sich nicht schlafen gelegt haben und die dann einfach keine Updates mehr bekommen (was ein Fehler wäre).

Neu eröffnen müsste der aufwachende Browser die Wensocket Kommunikation sowieso. Dann könnte er auch gleich vorher die alte Websocket Kommunikation schließen.

[wvhn]

Ich denke, dass der Reconnect mit Android-Geräten in der heutigen Form gar nicht funktionieren kann. Wenn - was ich vermute - während des Doze-Modus der Websocket nicht geschlossen wird, dann ist beim Aufwachen noch io.socket.readyState=1. Der Reconnect Timer initialisiert den Websocket aber nur neu, wenn der Wert 3 ist (./lib./ base/base.js Zeile 103.).

Traut sich jemand, die Bedingung mal testweise rauszunehmen oder den Wert von 3 auf 1 zu setzen? Am besten kopiert man das ganze smartVISU-Verzeichnis, macht die Änderung in der Kopie und ruft diese nur mit dem Android-Gerät auf, auf dem der Test laufen soll. Ganz sauber ist das möglicherweise nicht. Besser fügt man vor Zeile 104 noch folgendes ein:

io.close();

In fhem funktioniert das leider nicht. Dort wird der Reconnect im Treiber selbst gemacht, aber auch nur, wenn festgestellt wird, dass der Websocket geschlossen wurde (./driver/io_fhem.js Zeile 323). Warum das überhaupt als Timer programmiert ist, erschließt sich mir (noch) nicht. Hier bräuchte ich definitiv Hilfe von einem fhem Anwender mit etwas Programmierkenntnissen und Zeit zum Testen.

Wenn der o.g. Test erfolgreich ist, sehe ich zwei Lösungsmöglichkeiten:

• jemand findet heraus, wie der Browser merkt, dass er längere Zeit offline war. Dann kann man auf dieses Signal definiert reagieren.
• Wir setzen einen Zeitstempel, der bei jeder Kommunikation überprüft wird. Ist dort eine einstellbare Zeit überschritten, wird der Websocket neu initialisiert.

Gruß
Wolfram

[loeserman]

Ich probiere das gern. Geht aber erst ab morgen abend.