Das nächste Release

[itarch]

Hi

hab bei den CometVisue Releases 0.10.0-* die Situation, dass die Statie nicht aufgebaut werden. Im Entwicklermodus sehe ich folgende wiederkehrende Meldung:

GET http://192.168.1.30/cgi-bin/r?s=[B]undefined[/B]&a=6/1/6&a=6/1/3&a=6/1/0&a=6/1/9&a…a=5/2/2&a=5/2/44&a=5/2/40&a=5/2/91&a=5/2/90&a=5/2/96&a=5/2/95&a=5/2/50&t=0 [B]403 [/B]([B]Forbidden[/B])

Die Meldung kommt in verbindung mit "jquery.js:9203"

Was mich wundert ist, dass s=undefined steht.
Er übernimmt nicht die Session ID, die in /usr/lib/cgi-bin/l hinterlegt ist.

pi@RASP3BII:~ $ cat /usr/lib/cgi-bin/l
#!/bin/sh
echo "Content-Type: text/plain"
echo ""

echo "{ \"v\":\"0.0.1\", \"s\":\"KNXD\" }"

NACHTRAG:
Fehler beseitigt! Mußte in der /etc/apache2/conf-enabled/serve-cgi-bin.conf Anpassungen vornehmen.
Aber, CometVisu (in der Version 0.10.0-RC3 mit knxd 0.12.13) zeigt nach wie vor keine Statie an.

Hat jemand diese Kombination auf RPI3 (Jessie) am laufen?

[Chris M.]

Das mit dem s=undefined hat sich wohl bei der Client-Umstellung eingeschlichen, ist aber nicht weiter schlimm, da das Backend des eibd/knxd das zur Zeit nicht auswertet.
=> Es muss an etwas anderem liegen

Welche Rückmeldung kommet denn nun beim "r"? Falls immernoch ein 403, dann muss das gelöst werden

[itarch]

Nein 403 kommt nicht mehr...
Die Statie (bei b) aber auch nicht.
Such mir schon lange ein Wolf

Beim Chrome - Entwicklermodus - Network - Response
bzgl Aufruf /cgi-bin/r?....
sehe ich

