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

[Robert_Mini]

Solange ich der einzige mit dem Problem ist, soll es kein Blocker sein, aber schon sehr ärgerlich.
Eventuell verschwindet das Problem mit dem CV-Paket? Kann man das vorab zum Release testen?

Was mich aber schon wundert: Standard Wiregate, Comevisu von git, sollte doch funktionieren??

Hab inzwischen auch rsslog aktualisiert => bringt keine Änderung.
Habe rsslog aus der Visu-Hauptseite entfernt => Problem gefühlt seltener, aber nicht gelöst.

Rsslogs ganz entfernen hab ich noch nicht getestet, mach ich aber morgen.

lg
Robert

[Chris M.]

Standard Wiregate und ComeVisu vom Git ist genau das mit dem ich entwickle und teste, d.h. hier sind die Chancen am höchsten, dass ich das reproduzieren kann und somit auch fixen kann.

Aber noch konnte ich es nicht reproduzieren

[Robert_Mini]

Hab grad noch probiert.
Auch ohne rsslog tritt das Problem auf. Allerdings im Moment nur (auch ohne rsslogs), wenn ich 7-8x Reload drücke (unmittelbar nachdem die KNX-Stati angezeigt werden).

Hilft dir die config inkl. Bilder was? Hab natürlich auch viele (!) rrd in Diagrammen.
Könnte es sein, dass beim mehrfachen Reload das WG an seine Leistungsgrenze kommt und dann der eibd eine Anfrage o.ä. auslässt?

lg
Robert

[peuter]

Auch ohne rsslog tritt das Problem auf. Allerdings im Moment nur (auch ohne rsslogs), wenn ich 7-8x Reload drücke (unmittelbar nachdem die KNX-Stati angezeigt werden).

Mal abgesehen davon, dass das jetzt kein realistischer Anwendungsfall ist, einfach ständig neu zu laden, ist das für mich ein weiteres Indiz für die Vermutung, dass es sich hierbei um ein (Performance) Problem des Backends handelt und kein CometVisu Problem.

[Robert_Mini]

Das Problem ist nur, dass es manchmal selbst beim ersten Öffnen der Visu passiert.
Kann man (ich) irgendwo zum Test eine Pause beim Laden einbauen zB Widgets laden, Lesebefehl auf Backend, 1s Warten, dann weiter mit Bilder, Rss, Diagrammen etc.?

lg
Robert

[peuter]

Kann man (ich) irgendwo zum Test eine Pause beim Laden einbauen zB Widgets laden, Lesebefehl auf Backend, 1s Warten, dann weiter mit Bilder, Rss, Diagrammen etc.?

Das wird ohne größere Umbaumaßnahmen im Code nicht so einfach gehen.

[XueSheng]

Ich häng mich hier mal dran, da ich mit dem aktuellen git das gleiche Problem habe (Bus Werte erscheinen manchmal nach dem Laden der Visu, manchmal aber auch nach mehreren Minuten nicht). Produktiv verwende ich zur Zeit noch eine Uraltversion der Cometvisu, weil die ein oder andere Änderung der letzten Monate zu viele Umbauarbeiten an meiner config bedeuten würden. Aber dass die Buswerte nicht geladen werden ist imho ein Showstopper für das Release.

Ich verwende übrigens auch ein wiregate.

