Verhalten von Colspan am IPhone und Ladeverhalten (0.9.2 und rev2742)

[Chris M.]

Hab jetzt auch am Handy nochmal mit Reload im QF probiert => 2-spaltig! Somit ist das der Grund!

Heißt das, dass Dein Thema gelöst ist?

Eine Frage hab ich noch:
Wenn ich lt. Doku "svn update ." im Verzeichnis /visu_git/ aufrufe, bekomme ich nur nach einigen Sekunden die Meldung "Revision 2742", es werden aber keine neue Daten geladen.
Ist 2742 wirklich die letzte Version oder mache ich hier was falsch, um den Letztstand von Github zu holen?

Da kann ich leider nicht weiterhelfen, da ich Git direkt nutze(*). Wie nun die Git-Versionen auf die SVN Versionsnummer übersetzt werden weiß ich nicht.

--
(*): Leider läuft Git für GitHub nicht auf dem WireGate da es meines Wissens nach keinen geeigneten Backport gibt. Ich habe bei mir beim Entwickeln das WireGate Dateisystem per sshfs auf meinem Arbeitsrechner (Linux bzw. Kubuntu) mit eingebunden und nutze nun das lokale Git auf dem entfernten WireGate Verzeichnis.
Ob ähnliches auch mit Windows und MacOS Rechnern möglich ist, kann ich nicht sagen

[Robert_Mini]

Ich vermute dass das Problem gelöst ist. Ist der Pull request schon durch, dann teste ich nochmal mit der aktuellen git Version.

2742 habe ich vor mehreren Monaten installiert, der Befehl wie in der CV Doku beschrieben (svn update.), klappt so aber nicht.

Robert

[Chris M.]

Ja, Pull-Request https://github.com/CometVisu/CometVi...a9d78a37a7f3f6 ist gemerrged, Issue https://github.com/CometVisu/CometVisu/issues/369 ist geschlossen

[Robert_Mini]

Gerade nochmal getestet: das Umschalten zwischen HQ / QF funktioniert nun bei allen meinen Devices (Andriod 4.4 und IPhone5s mit iOS10.2) unter Safari, Chrome und Firefox!
Wobei das löschen des Caches im Safari doch etwas tricky ist, denn hier hat es das generelle löschen aller Website Daten gereich, das entfernen der Daten von 192.168.1.101 (mein WG mit der CV) reicht nicht, forceReload auch nicht!

Nachtrag: Ich würde für das Release eigentlich noch "maxScreenWidthColspanS: 480" empfehlen, dass passt für Hochformat für alle Iphones.
Ältere Iphones habe im QF 480 Viewportsize, dass sollte aus meiner Sicht schon in colspan-m fallen.

lg und Danke für eure Geduld!!
Robert

[Chris M.]

Die Seite https://material.io/guidelines/layou...ui-breakpoints empfiehlt, dass 480 die letzte Größe für small sein sollte.

Um einen Pixel rumzustreiten macht sicher keinen Sinn. Die Frage ist aber: wie kommen wir zu optimalen Werten?

Gefühlt sind 480 Pixel schon noch sehr wenig... Aber eigentlich ist das Gefühl egal, es sollte halt mit den gängigen Geräten gut aussehen.

[Robert_Mini]

Das Laden mit Cache funktioniert absolut performant, aber leider in meinem Fall nicht bei jedem reload (und eigentlich unabhängig von enableCache=true/false/invalid) ==> es werden dann keine Werte des GAs angezeigt, aber rsslog und Diagramme sehr wohl.

Mein Gefühl sagt mir im Moment, dass dies dann passiert,wenn man reload drückt, bevor der vorherige Aufruf fertig abgearbeitet wurde (zB rss, diagramme, Bilder der nicht sichtbaren Seiten). Reproduzierbar ist das Verhalten leider nicht so recht.
Hab nun auch ein Video davon auf meine Dropbox gestellt, schau's dir mal an:

https://www.dropbox.com/sh/lldzqubmu...8BOy0zcLa?dl=0

Video_Reload.avi:
1) Initial Load (kurz vor Start der Aufzeichnung => keine GA wie im Video zu sehen.
2) 3x Reload
3) Beim 4. Reload kommen die Stati sofort
4) 6x Reload ohne dass die GA's angezeigt werden
5) beim 7. Reload kommen die Stati wieder sofort.

Ähnliches Verhalten mit enableCache=false => Video_Reload_OhneCache.avi

Vielleicht komme ich ein wenig ungeduldig rüber, aber das Problem ist derzeit, dass in der aktuellen Git-Version die GA's entweder sofort kommen oder ansonsten auch nicht nach 1 Minute.
In meiner alten svn-Version lädt zwar die Visu die GA viel langsamer, dafür aber immer => Video_Reload_alt.avi

