CometVisu auf weiterer Hardware

[Chriko]

Nein, leider noch nicht. Ich hänge mit der "l" Datei. Muß ich die selber erstellen? Wenn ja, ist der Inhalt so richtig:
GET /l?u=USER&p=PASSWORD&d=DEVICE
Habe sie derzeit im selben Ordner wie eibwrite und eibread und symlink im cgi ordner.
Hab davon leider Null Ahnung daher tüftel ich jetzt schon den ganzen Abend daran und hoffe auf einen Geistesblitz.

[umatz]

Kann es sein, dass Du eine veraltete eibd Version benutzt?

admin@dockster:/var/log$ eibd --version
eibd 0.0.4

Trotzdem vielen Dank schon mal für Deine Unterstützung.

Chriko, bist Du schon weiter?

[Chris M.]

OK, damit ist der Bereich meines Wissens verlassen...

Kann es sein, dass Du eine veraltete eibd Version benutzt?

Falls nein, hoffe ich mal das Makki hier weiterhelfen kann. Da im Backend innen kenne ich mich kaum aus

[umatz]

OK, was macht ein

grouplisten local:/tmp/eib 12/7/1

Und ein paar mal klicken auf den Button oben links oder sonst wie auf die 12/7/1 ein paar Pakete schicken.

Ausführen des von Dir genannten Kommandos und ein paar Klicks auf den switch oben links:

admin@dockster:/var/log$ grouplisten local:/tmp/eib 12/7/1
Write from 15.15.2: 00
Write from 15.15.2: 00
Write from 15.15.2: 00
Write from 15.15.2: 00
Write from 15.15.2: 00

[Chris M.]

OK, was macht ein

grouplisten local:/tmp/eib 12/7/1

Und ein paar mal klicken auf den Button oben links oder sonst wie auf die 12/7/1 ein paar Pakete schicken.

[umatz]

Im eibd.log auf der Kiste siehst du die Busaktivitäten aber schon?

Mein eibd.log ist seltsamerweise immer leer, obwohl ich eibd mit

usr/bin/eibd --daemon=/var/log/eibd.log [...]

starte.

Ich kann aber wie oben schon angeführt andere eibd-tools (wie z.B. groupreadresponse) erfolgreich ausführen.

[umatz]

Hast Du den Socket /tmp/eib?

Probier mal in der Shell den Befehl

groupcacheread local:/tmp/eib 12/7/1

Was kommt da als Ausgabe?

Ja, ich verwende den socket in /tmp/eib, aber:

admin@dockster:~$ groupcacheread local:/tmp/eib 12/7/1
Read failed: No such device

Hingegen:

admin@dockster:~$ groupread local:/tmp/eib 12/7/1
Send request

[greentux]

Im eibd.log auf der Kiste siehst du die Busaktivitäten aber schon?

[Chris M.]

Firefox mit Firebug:

200 OK

Der Antwort-Body ist leer.

OK, dann scheint es irgendwo im Backend zu hängen.

Hast Du den Socket /tmp/eib?

Probier mal in der Shell den Befehl

groupcacheread local:/tmp/eib 12/7/1

Was kommt da als Ausgabe?

Ich hätte da noch mal eine Frage zur Installation.
Ich habe die modifizierten eibd Pakete installiert - also mit eibwrite/read und er läuft auch. Dann habe ich xampp installiert. Die symlinks kommen in den "visu"ordner oder wohin? Und was hat es mit der dummylogin datei aufsich.
War meine vorgehensweise denn sonst richtig?

Der Dummy-Login ist die (Dummy) Routine für den "l" Befehl.
Vgl. dazu auch SourceForge.net: CometVisu/Protocol - Open Automation

Im Grunde musst Du nun dafür sorgen, dass die CometVisu beim normalen Zugriff über HTTP die drei Befehle "l", "r" und "w" erreicht. Diese müssen in der normalen Config im CGI-BIN-Verzeichnis liegen, d.h. erreichbar sein unter:

http://wiregate/cgi-bin/l

(Ob Du dass per Link machst oder Web-Server-Config ist egal, der HTTP-Request muss halt funktionieren...)

[Chriko]

Ich hätte da noch mal eine Frage zur Installation.
Ich habe die modifizierten eibd Pakete installiert - also mit eibwrite/read und er läuft auch. Dann habe ich xampp installiert. Die symlinks kommen in den "visu"ordner oder wohin? Und was hat es mit der dummylogin datei aufsich.
War meine vorgehensweise denn sonst richtig?

[umatz]

Firefox mit Firebug:

200 OK

Der Antwort-Body ist leer.

[Chris M.]

OK, dann nimm mal bitte einen Browser mit ordentlichem JavaScript Debugging (z.B. Firefox mit der Erweiterung Firebug) und schau mal was als Antwort auf den Read-Request kommt.

