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

[XueSheng]

Habe auch kurz die alternative CometVisuClient.js getestet: Gleiches Problem wie bisher. Dies nur zur Vollständigkeit.

[Chris M.]

Leider habe ich keine gute Nachricht: Habe die Client-Datei in die aktuelle git kopiert, das Problem besteht leider weiterhin.
Hab nochmal ein paar Wireshark files auf den dropbox link geladen => Dateinbezichnung: Load_CV_git_special_per_URL_....
https://www.dropbox.com/sh/u9jcvfrj4...W5MfBJH3a?dl=0

Bist Du ganz sicher, dass der Cache hier nicht noch die alte Datei genutzt hat?

Angeschaut habe ich gerade mal die Load_CV_git_special_per_URL_3xxs_notsucessful.pcap ng - die sollte schon mit dem "Neuen-Alten" Client sein, nicht?
Hier ist das Verhalten der r-Requests noch so wie bei der 0.10.0... (=> Entweder das Verhalten ist wirklich gleich - oder der Browser hat eben noch nicht die andere Datei verwendet)

Zum Check ob hier der Cache ein Schnippchen geschlagen hat: die Browser-Konsole öffnen, auf die Source-Dateien gehen und im CometVisuClient.js nachschauen. Die "Neue-Alte" Version hat in Zeile 37 und 38 folgendes stehen:

    // Test - only valid on WireGate:
    this.urlPrefix = '/cgi-bin/';

Was hat sich sonst bei 0.9.2 => 0.10.0 geändert? Die 0.9.2 lädt absolut zuverlässig und schnell (ca. 5s).
Wurde serverseitig was geändert? Wo sind eigentlich die Files des backends, wo die GET... abgearbeitet werden oder ist das schon im eibd? Sorry, habe die Details der Kommunikation der CV leider immer noch nicht durchschaut.

Server-seitig läuft nur der eibd bzw. knxd mit dem eibread-cgi und eibwrite-cgi, was (inzwischen) mit dem eibd bzw. knxd mitgeliefert wird. Da Du das WireGate verwendest und nur die Web-Seiten (JS, CSS, ...) per Git (oder SVN) änderst wird das Backend identisch geblieben sein.

Da es im Backend einen Code Update gab - den ich bei mir nie getestet habe - setzte ich hier bei der Analyse auch darauf, dass Du die unveränderte Version vom WireGate verwendest.

Vom 0.9.2 zur 0.10.0 haben sich zwei elementare Dinge geändert (neben allem anderen was auch im ChangeLog steht): der Client - also die JS Datei um die es hier geht - wurde von zwei getrennten Dateien (eine für eibd und eine andere für OpenHAB) zu einem Universal-Client vereinheitlicht. Und zum anderen wird neben den beiden schon bekannten Caches der Inhalt der Config-Datei gecacht, so dass bei einem Start die Visu noch schneller dargestellt wird. Das *sollte* aber keinen Einfluss haben... Aufgrund der WireShark Dateien gehe ich auch nicht davon aus, dass das hier ein Problem ist.

Wobei mir im Versuch ein Unterschied im direkten Verhalten des Clients zwischen 0.9.2 und 0.10.0 aufgefallen ist: Wenn die Config nur aus GAs besteht, die NICHT im eibd/knxd-Cache enthalten sind, dann gibt es ein Verhalten, dass die hier beschriebenen Probleme erklären könnte.
Aber: es dürfen eben keine der GAs im Cache sein. Z.B. weil man nur Test-GAs verwendet und/oder auf dem Bus so viel los ist, dass diese GAs vor dem Start wieder aus dem Cache geflogen sind...
=> Robert_Mini und XueSheng könnte das bei Euch der Fall sein?
Aber eigentlich kann ich mir so einen Fall bei einer realen Visu nicht vorstellen, nur bei einer Demo-Config...

[Robert_Mini]

Hallo Chris!
Cache hatte ich geleert, soweit ich gesehen habe, stand beim read nun SESSION statt undefined, somit wäre ich hier sicher gewesen. Prüfe das aber heut Abend nochmal.
Ich fürchte schon, dass ein paar Test-GAs vorkommen, die nicht am KNX vorkommen bzw. nicht lesbar sind (auch WG Stati, die ich normalerweise zyklisch sende, damit sie im eibd Cache aktuell sind.
Klingt aber nach einem Ansatzpunkt!

lg
Robert

[Robert_Mini]

Steh grad auf der Leitung. Wenn ich unter Entwicklertool auf Browser-Console drücke, kommt das Fenster wie im Anhang. Wo kann ich hier die geladenen .js finden?

Wenn ich in Firefox unter Einstellungen/Erweitert/Netzwerk sowohl Offline Webinhalte als auch Zwischengespeicherte Webinhalte leere, sollte das doch passen oder. Werde das aber noch anhand der geladenen .js überprüfen, sobald ich in der Console den richtigen "Knopf" finde.

Hinsichtlich Test-GAs: Hab grade eine Menge 13/x/x bzw. ungültige (oder nich lesbare) GAs rausgeschmissen, Problem bleibt aber bestehen. Muss aber hier noch weiter suchen, denn durch das Mapping übersieht man leicht welche (zB 0°C).

lg
Robert

[Chris M.]

Ein paar nach KNX Standard gültige, aber nicht aktiv genutzte GAs sollten hier kein Problem solange aktiv verwendete GAs auch enthalten sind. Am besten welche die zyklisch gesendet werden...

Im Chromeium würde das ganze (hier allerdings eine 0.9.2) so aussehen:
Screenshot_20170314_225735.png

[XueSheng]

Ein weiterer Fall?
https://knx-user-forum.de/forum/supp...leere-response

[Chris M.]

Ja, sieht so aus. Ich schlage vor, dass wir das Thema dort weiter bearbeiten, da es hier nicht mehr zum Thread-Titel passt...