CometVisu auf weiterer Hardware

[swiss]

Hmm.. könnte dass mit der Pfadangabe zutun hsben. Die cv liegt normalerweise unter "visu" oder "visu_svn" hier liegt sie aber direkt im www Verzeichniss. Wenn da beim Editor der Pfad zur Config hardcodet ist, würde dass den Fehler erklären...

[Merlin123]

ich kann die visu aber mit http://192.168.0.127/visu aufrufen. Dann stimmt der Pfad doch, oder?
Das Script macht ja auch ein
mv visu /var/www

Also entpackt er nach www und moved dann.

[swiss]

Stimmt. Das müsste so auf jeden fall funktionieren... Keine Ahnung. Ohne firebug wird es schwer den Fehler zu finden. Die Palette reicht von "kein schreibzugriff" bis zu fehlenden Pakete für den Interpreter

[Merlin123]

ok. ich schau mal ob ich da heute abend was finde....

Wie gehe ich da am besten vor um sinnvolle Ergebnisse zu bekommen?
Firbug starten, dann die Seiten aufrufen und in Firebug schauen ob was auffällt?

Gerade bei den CV Meldungen frag ich mich, wie ich da im Browser was sehen soll. Die werden doch innerhalb von CV generiert und nur an den Browser ausgeliefert, oder?

[Chris M.]

Gerade bei den CV Meldungen frag ich mich, wie ich da im Browser was sehen soll. Die werden doch innerhalb von CV generiert und nur an den Browser ausgeliefert, oder?

Die CV läuft komplett im Browser.

Auf dem Server braucht's neben irgend einem HTTP-Server nur noch die eibd-Anbindung - und selbst die ist nur ein CGI-BIN für den HTTP-Server das bisschen JSON erzeugt.
Für den Editor kommt bisschen PHP oben drauf, aber eigentlich auch nur, damit der im Dateisystem agieren kann.

[Merlin123]

AW: CometVisu auf weiterer Hardware

Ah ok.
Ich werde es heute nicht mehr schaffen das mut Firebug zu testeb. Die kids halten mich auf Trab
Schau mir das aber nochmal an.

Gruß,
Oliver

Gesendet via Tapatalk

[Merlin123]

so... also Firebug meint (CV 0.6.2 auf Raspberry Pi mit Lighttpd als Webserver)
Bei der Check config macht der Browser ein get check_config.php und bekommt einen 403er Fehler zurück. (URL http://192.168.0.127/visu/check_config.php)
Die Permissions auf der Datei sind 755.

Beim Aufruf des Editor versucht er die Dateien zu laden:
-rw-rw-r-- 1 www-data www-data 1193 Dec 30 2011 get_addresses.php
-rw-rw-r-- 1 www-data www-data 1005 Dec 30 2011 get_widget_diagram.php
Beide Male kommt auf ein 403er Fehler

Beim Versuch die Konfig zu speichern mal er einen POST auf diese Datei
-rw-rw-r-- 1 www-data www-data 6112 Dec 30 2011 save_config.php
und bekommt auch den 403er Fehler

Welche Permissions müssten die Sachen den haben?

[Chris M.]

Erst mal grundsätzlich: funktioniert dort PHP überhaupt?

[Merlin123]

AW: CometVisu auf weiterer Hardware

Guter Hinweis....
Nein. Php tut nicht
Mal schauen ob ich rausfinde wieso. Nehme Tipps dankend an.

Gruß,
Oliver

Gesendet via Tapatalk

[Merlin123]

AW: CometVisu auf weiterer Hardware

Fastcgi war nicht geladen. Die Meldungen sind jetzt weg.
Jetzt mal schauen was geht. Ich glaube mein eibd mag noch nicht...

Gruß,
Oliver

Gesendet via Tapatalk

[Merlin123]

AW: CometVisu auf weiterer Hardware

Ich habe mein Problem in diesen Thread ausgelagert.

[derwolff2010]

Hallo,

bei mir läuft die Cometvisu auf einem Dockstar und ist experimentell an ein anderes Bussystem als KNX angebunden.
Grundsätzlich läuft auch alles, mir fällt nur auf dass anscheinend lighttpd sporadisch die Verbindung abbricht ohne dass die Timeoutzeit abgelaufen ist.
Es häufen sich dann bei mir entsprechend viele read-Prozesse an, da die Visu nach einem Abbruch eine neue Anfrage stellt.

Muss noch ein Parameter in der lighttpd Konfiguration für das Keep-Alive Handling gesetzt werden? Oder hat jemand eine Idee woran dies sonst noch liegen kann?

Gruß
Carsten

[Chris M.]

Die CV bricht selber eine Verbindung nach einer gewissen Zeit (müsste nachsehen ob's jetzt eine oder fünf Minuten waren...) ab, um sicher zu gehen, dass nicht nur das Backend ein Problem hat.

=> Die Implementierung des Backends muss das abkönnen.

Aber anders herum geht das genau so: das Backend kann intern einen Timeout haben (optimaler Weise etwas über dem vom Client) und dann die Verbindung und ggf. sich selbst beenden.

Damit sollte sich das leicht lösen lassen.

[derwolff2010]

Auf der Backendseite habe ich eine angepasste Version von eibread-cgi laufen. Der Standardtimeout ist wie im Orginal 300 Sek. oder man gibt einen Wert über den Parameter t mit. Der Rest ist eins zu eins aus dem SVN.

Auf dem CV Demoserver liegen die Antwortzeiten auch deutlich unter 60 Sek. . Kommen wirklich so viele Telegramme über den Bus, die für die Visu relevant sind?
In meiner Version von eibread-cgi wird wirklich nur dann eine Anwort gesendet wenn der Wert des aktuellen Telegramms von der Visu benutzt wird, alles andere wird unterdrückt bis zum Timeout. Es soll ja nicht gepollt werden ;-) . Deshalb kommen mir die Zeiten auf dem Demoserver etwas kurz vor.
Wahrscheinlich sieht man auch deshalb dort nicht den beschrieben Abbruch.

Ich bin durch meine Anpassung immer etwas verunsichert ob dies noch ein Bug in CV ist, oder ob dies nur mich betrifft. Bei dem Diagramm-Plugin habe ich auch noch etwas eingenartiges geloggt, aber leider hat sich noch kein anderer User dazu geäußert.

[Chris M.]

Auf dem CV Demoserver liegen die Antwortzeiten auch deutlich unter 60 Sek. . Kommen wirklich so viele Telegramme über den Bus, die für die Visu relevant sind?
In meiner Version von eibread-cgi wird wirklich nur dann eine Anwort gesendet wenn der Wert des aktuellen Telegramms von der Visu benutzt wird, alles andere wird unterdrückt bis zum Timeout. Es soll ja nicht gepollt werden ;-) . Deshalb kommen mir die Zeiten auf dem Demoserver etwas kurz vor.
Wahrscheinlich sieht man auch deshalb dort nicht den beschrieben Abbruch.

Naja, man kann ja im Firebug mal nachschaun, was da so übertragen wird. Wenn es lauter verschiedene Pakete sind, dann ist auf diesem System anscheinend einfach eine hohe Last (was mich nicht wundern würde).

Bei mir hier z.B. sehe ich durchaus die Timeouts - die sind aber auch (s.o.) durchaus gewollt.

Ich bin durch meine Anpassung immer etwas verunsichert ob dies noch ein Bug in CV ist, oder ob dies nur mich betrifft.

Das kann natürlich beides sein.

Timeouts mit dem "r" sind aber völlig normal.