Ankündigung

Einklappen

Nicht vergessen: Das KNX-UF-Symposium by eib-tech in München am 3. November 2017!

Mehr anzeigen
Weniger anzeigen

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

Einklappen
X
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

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

    Hallo zusammen!

    Folgendes Problem habe ich unter 0.9.2 und der aktuellen Version auf GitHub (rev2742) am Iphone:
    1) colspan:
    - Trigger und Info mit jeweils colspan=2 werden nebeneinander dargestellt
    - Trigger mit colspan=2 und Info-widget mit colspan=1 passt ebenfalls in eine Zeile
    - ABER: Trigger mit colspan=3 und info mit colspan=1 wird in der Zeile umgebrochen

    2) Beim initialen Aufrufen der Seite, wird auf der 1. Seite die Schrift zu groß dargestellt. Beim Hin und Zurückklicken wird dann die richtige Schriftgröße verwendet.

    lg
    Robert
    Angehängte Dateien

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

    Einen Kommentar schreiben:


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

    Einen Kommentar schreiben:


  • Chris M.
    antwortet
    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

    Einen Kommentar schreiben:


  • Robert_Mini
    antwortet
    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
    Angehängte Dateien

    Einen Kommentar schreiben:


  • Robert_Mini
    antwortet
    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

    Einen Kommentar schreiben:


  • Chris M.
    antwortet
    Zitat von Robert_Mini Beitrag anzeigen
    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:
    Code:
        // Test - only valid on WireGate:
        this.urlPrefix = '/cgi-bin/';

    Zitat von Robert_Mini Beitrag anzeigen
    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...

    Einen Kommentar schreiben:


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

    Einen Kommentar schreiben:


  • Robert_Mini
    antwortet
    Hallo Chris!

    Vorweg - Danke für dein Engagement!!!
    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

    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.

    Danke
    Robert

    Einen Kommentar schreiben:


  • Chris M.
    antwortet
    So, mal ein Versuch - ist nur temporär und funktioniert nur auf dem WireGate und bei ähnlich aufgesetzten Geräten: Ich habe den Client-Code der 0.9.2 mal so erweitert, dass die 0.10.0 damit funktioniert (funktionieren sollte... Bitte auf der Konsole auf Fehlermeldungen achten! Ist ja nur ein Hack...).

    => Bitte mal bei der Git-Version (nicht dem minimized Release!) die /src/lib/CometVisuClient.js durch die angehängte (entpackte!) Datei ersetzen und dann nochmal testen.

    Tritt das Problem nicht mehr auf, suchen wir im Client weiter. Tritt das Problem weiterhin auf, dann ist's eher ein Problem am Server.
    Angehängte Dateien

    Einen Kommentar schreiben:


  • peuter
    antwortet
    Hab mir die Frage selbst beantwortet: Kann nicht sein, dass das jemand benutzt, den man bekommt direkt ne Fehlermeldung auf der Console und niemals irgendwelche Stati in dem Fall.

    Einen Kommentar schreiben:


  • peuter
    antwortet
    Benutzt eventuell jemand von Euch dieses Feature: http://cometvisu.org/CometVisu/de/la...blequeue-queue
    Hab gerade festgestellt, dass diese Funktionialität beim Überarbeiten des CometVisu-Clients für 0.10.0 verloren gegangen ist. Das würde zumindest unterschiedliche Verhaltensweisen zwischen den Versionen erklären, aber nur wenn mans auch benutzt. Ohne den URL-Parameter ist das sowieso abgeschaltet, weil noch experimentell und hat vielleicht sowieso nie richtig funktioniert.

    Einen Kommentar schreiben:


  • XueSheng
    antwortet
    Den Aufwand mit zweitem WG zum Testen wollte ich nicht betreiben, daher habe ich eine WG Instanz für Testzwecke virtualisiert (Server mit Xeon E3, usw). Der Zugriff auf den Bus erfolgt jedoch nicht autark, sondern übers Netzwerk (eibd auf Wiregate).

    Folgendes habe ich festgestellt:
    WG (original):
    • Deaktivieren aller Plugins (rsslog, diagram und colorchooser) ändert nichts am Problem
    • starke Reduzierung der GAs verbessert die Situation deutlich (je weiter die Visu abgespeckt wird, desto seltener tritt das Problem auf)


    WG (virtualisiert):
    • Problem lässt sich deutlich seltener hervorrufen.
    • Wenn eine Antwort auf t=0 ausbleibt, fängt sich die Visu i.d.R. innerhalb weniger Minuten. Bei WG (original) kann das schon mal ins Unendliche gehen (nach 1h noch keine Buswerte und noch immer Anfragen mit t=0).


    Mir ist nicht klar wo sich der Client der Visu versteckt (irgendwo im JS Code?). Der Ansatz von Robert könnte durchaus interessant sein (Austausch Client 0.9.2 und 0.10.0)

    Einen Kommentar schreiben:


  • Robert_Mini
    antwortet
    Hallo Chris!
    Super, dass du dich um das Thema annimmst :-)
    Ehrlich gesagt, glaub ich nicht an ein Performance Problem am WG. Im Anhang eine Übersicht. Es laufen zwar einige Plugins, aber alle mit Zyklen um 60-300s bzw. nur bei events, alle compiliert. Es läuft bei mir auch keine Visu ständig, nur on demand am Tablet, PC oder Handy und wird dann wieder geschlossen.

    Auch bei einer kleineren Visu ohne rsslog habe ich das gleiche Problem. Und dass das WG 60s keine Zeit zum Antworten hat, never ever. Mir scheint eher, dass die Anfrage "ignoriert wird/verloren geht" und deshalb nach 60s ein erneuter Versuch folgt.
    Kleiner Beweis dafür: Wenn die Stati nicht "sofort" da sind, drücke ich F5, nach 5s wieder, etc. Nach dem 4-6 Versuch sind die Stati da wieder "sofort" da. Und ich habe beim Reload nicht das Gefühl, das die CV aufgrund "Überlast" länger laden täte.

    Weiters habe ich gerade parallel eine Console am WG geöffnet. Die CPU last die ich mit "top" sehe, geht beim Reload für 2sec auf cpu 0%id und dann wieder zurück auf 70-75% idling.

    Noch ein paar Ideen:
    - Kann ich eigentlich testweise den client von 0.9.2 unter 0.10.0 testen?
    - Auch könnte ich StefanW bitten, mir einen WG zum testen zur verfügung zu stellen, dann ohne Plugins, rrds und Sensoren...

    Danke und lg
    Robert
    Angehängte Dateien

    Einen Kommentar schreiben:


  • Chris M.
    antwortet
    Nachtrag:
    Der Client hat sich tatsächlich zwischen 0.9.2 und 0.10.0 geändert, da war mein letzter Blick in den Code nicht richtig.
    Zur 0.10.0 kam der vereinheitlichte Client, der das traditionelle Backend mit dem OpenHAB Backend zusammengeführt hat.

    => Hier besteht grundsätzlich das Risiko, dass sich beide Versionen nicht gleich verhalten

    Der WireShark-Dump zeigt mir jedoch, dass hier ein Reset vom Client aus passiert sein muss (evtl. kann hier jemand mit besseren WireShark-Kenntnissen das bestätigen) - was durchaus dem gewünschten Verhalten entsprechen würde.
    D.h. wenn die Annahme stimmt, dass sich der Client bei der 0.9.2 und 0.10.0 gleich verhält (weil wir keinen Bug eingebaut haben) dann sollte auch die 0.9.2 sich gleich verhalten und das gleiche Problem zeigen - wenn auch hier vom WireGate nicht innerhalb von 60 Sekunden eine Antwort kommt.

    Da die 0.9.2 jedoch eine andere Last auf dem WireGate erzeugt (ich hätte vermutet(!): einen höhere...) kann es gut daran liegen, dass es daran liegt, dass das Thema dort nicht auffällt.

    Oder der Client der 0.9.2 hat sich doch anders verhalten als der der 0.10.0...

    Einen Kommentar schreiben:

Lädt...
X