Update: Habe das Issue mit entsprechender Info aktualisiert (https://github.com/CometVisu/CometVisu/issues/250).

[Robert_Mini]

Zumindest bin ich nicht mehr alleine

[Chris M.]

Das blöde ist, dass es sich hier vermutlich um eine entsprechende Reaktion des Backends (hier: eibread-cgi) handelt. Wieso und warum weiß ich nicht.

Wenn ich das nicht nachstellen kann, kann ich auch nicht wirklich helfen

Schuss in's blaue: Könnte es sein, dass das WireGate in dem Moment der Anfrage zu sehr ausgelastet ist?

[XueSheng]

Kann man das Backend nicht debuggen?

Zu hohe Auslastung über 20 Minuten und mehr? Unwahrscheinlich. Zumal ältere CV Versionen (fast) keine Probleme machten. Festgestellt hatte ich seiner Zeit nur Probleme im Zusammenhang mit dem Ladeverhalten des rsslog Plugin.

Irgendeine Besonderheit muss hier zugrunde liegen. Das Debuggen muss doch irgendwie möglich sein!?

[Chris M.]

Beim Debuggen kann/muss man den Schnitt bei den übertragenen HTTP-Paketen machen.
Wenn die Antwort auf ein t=0 Request quasi leer ist, dann liegt ein Problem auf dem Server vor.
Wenn die Antwort sauberen Inhalt hat und einen Wert für "i" dabei hat und der Client trotzdem als nächstes t=0 abfrägt, dann ist es ein Problem im Client.

Bei dem WireGate kenne ich durchaus so hohe und lang andauernde Auslastungen. Gerade mit dem rsslog Plugin. Warum und was hier das Problem ist bzw. war, weiß ich nicht. Als ich das vergessene und im Hintergrund immer mitgeladene Browser-Tab geschlossen hatte, war der Spuk zu meinem Erstaunen vorbei. Verschärft wurde das, da ich auch einige Tabs mit drraw offen habe, die beim Browser Start natürlich auch geladen werden und damit erst mal das Graphen-Generieren angestoßen hatten, das erstaunlich Ressourcen-fressend ist.
Die Auswirkung ging bei mir sogar so weit, dass der Monit irgendwelche Prozesse abgeschossen hatte.

[Robert_Mini]

Wollte oben eigentlich ausführlicher posten und keinen sarkastischen Post abliefern... - sorry.

Beim Debuggen kann/muss man den Schnitt bei den übertragenen HTTP-Paketen machen.
Wenn die Antwort auf ein t=0 Request quasi leer ist, dann liegt ein Problem auf dem Server vor.
Wenn die Antwort sauberen Inhalt hat und einen Wert für "i" dabei hat und der Client trotzdem als nächstes t=0 abfrägt, dann ist es ein Problem im Client.

Als Laie: Kann man das Backend nicht so erweitern, dass bei einer leeren Antwort nochmal ein Request gesendet wird? Alternativ würde es helfen, wenn nach einem timeout (20s) keine Anwort kommt, ein erneuter Request? Irgendeinen Watchdog gibt es ja bereits, vielleicht lässt sich der erweitern?

Was mit noch auffällt: Wenn der Request klapp, dann sind die Werte innerhalb der ersten 3-5sec da. Das war früher anders. In meiner älteren Version kommen die KNX-Zustände immer erst nach ca. 15sec, dafür aber gesichert . Irgendwas muss sich hier gefühlt am Ladeverhalten geändert haben...

lg
Robert

[XueSheng]

Chris M.: Danke für Deine Ausführung. Klar ist doch, dass wir im Fehlerfall nicht über die Anfragen t=0 hinwegkommen (Problem auf dem Server laut Deiner Aussage). Daher nochmal explizit die Frage: Wie kann man den Server-Part debuggen? Ohne Deine Hilfestellung werden wir hier nicht weiterkommen.

[Robert_Mini]

Um nicht den Release Thread zu sehr zu belasten:
Das Verhalten ist auch in der RC4 das gleiche.
Meist klappt das initiale Laden der KNX Stati NICHT.
Offentsichtlich kommt dann alle 60sec der neue Leseversuch (Watchdog?).
Nach 3min sieht man den 3 (misslungenen) Leseversuch => auffällig ist die Größe 0Byte.
Erst der 4. Versuch klappt dann => Größe 4,63kB, ab dann kommen in kurzen Abständen die Rückmeldungen vom backend, so wie es sein soll.

Kann mich hier leider nur wiederholen: meine alte Version lädt zwar generell viel langsamer (15sec), dafür aber immer im 1. Anlauf erfolgreich. Auch in dieser Version kommen zuerst die Bilder, dann die rsslogs und zuletzt die KNX Stati.

In der aktuellen git und RC4: Wenn's klapp sind die Stati nach 2sec da und der Rest nach 3sec, aber leider eben nur bei jedem 7-10 Reload oder eben nach 3-4min Warten.

Hab hier mal die files aus /lib angehängt.
Hier hat sich offensichtlich vieles getan, seit meiner letzten funktionieren Version und aktuell:
cometcisu-client.js => meine alte Version => OK
CometVisuClient.js => aktuelle RC4 => NOK

Wie kann ich hier helfen? Offensichtlich bin ich nicht mehr der einzige.
@XueSheng: Was neues bei dir?

lg
Robert

[XueSheng]

Von meiner Seite nichts Neues. Da ich kein Programmierer bin, benötige ich zumindest ein paar Anhaltspunkte, um ein Debugging durchführen zu können. Ich bleibe bis auf weiteres bei der alten CV Version und werde über kurz oder lang zu einer anderen Visu wechseln (das Problem habe ich vor über einem Jahr gemeldet und mehrfach um Hilfe gebeten, aber da das Problem wohl nur uns beide betrifft, besteht offentlich kein Interesse an einem Lösungsansatz). Schade eigentlich.