- √ - CometVisu stellt "Werte-Update" ein

[speedyG]

Noch kurz ein Phänomen was ich grad festgestellt habe.
Manchmal friert es nur einige Schalter ein. Einige aktualisieren sich wunderbar andere aber nur wenn ich von der Classic UI einmal schalte. Danach gehts auch wieder aus der CometVISU. Irgendwie merkwürdig.
Jetzt ist aber wirklich Schluss für heute.

Gruss Mark

[teichsta]

Hi,

Vielleicht könnt Ihr das mal testen und berichten ob es besser ist, oder ob ggf. neue Probleme auftreten. Langzeittests hab ich damit noch nicht gemacht aber die ersten kurzen Tests lassen hoffen.

wäre klasse, wenn wir den Fix noch in das Release am Sonntag reinbekommen würden. Einfach baldmöglichst einen PR schicken :-)

Gruß,

Thomas E.-E.

[peuter]

Es wird ja jede Sekunde oder so eine read Anfrage mit allen Werten gesendet. Nach einer Weile braucht dann die Antwort sehr lange und danach kommen auch die read Anfragen nicht mehr.

Hier mal ein paar Worte zur Erklärung: Die CometVisu sendet einen Read-Request für alle Items, deren Updates sie empfangen möchte. Beim ersten Request schickt das CV-Binding den Status aller angefragten Items zurück, damit die Visu sich initialisieren kann. Das kann natürlich, je nach Größe der CV-Config ein wenig dauern. Ab dem zweiten Read-Request sendet das Binding aber nur noch die geänderten Werte zurück, das geht dann ziemlich schnell. Solange sich keine Werte ändern, wird auch nichts gesendet, von daher kann ein Read-Request sehr lange auf Antwort warten (aber nach 60 Sekunden wird er von der CV abgebrochen und neu gestartet). D.h. also nicht das die Antwort so lange dauert, weil irgend etwas überlastet ist, sondern, weil gerade nix los ist.

Noch kurz ein Phänomen was ich grad festgestellt habe.
Manchmal friert es nur einige Schalter ein. Einige aktualisieren sich wunderbar andere aber nur wenn ich von der Classic UI einmal schalte. Danach gehts auch wieder aus der CometVISU.

Was ich beim testen festgestellt habe, da man da ja openHAB zig-mal neustartet, ist, dass es nach Neustart schon ein wenig dauern kann, bis openHAB komplett gestartet ist und die CV auch reagiert. Ich bitte Dich, das bei Deinen Tests zu berücksichtigen. Wenn Du demnächst auf einem CubieBoard testest, wird das natürlich noch ein wenig länger dauern.

Im übrigen kann man in der Firebug-Console prima sehen, welche Updates das CV-Binding zurück sendet.

wäre klasse, wenn wir den Fix noch in das Release am Sonntag reinbekommen würden. Einfach baldmöglichst einen PR schicken :-)

Ich hatte gleichzeitig ein Upgrade vom Atmosphere auf 2.0.7 gemacht, dadurch aber eine Exception. Die Ursache dafür habe ich nicht gefunden (irgendein falscher cast von BundleURLConnection auf JarURLConnection). Ich habe auf die schnelle zwar keine Auswirkungen feststellen können, aber da das auch das Rest-Bundle betraf, wollte ich hier erstmal testen lassen.

In Hinblick auf das kommende Release, habe ich Atmosphere wieder zurück auf 2.0.3 gesetzt, die Exception ist weg und der PR hat die Nummer #800.

[milymat]

So ich hab nun dein Binding getestet. Nach einem Neustart von OpenHAB läuft alles 1A. Die Aktualisierung von Wert ist viel schneller geworden.

Ich werds heute im Laufe des Tages testen, sollten die Werte nicht mehr aktualisiert werden, melde ich mich.

[milymat]

Der Hammer! Bis jetzt läuft die CometVisu 1A. Werte aktualisieren sich sauber.

Vielen Dank

[speedyG]

Bei mir läuft es jetzt auch bedeutend besser. Liegt vielleicht wirklich am openhab neustart. Wobei openhab läuft bei mir auf einem normalen Ubuntu Rechner der eigentlich nur Däumchen dreht. Das Cubieboard soll dann nur der Visudarstellungsrechner werden und ein Controlpanel ersetzen.

Anbei noch ein Screenshot wo einige Anfragen von heute ins leere gelaufen sind. Wenn ich es richtig verstanden habe sollte es ja dann so sein, dass es in dieser Zeit keine Änderungen gab, deswegen der Abort, und ein neuer Request gesendet wurde. In dieser Zeit gab es keine Aktualisierung. Nach dem Write müsste ja sofort ein Read kommen. Nur der vorherige Read eierte noch rum und erst der nächste Read brachte ein OK. Aber auch das passiert jetzt sehr selten.
Damit kann ich leben, vielleicht liegt das auch an meinem System.
Ich beobachte weiter...



Gruss Mark

[milymat]

Also nach ausgiebigen Tests - die CometVisu läuft und läuft

Nochmal vielen Dank.

[peuter]

Also nach ausgiebigen Tests - die CometVisu läuft und läuft

Freut mich zu hören, wenn das Problem behoben ist, möchte ich Dich bitten dieses Thema als erledigt zu markieren.

[speedyG]

Hallo nochmal,