[umatz]

Öffne die Widget-Demo und schreibe mal per ETS an die 12/7/1 den Wert 0 oder 1 (DPT 1, Ein/Aus).

Wenn dann der Switch links oben seinen Status wechselt, dann läuft schon alles. Wenn nicht, dann suchen wir etwas tiefer weiter.

Richtig, ich teste mit der Widget-Demo und die Adressen sind in meinem Projekt unbelegt.
Der Switch ändert seinen Status nicht, wenn ich an 12/7/1 0 oder 1 schreibe.

[Chris M.]

Da ich ein eibd-Paket von makki verwendet habe, sind auch die für die CometVisu notwendigen Erweiterungen (eibread/write-cgi) und symbolischen Links vorhanden.

Diese beiden Extras sind für die CometVisu essentiell - wer die CometVisu selber einrichten möchte muss auf die unbedingt Acht geben. Und dafür sorgen, dass die als "r" und "w" per HTTP erreichbar sind (wie auf der Homepage beschrieben)

Grundsätzlich wird die Visu in meinem Browser angezeigt und bei einem Klick auf einen Switch kann ich im Busmonitor auch ein entsprechendes Telegramm sehen.

Sehr gut, damit kann die finale Lösung nicht mehr weit sein.

Allerdings sehe ich kein einziges Telegramm, welches die lesenden Aktivitäten der Visu (bzw. des KNX-Backends) widerspiegelt und es werden auch keine Statusinformationen in der Visu aktualisiert.
In meinem http-access-log sehe ich ungefähr sekündliche Aufrufe des Backends, die vermutlich der Aktualisierung der Visu-Status dienen:

192.168.178.20 - - [02/Dec/2011:17:37:13 +0100] "GET /cgi-bin/r?
s=SESSION&a=12/7/1&a=12/7/1&a=12/7/1&a=12/7/20&a=12/7/20&a=12/7/5&
a=12/7/9&a=12/7/105&a=12/7/16&a=12/7/16&a=12/7/1&a=12/7/16&a=12/7/5
&a=12/7/9&a=12/7/9&a=12/7/9&a=12/7/9&a=12/7/9&a=12/7/9&a=12/7/9&
a=12/7/9&a=12/7/9&a=12/7/9&a=12/7/9&a=12/7/9&a=12/7/9&a=12/7/9&a=12/7/9&
a=12/7/9&a=12/7/50&a=12/7/51&a=12/7/52&a=12/7/50&a=12/7/50&a=12/7/51&
a=12/7/51&a=12/7/52&a=12/7/52&a=12/7/9&a=12/7/9&a=12/7/9&t=0 ..."

Muss ich den eibd mit anderen Parametern starten, damit auch die Leseanforderungen auf den Bus weitergegeben werden?

Der Request sieht normal aus. Die angefragten Adressen sehen nach denen aus der Widget-Demo aus, die bewusst so gewählt wurden, dass die in vielen KNX-Installationen hoffentlich unbenutzt sind.

Daher, bevor wir mal tief in sonstige Fehlersuche einsteigen, mach doch mal ein ganz einfachen Versuch:
Öffne die Widget-Demo und schreibe mal per ETS an die 12/7/1 den Wert 0 oder 1 (DPT 1, Ein/Aus).

Wenn dann der Switch links oben seinen Status wechselt, dann läuft schon alles. Wenn nicht, dann suchen wir etwas tiefer weiter.

Mir fällt gerade auf, dass bei dem oben angezeigten Request keine SessionId übergeben wird, bei den erfolgreichen Write-Requests dagegen schon.
Ist das das Problem? Und wie kann ich es beheben?

Das ist kein Problem, die aktuelle Implementierung des Backends verwendet keine Session-ID.

[umatz]

Hallo Chriko,

makki hatte auch mal mit der Dockstar gespielt und debian-Pakete vom eibd und den wesentlichen Voraussetzungen für die armel-Architektur gebaut (siehe hier).

Die Pakete enthalten auch die im README der CometVisu genannten Extras:

*** Important note on diagram-backend ***
It uses a modified version of rrdtool, adding a "fetchj" option.
You can find source and Debian-packages here:
http://repo.wiregate.de/wiregate/pool/main/r/
http://repo.wiregate.de/wiregate/pool/main/libr/

*** Notes on the KNX-backend ***
The KNX-backend uses
/usr/lib/cgi-bin/l : a dummy-login
/usr/lib/cgi-bin/r : a symlink to /usr/bin/eibread-cgi
/usr/lib/cgi-bin/w : a symlink to /usr/bin/eibwrite-cgi
eibread/write-cgi are part of a modified eibd-clients package here:
http://repo.wiregate.de/wiregate/pool/main/e/
(source: bcusdk)

Greetinx,
Udo