Hab jetzt noch ein Video mit der Konsole gemacht, mir sagt es nicht sehr viel, außer dass eben manchmal rsslog.php sehr lange braucht. Allerdings in den Fällen wo die GA's sofort kommen, werden die GA vor dem rsslog geladen. Interessant bei diesem Video ist, dass beim ersten Laden tatsächlich nach ca. 1min (im Video 1:09) die Stati der GA's noch kommen! Der nächste Reload klappt sofort, dann wieder einer nicht, dann wieder sofort...

lg Robert

PS: mein URL mit \visu_git\ ist aktuell und hat schon den Fix für den Navbar drinnen, visu_svn_last ist aus einer Zeit, wo noch mit sourceforge gearbeitet wurde.

[peuter]

Das Laden der Wert hat mit dem Caching auch nichts zu tun, hätte mich gewundert wenn es da einen Zusammenhang gegeben hätte. Die Videos erleuchten die Situation auch nicht besonders. In der Console kann man sehen, dass der Read-Request. der die Werte abfragt da ist. Wenn dieser keine Antwort erhält ist das normalerweise die Schuld des Backends. Aber dagegen spricht, dass es mit der alten Version funktioniert.

Was Du vielleicht nochmal versuchen könntest, wäre das Ganze mal im Chrome zu versuchen, weil da die Console vielleicht aufschlussreicher ist. Ööffnen mit F12 und dann auf Network klicken, dann sieht man alle Requests und interessieren aber nur die XHR-Requests (da kann man nach filtern). Da sollte zunächst ein 'cgi-bin/l' Request zu sehen sein (login) und danach diverse 'cgi-bin/r' (read). Der erste read-request muss hier das Problem sein, denn dieser fragt alle Werte vom Backend ab, die darauf folgenden nur noch Änderungen. Wenn Du mal 1-2 Minuten wartest, dann wird dieser Read-Request vom Watchdog gekillt, wenn das Backend noch keine Antwort geliefert hat. Das sollte in der Console erkennbar sein (sollte irgendwas von abort stehen und rot sein). Du kannst den Read-Request auch anklicken und dann genau sehen, wie die Anfrage der ComitVisu an das Backend aussieht und was dieses geantwortet hat.
Wenn du das mal hier posten kannst, bringt das und das vielleicht etwas weiter.

[Robert_Mini]

Hab Chrome installiert und nochmal 2 Videos hochgeladen: Link
So richtig schlau werde ich aber daraus nicht, vielleicht erkennt man im Video was?
Offensichtlich wird gelegentlich die Kommunikation zum Backend nicht richtig aufgebaut.

lg Robert

[peuter]

Videos helfen hier nicht, da kann ich kaum was drauf erkennen. Außerdem hängt das irgendwie mit dem Backend zusammen und da ich openHAB als Backend benutze werde ich das Problem wohl niemals nachstellen und somit auch nicht fixen können.

[Robert_Mini]

Ok. Schade aber verständlich.
Vll. hat Chris dazu noch eine Idee.
Ansonsten warte ich mal auf das nächste Release, ob dieses Verhalten dort auch so existiert.

Weiters kann ich mit einer kleinen Testconfig probieren.

Ich hab auch noch das Problem, dass mein strftime nicht mehr angezeigt wird und meine Bilder eine andere Größe als früher haben...

lg
Robert

[Chris M.]

Die spannende Frage ist, was denn die "r" Requests machen, also wann die mit "t=0" oder "i=<...>" geschickt werden und was das Backend dabei zurück meldet.

In diesem Kontext gibt es noch ein offenes Issue: https://github.com/CometVisu/CometVisu/issues/250 - leider kann ich es nicht nachstellen und somit momentan nicht weiter debuggen

=> Bitte noch ein paar mal laden und explizit auf das Timing der "l" und v.a. "r" Requests achten und nochmal berichten

strftimer: peuter kann es sein, dass das Plugin mit dem Caching (noch) inkompatibel ist? Bei'm Blick auf den Code sieht's verdächtig aus...

Bilder: Beispiel-Config?

[Robert_Mini]

Strftime funktioniert in der Demo (etwas versteckt).
ich habe bei mir eine class im Aufruf (Bodo's Design), damit klappt's dann nicht.

[peuter]

Also bei mir funktionierte Strftime in der Demo nicht, wenn der Cache benutzt wurde. Nach kurzem Blick in den Code hätte das auch niemals funktionieren können. Fix gibts hier: https://github.com/CometVisu/CometVisu/pull/483

[Robert_Mini]

Hab grad den issue 250 gelesen, XueSheng hat offensichtlich das gleiche Phänomen, fix offenbar mit zusätzlichem Index im rsslog . Ich schau mir in jedem Fall in den nächsten Tagen mal mein rsslog.php an und tausche ggf. gegen das aktuelle (hoffentlich mit dem zusätzlichen Index??).

Danke und lg
Robert

[Chris M.]

Kann ich das Thema hier als gelöst ansehen - oder zumindest las dass es kein Blocker für die 0.10.0 ist?