also irgendwie werde ich nicht glücklich mit der Geschichte.
Bei mir bleiben die Werte dann hängen, wenn mal ein Read nach einer Minute abgebrochen wird. Der darauf folgende read bleibt dann hängen und es aktualisiert sich nichts mehr. Wenn ich regen Busverkehr habe und sich ständig etwas aktualisert habe ich keine Probleme. Aber sobald mal eine Minute nichts passiert geht wieder nichts.
Ich habe mal 2 Screenshots von Chrome gemacht. Zwischen den read requests sehe ich so keinen Unterschied. Das einzige was auffällt, wenn ich den Mauszeiger über die Spalte Initiator halte sieht das anders aus. Der Request mit der Zeile CometVisu.restart liefert mir kein Ergebnis. Das sieht man daran, dass nur noch write kommt und der Read nicht erneut kommt.
Kann das vielleicht mal jemand bei sich testen? Es darf dann allerdings eine Minute nichts am Bus passieren.
Ich habe schon alles aktualisiert auf Cometvisu 0.8.2 und openhab 1.5.0 Snapshot. Wenn es bei anderen läuft kann es nur noch meine Config sein.
Danke

Gruss Mark

[peuter]

Ok die gute Nachricht: Ich kann das Problem reproduzieren, liegt also nicht an Deiner config. Sobald ein Read-Request per Timeout abgebrochen wurde, gibts Probleme.
Nun die schlechte Nachricht: Auch nach mehreren Stunden probieren und debuggen habe ich keinen Schimmer wie ich das Problem beheben kann. Ich werde es zwar weiter probieren eine Lösung zu finden, bin aber völlig ratlos.

[speedyG]

Hmm, naja ich weiss gar nicht ob ich mich jetzt freuen soll...
Ich hatte auch schon versucht etwas zu finden bin aber an dem ganzen java zeugs gescheitert. Ist schon länger her, dass ich mich mit sowas beschäftigt habe.
So vom rein logischen her müsste man nur die Stelle finden die nach einem Timeout den neuen Request sendet. Dieser scheint ja irgendwie anders zu sein als die anderen requests. Vermutlich ist das allerdings nicht ganz so einfach...
Eine andere Möglichkeit wäre noch den Busverkehr zu erhöhen.

[tger977]

auch auf die Gefahr hin daß ich wieder falsch liege oder was nicht richtig verstanden habe...

Das von Mark geschilderte Timeoutverhalten könnte bei mir (ich habe kein openhab!) zu meinen Erfahrungen passen, da ich bisher nur mit meinem Testaufbau mit extrem wenig Busverkehr gearbeitet habe und ich das Verhalten ja quasi permanent damit bekommen habe. Derzeit bin ich kurz vor Fertigstellung der Installation, ich wollte dort dann mit deutlich mehr Buslast mir das nochmal genauer ansehen.

Deshalb die Frage: Kann das Problem vielleicht doch auch unabhängig von OpenHAB sein?

Andi

[peuter]

So vom rein logischen her müsste man nur die Stelle finden die nach einem Timeout den neuen Request sendet. Dieser scheint ja irgendwie anders zu sein als die anderen requests. Vermutlich ist das allerdings nicht ganz so einfach...

Die Stelle zu finden ist kein Problem. Auf der Client-Seite gibt es einen watchdog, der jeden Read-Request nach 60 Sekunden abbricht und neu sendet. Es wird dann exakt der selbe Read-Request neu gestartet, da gibt es keine Unterschiede. Das Problem hierbei scheint zu sein, dass der Server (in dem Fall ist das das CometVisu-Backend in openHAB) nichts davon mitbekommt. Der bekommt nur mit das es einen neuen Read-Request gibt und scheinbar kommt der dann irgendwie durcheinander und sendet die Updates nicht über den neuen Read-Request zurück.

Da gibt es nun zwei mögliche Lösungsansätze:
1. man bekommt es irgendwie hin, das der Client den laufenden Request auf andere Weise beendet, so dass der Server das mitbekommt und entsprechend darauf reagieren kann
2. der Server merkt, dass er einen neuen Read-Request vom selben Client bekommt beendet den alten und sendet die updates an den neuen

Hab in beide Richtungen bisher keine Fortschritte erzielen können.

Eine andere Möglichkeit wäre noch den Busverkehr zu erhöhen.

In dem Fall wäre es wohl besser den Timeout zu erhöhen, z.B. auf 5 Minuten oder so. Zu finden in der lib/cometvisu-client.js

  this.maxConnectionAge = 60;                            // in Seconds - restart if last read is older

ist so aber nur in der SVN-Version zu finden und letzendlich nur ein unschöner Workaround.

[peuter]

Deshalb die Frage: Kann das Problem vielleicht doch auch unabhängig von OpenHAB sein?

Kann ich nicht beurteilen, das originale CometVisu-Backend kenne ich überhaupt nicht, bzw. hab keinen Schimmer wie das funktioniert. Ausschließen kann man das natürlich nicht das der Client da irgendwie einen Fehler hat.
Ich werde mal am Wochenende versuchen da weiterzukommen ist auf jeden Fall nicht so auf die schnelle zu lösen (zumindest für mich nicht).

[tger977]

Ich werde mal am Wochenende versuchen da weiterzukommen ist auf jeden Fall nicht so auf die schnelle zu lösen (zumindest für mich nicht).

Danke! Für mich ist es absolut gar nicht lösbar Daher bin über jede Hilfe dankbar...