bei der Kombination (a) KNXD 0.12.8:c9ea107 und CV 0.9.2 : {"d": {"6/2/0":"0C18","6/2/15":"0C1A"},"i":43024}
bei der Kombination (b) KNXD 0.12.13-2 und CV 0.10.0-RC3 : {"d": {,"0/0/3":"00","0/0/4":"01", ...

Bei (a) kommen die Statie. Dass diese nach ne zeit verloren gehen, tja keine Ahnung.
Bei (b) kommen keine Statie. Das Komma da oben gefällt mir auch nicht.

Ich hab hier zwei RPI3 und kann SEHR zeitnah testen. Nur was?

[Chris M.]

Ja, das Komma darf dort nicht sein. Ob es den JSON-Parser so irritiert, dass der keine Daten mehr zurück gibt kann durchaus sein (testen kann ich's gerade nicht).

Smurf mir sieht das nach einer Regression im eibread-cgi aus. Kann das sein?

[Smurf]

Klingt logisch. Ich seh gleich mal nach.

[Smurf]

v0.12.14 hochgeladen. Bitte testen.

[Smurf]

… und TODO: in der nächsten "großen" Version einen vernünftigen JSON-Generator verwenden statt dieses Unfugs.

[itarch]

Yepp
Ich teste mal... mit
Weizierl 730, RPI3, Jessie, KNXD 0.12.14, CometVisu 0.10.0-RC3, Windows 10 Chrome oder Android 6 Browser

Und siehe da, die Statie sind wieder da !!!
Nur am Rande, Steuerung über CV geht (folglich) auch.

Da ich zwischenzeitlich den Überblick verloren habe, in welcher Kombination die Statie nach und nach verloren gingen, werde ich die nächsten Tage berichten wie sich das obige Setup in dieser Sache verhält.

[Robert_Mini]

Löst dieser Fix auch dieses Problem?
https://knx-user-forum.de/forum/supp...-rev2742/page3

oder ist das spezifisch für den RPI3?
lg
Robert

[Chris M.]

Der Release Candidate 4 ist nun draußen. Bitte nochmal intensiv testen!

Wieder gilt: wenn keine (schweren...) Bugs gefunden werden, wird das in ca. 1 Woche das finale Release

[itarch]

Feedback:

Das Setup wie in #53 beschrieben ist stabil.
Es gehe keine Statie verloren. Soweit der Stand nach min 36 Std. Testzeit. Dabei hab ich zwischendurch mindestens 12 Std. nicht zugegriffen. 36 Std. bedeutet, dass KNXD und Apache resp CometVisu nicht neu gestartet wurden.

Da ich parallel noch ein RPI1 mit Wheezy, eibd 0.0.4 und CV 0.9.2 am laufen hab, stelle ich folgenden Unterschied zu diesem Setup fest: Statie Änderungen werden im aktuellen Setup (knxd 0.12.14, CV 0.10.0-RC3) sehr Zeitverzögerung (5-10 sec) angezeigt. D.h. wenn ich ein dimmbares Licht über das 1-bit-objekt einschalte (100%) dauert es 5-10 sec bis das Widget (=Dimmen) voll aufschlägt.

[Chris M.]

Das CometVisu Projekt freut sich nun genau einen Monat nach dem ersten Release Candidate die Version 0.10.0 zu veröffentlichen, die unter https://github.com/CometVisu/CometVi...-0.10.0.tar.gz oder https://github.com/CometVisu/CometVi...isu-0.10.0.zip heruntergeladen werden kann.

Dieses Release enthält als wichtigste Verbesserungen:

- Neues System für die Dokumentation: http://cometvisu.org/CometVisu/de/latest/manual/
- Neues Plugin: powerspectrum
- Neues Plugin: text to speech
- Erweiterung des Config-Managers, um auch Mediendateien (beispielsweise für Hintergrundbilder) verwalten zu können
- Deutliche Verkürzung der Ladezeiten durch lokales Cachen (über den enableCache URL-Parameter einstellbar)
- Aktualisierte Icons
- Sicherstellung der Codequalität durch Einführung von Unit Tests
- Viele behobene Fehler

Die letzten Änderungen stehen im Change Log unter https://raw.githubusercontent.com/Co...10.0/ChangeLog

Was wir jetzt noch an Bugs finden und lösen wandert dann in eine 0.10.1

[itarch]

Tja, nun muß ich doch Gesagtes in #53 und #56 mehr oder weniger revidieren.

Was ist passiert? Ich habe hier aufgeräumt/umgebaut und dabei folgendes festgestellt.

Die Testumgebung B[RPI3, Jessie, knxd 0.12.14, CV 0.10.0-RC3] scheint wohl ohne die (alte) Produktivumgebung A[RPI, Wheezy, eibd 0.0.4, CV 0.9.2] im Bezug auf die Visualisierung (=CV...) nicht zu funktionieren.

Wenn ich B alleine betreibe sehe ich keine Statie in der CometVisu (0.10.0-RC3)
Wenn ich neben B auch A starte, dann sehe ich Statie in der CV(, die auf B läuft).

In der Testumgebung B läuft unter anderem linknx 0.0.1.33, die Kommunikation zum Bus erfolgt über das TUL device, über das KNXD 0.12.14 sehr wohl funktioniert, da bspw Linknx fleißig mithört und protokolliert. Das funktioniert auch dann wenn die Umgebung A nicht gestartet ist. Klar der Kommunikationsweg ist hier ein anderer, will aber sagen, dass KNXD in Kombination mit TUL und auf Port localhost:6720 geht.

Ist es richtig, dass für die CV dem KNXD in /etc/knxd.conf der Parameter -u /tmp/eib hinzugefügt werden muß?
Apache2 läuft unter www-data. Muß die Gruppe www-data rwx auf /tmp/eib haben?
Was mich wunder ist, wenn ich http://192.168.1.30/cgi-bin/r in Chrome eingebe sehe ich folgenden Output.
CV-CGI-OUT.png

Das sieht doch nach Daten aus, die aber in der Visualisierung nicht angezeigt werden!?!?

Was kann ich nun checken/bereitstellen um die Fehlersuche zu unterstützen?

[Chris M.]

Mit dem knxd kenne ich mich leider nicht wirklich aus. Der eibread-cgi.c Code dort schaut in "local:/run/knx" (früher "local:/tmp/eib") nach der Verbindung zum knxd.
=> Ich vermute Du brauchst den Parameter -u /run/knx

Der Output im Screenshot schaut jedoch richtig aus - bis auf dass ich bei einem leeren Aufruf von r eigentlich eine etwas andere Antwort erwartet hätte...: {'error': 'No data'}

[itarch]

Chris M. den Parameter -u /run/knx kann man nicht (so) in die Konfigurationsdatei einfügen, weil diese Socket per default gesetzt ist. Man kann mit "-u ..." eine weitere Socket hinzufügen. Wie auch immer, deine Bemerkung schließt ne weitere Lücke (bei mir). Ich fass mal (vlt nicht 100% syntaktisch richtig) wie folgt zusammen: Die CV kommuniziert über "l, r, w" mit der KNX Schnittstelle über r=eibread-cgi und für w=eibwrite-cgi. Jetzt steht in diesen zwei CGI-Files (wie Du angemerkt hast) der Hinweis "local:/run/knx". Dieser wird ja auch von KNXD bereitgestellt.
Starte ich also meine Test-Umgebung (RPI3, Jessie, knxd 0.12.14, CV 0.10.0-RC3) neu (Reboot), starte fortfolgend Chrome, greife auf die CV zu, dann sehe ich (im ETS-5-Gruppenmonitor) wie lauter viele GroupValueRead und GroupValueResponse über den BUS gehen. Leider kommt keins von diesen Respons in Chrome an. Dann Klicke ich auf einen CV-Widget (Licht) und das ausgewählte Licht geht aus. Kommunikation mit eibwrite-cgi scheint also zu gehen. Der Status geht aber nicht auf "AUS". Der Widget bleibt bei "-" stehen.

Merkwürdig ist auch, dass in Chrome in der Entwicklungsumgebung, Reiter Network, Reiter Headers der lange Read-Aufruf angezeigt wird, aber unter Reiter Preview und Response steht "This request has no preview/response available".

So und wenn ich jetzt die alte Produktionsumgebung - eibd.0.0.4 - hochfahre, warte ein wenig, dann tauchen auch die lang ersehnten Statie auf. In einem weiteren putty fenster sieht man kurz bevor die Statie kommen folgenden KNXD Film

# sudo journalctl -u knxd -f
...
Mar 08 11:57:48 RASP3BII knxd[11397]: knxd: Layer 4 [ 3:cache            5985.258] GroupCache found: 1.0.17
Mar 08 11:57:48 RASP3BII knxd[11397]: knxd: Layer 4 [ 3:cache            5985.258] GroupCacheRead 5/0/20 1 0
Mar 08 11:57:48 RASP3BII knxd[11397]: knxd: Layer 4 [ 3:cache            5985.258] GroupCache found: 1.1.240
Mar 08 11:57:48 RASP3BII knxd[11397]: knxd: Layer 4 [ 3:cache            5985.258] GroupCacheRead 5/1/2 1 0
Mar 08 11:57:48 RASP3BII knxd[11397]: knxd: Layer 4 [ 3:cache            5985.258] GroupCache found: 1.0.10
Mar 08 11:57:48 RASP3BII knxd[11397]: knxd: Layer 4 [ 3:cache            5985.259] GroupCacheRead 5/1/4 1 0
Mar 08 11:57:48 RASP3BII knxd[11397]: knxd: Layer 4 [ 3:cache            5985.259] GroupCache found: 1.0.10
Mar 08 11:57:48 RASP3BII knxd[11397]: knxd: Layer 4 [ 3:cache            5985.259] GroupCacheRead 5/1/6 1 0
Mar 08 11:57:48 RASP3BII knxd[11397]: knxd: Layer 4 [ 3:cache            5985.259] GroupCache found: 1.0.10
Mar 08 11:57:48 RASP3BII knxd[11397]: knxd: Layer 4 [ 3:cache            5985.259] GroupCacheRead 5/1/8 1 0
Mar 08 11:57:48 RASP3BII knxd[11397]: knxd: Layer 4 [ 3:cache            5985.259] GroupCache found: 1.0.10
...

Und in Chrome ... Reiter Preview und oder Response sieht man jetzt Inhalt und nicht "This request has no preview/response available"

Anbei auch die Konfiguration des eibd.0.0.4:

# cat /etc/default/eibd
EIBD_BACKEND_ADDR = 1.0.252
EIBD_BACKEND = ipt
EIBD_PORT_IP = 224.0.23.12
EIBD_PORT_IPT = 192.168.1.11
EIBD_T = y
EIBD_R =
EIBD_I = y
EIBD_C = y

mglw. muß hier auch Smurf vorbeischauen...