Neuinstallation von CV 0.11.2 auf Raspi - was muss alles installiert werden?

[netfriend]

Ja, Deine Verbindung zum knxd funktioniert anscheinend nicht.

Mit dem knxd 0.14.29-5 habe ich keine Erfahrung (genauer: für mich ist der 0.0.5 sehr stabil und später wurde dort ein Bug eingebaut durch den die CometVisu nicht mehr funktioniert hatte - keine Ahnung ob der inzwischen behoben wurde). Aber ist der Socket vom knxd korrekt erzeugt? Findet den das eibread-cgi (also der Symlink für den "r") auch?

Kannst Du mir bitte schreiben, wie man den Socket korrekt erzeugt bzw. wie man prüfen kann, ob er das eibread-cgi auch findet?
Nachdem Du den knxd 0.0.5 verwendest, weißt Du ja auch, wie man den installiert. Kannst Du das kurz beschreiben?
Denn auf github finde ich die Version 0.0.5 vom knxd gar nicht mehr und die Installationsanleitung hat sich über die Versionen wohl auch etwas verändert.
Wäre prima, dann kann ich mal checken ob das alles läuft wie es soll.
Vielen Dank.

[Chris M.]

Die beste und einfachste Möglichkeit ist inzwischen das ganze über Docker laufen zu lassen, vgl. z.B. das Tutorial für den Raspberry Pi https://www.cometvisu.org/CometVisu/...cometvisu.html
Die Erzeugung des Docker-Images (also das Docker File) geschieht durch: https://github.com/CometVisu/Docker/...ckerfile.cross - hier kannst Du auch sehen wie der knxd heruntergeladen, erzeugt und im Anschluss "installiert" wird.

Wenn der eibread-cgi den Socket nicht findet, dürfte als Antwort kommen:

Content-Type: text/plain

{'error': 'Open failed'}

[netfriend]

Die CometVisu-Docker-Version hab ich schon zum Laufen gebracht - mit all den Tücken und Vor- und Nachteilen.

Deshalb versuche ich nochmal auf meinem Spiel-Raspi eine saubere Neuinstallation hinzubekommen.
Nachdem der aktuelle knxd 0.14.xx wohl immer noch Probleme in Verbindung mit der CometVisu macht (ich habe jedenfalls nichts Gegenteiliges gelesen), würde ich den knxd 0.0.5.1 nutzen wollen, der im Container wohl gut läuft.

Ich hab mir das Dockerfile.cross angesehen und die mir wichtig erscheinenden Passagen (# Compile knxd 0.0.5.1, # build pthsem, # build knxd) händisch ausgeführt. Es ist alles ohne Fehler durchgelaufen. Auch in der readme.md vom knxd-0.0.5.1 steht nichts zusätzliches drin, was noch erforderlich wäre.

Nun finde ich weder eine knxd.conf, wo ich die IP-Adresse meines Interfaces eintragen kann, noch läuft der knxd. Auch die eibread-cgi und eibwrite-cgi finde ich nirgends.
Hab ich irgendwas vergessen?

Auch den Test mit knxtool kann ich nicht machen, da er knxtool nicht findet.
Eine Installation mit "apt-get install knxd-tools" schlägt fehl: "E: Unable to locate package knxd-tools".

Hat jemand ne Idee?

[netfriend]

So, nach unermüdlichen Versuchen sehe ich folgendes:

knxd error read.JPG

gestartet hab ich den knxd so:

knxd -i iptn:192.168.170.223:3671 -e 1.1.225 -u/tmp/eib -d -c

Die Verbindung zum KNX besteht wohl, denn nach dem Start sehe ich am IP-Interface, dass eine Verbindung belegt wurde. Stoppe ich den daemon wieder, wird die Verbindung wieder freigegeben. Daher sollte das passen.

Aber so wie Chris schreibt, dürfte mit dieser Meldung der/die/das eibread-cgi den socket nicht finden.

Konkret habe ich
eibread-cgi und eibwrite-cgi aus dem knxd-0.0.5.1-Verzeichnis nach \usr\bin kopiert
/usr/lib/cgi-bin/r : symlink to /usr/bin/eibread-cgi erstellt
/usr/lib/cgi-bin/w : symlink to /usr/bin/eibwrite-cgi erstellt
usr/lib/cgi-bin/l : Datei erstellt mit folgendem Inhalt:

#!/bin/sh
echo Content-Type: text/plain
echo

echo "{ "v":"0.0.1", "s":"SESSION" }"

Sicherheitshalber habe ich diesen Dateien und dem Comet-Visu-Verzeichnis chmod 0777 gegeben.

Was mache ich falsch bzw. kann ich prüfen?
Das kann doch nicht so schwer sein, dass Ding zum Laufen zu bringen. Ich verzweifel bald...an mir selbst

[Chris M.]

Grundsätzlich sieht das schon mal richtig aus.

Wird denn in /tmp/ der Socket /tmp/eib erzeugt? Welchen Eigentümer und welche Berechtigungen hat der? Unter welchem Eigentümer wird darauf zugegriffen?
Hast Du dem Socket auch noch die Schreibrechte eingestellt, vgl. https://github.com/CometVisu/Docker/...entrypoint#L15 ?

[netfriend]

Danke Chris für Deine Bemühungen !!!

Grundsätzlich sieht das schon mal richtig aus.

Wird denn in /tmp/ der Socket /tmp/eib erzeugt? Welchen Eigentümer und welche Berechtigungen hat der?

Es ist in /tmp eine Datei "eib" vorhanden. Ich nehme an, es ist der Socket. Wer den erstellt hat oder durch was der erstellt wurde, weiß ich nicht.
Gruppe/Eigentümer ist "root", Berechtigung ist 0755.

Unter welchem Eigentümer wird darauf zugegriffen?

Wer greift darauf zu? Ist das eibread-cgi und eibwrite-cgi? Falls ja, wie ist da der Zusammenhang? Woher wissen die voneinander bzw. wo die zu finden sind?

Falls es eibread-cgi und eibwrite-cgi sind, die liegen in /usr/bin und Gruppe/Eigentümer ist "root", Berechtigung 0777.
Falls ich falsch liege, bitte erklären :-)

Hast Du dem Socket auch noch die Schreibrechte eingestellt, vgl. https://github.com/CometVisu/Docker/...entrypoint#L15 ?

Nein, hatte ich vergessen. Habe nun

chmod a+w /tmp/eib

nachgeholt. Jetzt steht die Berechtigung auf 0777.


Ändert aber leider nichts daran, die Fehlermeldung bleibt dieselbe.
Auf die Anfrage "r?t=0&s=SESSION&a=3/1/6&a=3/1/7&a=10/5/0&a=10/5/1" kommt nach wie vor die Response "{'error': 'Open failed'}"
Ich habe in die mitgelieferte visu_config.xml zwei Switch eingefügt mit diesen GAs.
Jetzt fehlt nur noch die Antwort...

[Chris M.]

Auch wenn die Dateien eibread-cgi/eibwrite-cgi dem root gehören, sobald diese ausgeführt werden läuft der Prozess unter dem Account des ausführenden. Das ist normalerweise der Web-Server, also z.B. "www-data". Beispiel von meinem Test-Container:

# ps aux
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 1 0.0 0.2 83576 11424 ? Ss Jun01 6:40 apache2 -DFOREGROUND
root 7 0.4 0.0 6768 1980 ? Ss Jun01 264:44 knxd -i iptn:172.17.0.1:3700 -e 1.1.238 -u -d/var/log/eibd.log -c
root 11 0.0 0.0 15852 2788 ? Ss Jun01 0:00 /usr/sbin/sshd
root 2769 0.8 0.0 3996 3372 pts/0 Ss 21:29 0:00 bash
www-data 2788 0.0 0.0 2788 740 ? S 21:29 0:00 /usr/lib/cgi-bin/r
root 2789 0.0 0.0 7636 2776 pts/0 R+ 21:29 0:00 ps aux
www-data 4184 0.0 0.3 84552 13564 ? S Jun03 2:52 apache2 -DFOREGROUND
www-data 12763 0.0 0.1 84128 7040 ? S Jun06 0:16 apache2 -DFOREGROUND
www-data 17919 0.0 0.3 84504 14116 ? S Jun05 1:16 apache2 -DFOREGROUND
...

Bis auf den 'Open failed' Fehler sieht das bei Dir schon alles richtig aus.

Grundsätzlich ist bei der Fehlersuche es auch einfacher mit einem Write zu testen als mit einem Read. Das Read muss ja eine Verbindung aufbauen und offen halten, da können verschiedene Sachen schief laufen. Beim Write wird nur ein simpler GET abgesetzt und fertig. Den kann man am einfachsten mit einem Trigger testen, da der keinen Zustand hat, der ja vorher über den Bus kommen sollte.

Ansonsten, um noch etwas näher beim eibd/knxd zu suchen, ob da die Verbindung passt:
In den Container wird ja mit https://github.com/CometVisu/Docker/...file.cross#L67 die Latte der Busmonitore so wie groupwrite und groupread bereitgestellt.
=> Funktioniert bei Dir denn vbusmonitor1time local:/tmp/eib ? Hier solltest Du alles sehen was am Bus passiert

[netfriend]

Auch wenn die Dateien eibread-cgi/eibwrite-cgi dem root gehören, sobald diese ausgeführt werden läuft der Prozess unter dem Account des ausführenden. Das ist normalerweise der Web-Server, also z.B. "www-data". Beispiel von meinem Test-Container:

# ps aux
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 1 0.0 0.2 83576 11424 ? Ss Jun01 6:40 apache2 -DFOREGROUND
root 7 0.4 0.0 6768 1980 ? Ss Jun01 264:44 knxd -i iptn:172.17.0.1:3700 -e 1.1.238 -u -d/var/log/eibd.log -c
root 11 0.0 0.0 15852 2788 ? Ss Jun01 0:00 /usr/sbin/sshd
root 2769 0.8 0.0 3996 3372 pts/0 Ss 21:29 0:00 bash
www-data 2788 0.0 0.0 2788 740 ? S 21:29 0:00 /usr/lib/cgi-bin/r
root 2789 0.0 0.0 7636 2776 pts/0 R+ 21:29 0:00 ps aux
www-data 4184 0.0 0.3 84552 13564 ? S Jun03 2:52 apache2 -DFOREGROUND
www-data 12763 0.0 0.1 84128 7040 ? S Jun06 0:16 apache2 -DFOREGROUND
www-data 17919 0.0 0.3 84504 14116 ? S Jun05 1:16 apache2 -DFOREGROUND
...

So siehts bei mir aus, allerdings hab ich aus ca. 120 Zeilen die (hoffentlich) interessanten rauskopiert. Was mir auffällt: /usr/lib/cgi-bin/r gibts bei mir nicht.
Das ist alles was mit apache, knxd, eib, cgi-bin usw. zu tun hat:

root@raspi4b:~# ps aux
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
www-data   351  0.7  0.1 191776  6108 ?        S    18:49   0:02 /usr/sbin/apache2 -k start
root       579  0.0  0.4 191704 16932 ?        Ss   Jul13   0:06 /usr/sbin/apache2 -k start
root      1984  0.1  0.0   4616  1828 ?        Ss   Jul13   1:50 knxd -i iptn:192.168.170.223:3671 -e 1.1.225 -u/tmp/eib -d -c
www-data 29978 0.0 0.1 191776 6108 ? S 00:00 0:03 /usr/sbin/apache2 -k start
www-data 29981 0.0 0.1 191776 6108 ? S 00:00 0:03 /usr/sbin/apache2 -k start
www-data 29982 0.0 0.1 191776 6108 ? S 00:00 0:02 /usr/sbin/apache2 -k start
www-data 29983 0.0 0.1 191776 6108 ? S 00:00 0:03 /usr/sbin/apache2 -k start
www-data 29984 0.0 0.1 191776 6108 ? S 00:00 0:02 /usr/sbin/apache2 -k start

Siehst Du hier nen Fehler? Muss man /usr/lib/cgi-bin/r manuell starten?

Bis auf den 'Open failed' Fehler sieht das bei Dir schon alles richtig aus.

Grundsätzlich ist bei der Fehlersuche es auch einfacher mit einem Write zu testen als mit einem Read. Das Read muss ja eine Verbindung aufbauen und offen halten, da können verschiedene Sachen schief laufen. Beim Write wird nur ein simpler GET abgesetzt und fertig. Den kann man am einfachsten mit einem Trigger testen, da der keinen Zustand hat, der ja vorher über den Bus kommen sollte.

Ich hab in meiner visu das dahingehend geändert, dass ich nur 2 Trigger eingebaut habe. Gehen auf die selbe GA, einmal mit 0 und einmal mit 1. Die Visu lädt nun ohne Fehler, da ja kein read ausgeführt wird. Sendet man einen write Befehl mittels Trigger sehe ich das in den Entwicklertools:

w?s=SESSION&a=10/5/0&v=81&ts=1626283509586" und als Reponse kommt nach wie vor: "{'error': 'Open failed'}"

Ansonsten, um noch etwas näher beim eibd/knxd zu suchen, ob da die Verbindung passt:
In den Container wird ja mit https://github.com/CometVisu/Docker/...file.cross#L67 die Latte der Busmonitore so wie groupwrite und groupread bereitgestellt.
=> Funktioniert bei Dir denn vbusmonitor1time local:/tmp/eib ? Hier solltest Du alles sehen was am Bus passiert

Hab ich probiert. Ich hatte schon alle angegebenen Dateien nach /usr/local/bin kopiert. Nachdem "Permission denied" kam, habe ich den Dateien die Berechtigung 0777 gesetzt. Danach gings:

root@raspi4b:~# vbusmonitor1time local:/tmp/eib
-bash: /usr/local/bin/vbusmonitor1time: Permission denied
root@raspi4b:~# vbusmonitor1time local:/tmp/eib
2021-07-14 19:01:49.675
19:01:52.112 LPDU: BC 11 FA 0C 01 F3 00 80 14 1A D8 :L_Data low from 1.1.250 to 1/4/1 hops: 07 T_DATA_XXX_REQ A_GroupValue_Write 14 1A
19:01:52.742 LPDU: BC 11 C9 0D 1F E5 00 80 43 84 80 00 AB :L_Data low from 1.1.201 to 1/5/31 hops: 06 T_DATA_XXX_REQ A_GroupValue_Write 43 84 80 00
19:01:52.966 LPDU: BC 11 C9 0D 1E E5 00 80 00 00 23 E9 27 :L_Data low from 1.1.201 to 1/5/30 hops: 06 T_DATA_XXX_REQ A_GroupValue_Write 00 00 23 E9
19:01:54.074 LPDU: BC 11 14 08 08 E3 00 80 26 62 61 :L_Data low from 1.1.20 to 1/0/8 hops: 06 T_DATA_XXX_REQ A_GroupValue_Write 26 62
19:01:54.107 LPDU: BC 11 14 08 02 E1 00 81 2C :L_Data low from 1.1.20 to 1/0/2 hops: 06 T_DATA_XXX_REQ A_GroupValue_Write (small) 01
19:01:54.427 LPDU: BC 11 06 14 00 E3 00 80 00 3C 1F :L_Data low from 1.1.6 to 2/4/0 hops: 06 T_DATA_XXX_REQ A_GroupValue_Write 00 3C
19:01:55.706 LPDU: BC 11 54 73 00 E3 00 80 0C 4E 54 :L_Data low from 1.1.84 to 14/3/0 hops: 06 T_DATA_XXX_REQ A_GroupValue_Write 0C 4E
19:01:56.522 LPDU: BC 11 30 38 03 E3 00 80 0C 73 45 :L_Data low from 1.1.48 to 7/0/3 hops: 06 T_DATA_XXX_REQ A_GroupValue_Write 0C 73
19:01:56.574 LPDU: BC 11 21 45 00 E3 00 80 0C 77 2E :L_Data low from 1.1.33 to 8/5/0 hops: 06 T_DATA_XXX_REQ A_GroupValue_Write 0C 77
19:01:58.388 LPDU: BC 11 0C 3E 00 E3 00 80 0C BA B5 :L_Data low from 1.1.12 to 7/6/0 hops: 06 T_DATA_XXX_REQ A_GroupValue_Write 0C BA
19:01:58.565 LPDU: BC 11 02 0C 0A E3 00 80 15 28 08 :L_Data low from 1.1.2 to 1/4/10 hops: 06 T_DATA_XXX_REQ A_GroupValue_Write 15 28
19:01:58.741 LPDU: BC 11 C9 0D 1F E5 00 80 43 82 80 00 AD :L_Data low from 1.1.201 to 1/5/31 hops: 06 T_DATA_XXX_REQ A_GroupValue_Write 43 82 80 00
19:01:58.966 LPDU: BC 11 C9 0D 1E E5 00 80 00 00 23 E9 27 :L_Data low from 1.1.201 to 1/5/30 hops: 06 T_DATA_XXX_REQ A_GroupValue_Write 00 00 23 E9
19:01:59.289 LPDU: BC 11 0C 42 00 E3 00 80 0C 47 34 :L_Data low from 1.1.12 to 8/2/0 hops: 06 T_DATA_XXX_REQ A_GroupValue_Write 0C 47

Ich denke, knxd mit dem Bus funktioniert, aber CometVisu mit knxd nicht.
Hast Du noch ne Idee? Danke!

[Chris M.]

Dass Du kein r siehst ist nicht überraschend, Du müsstest in genau dem Sekundenbruchteil ps ausführen wenn der Read-Request kommt. Und die Chance das wirklich zu sehen gibt's erst wenn alles läuft und der r so lange offen gehalten wird, bis eine neue Bus-Antwort an die Visu übermittelt werden soll.

Der ps sieht passend aus. Web-Server läuft als www-data, d.h. der eibwrite-cgi wird auch mit den User www-data ausgeführt.

OK, aber halten wir mal fest:
Busmonitor geht => der knxd funktioniert und hat eine Verbindung zum KNX
Der w hat "Open failed" => der eibwrite-cgi kann nicht auf den Socket zugreifen => entweder sucht der den an einer anderen Stelle oder die Zugriffsrechte passen nicht

Um zu klären ob es ein Berechtigungsproblem ist kannst Du den Monitor ja mal unter dem entsprechenden User ausführen:

su www-data -s /bin/bash -c 'vbusmonitor1time local:/tmp/eib'

Und um zu klären nach welcher Datei gesucht wird kannst Du in den Source Code schauen. Aber wenn Du die 0.0.5.1 Zip Datei nutzt muss es local:/tmp/eib sein, vgl. auch https://github.com/knxd/knxd/blob/0....ite-cgi.c#L227

[netfriend]

OK, aber halten wir mal fest:
Busmonitor geht => der knxd funktioniert und hat eine Verbindung zum KNX
Der w hat "Open failed" => der eibwrite-cgi kann nicht auf den Socket zugreifen => entweder sucht der den an einer anderen Stelle oder die Zugriffsrechte passen nicht

Um zu klären ob es ein Berechtigungsproblem ist kannst Du den Monitor ja mal unter dem entsprechenden User ausführen:

su www-data -s /bin/bash -c 'vbusmonitor1time local:/tmp/eib'

Also, der User www-data darf das nicht (Permission denied), der User pi darf das auch nicht. Der User root darf das.
Hab nochmal die Rechte von /tmp/eib kontrolliert, dort steht 0777. Hab diese nochmal auf was anderes gesetzt und wieder zurückgeändert auf 0777.
Nochmal probiert, Busmonitor läuft unter allen drei Benutzern. Offenbar ist hier beim Setzen der Rechte irgendwas schief gelaufen.

Leider hat sich das Verhalten der CometVisu nicht verändert. Ich starte den im Chrome mit geöffneten Entwicklertools, und "disable Cache" ist aktiviert.

Und um zu klären nach welcher Datei gesucht wird kannst Du in den Source Code schauen. Aber wenn Du die 0.0.5.1 Zip Datei nutzt muss es local:/tmp/eib sein, vgl. auch https://github.com/knxd/knxd/blob/0....ite-cgi.c#L227

Hab ich kontrolliert. In meinem verwendeten knxd-0.0.5.1 steht ebenfalls \tmp\eib als default drin. Außerdem wird der knxd ja mit dem Parameter -u/tmp/eib gestartet, der dürfte das ja nochmal überschreiben.


Nochmal zum Verständnis: r und w liegen in /usr/lib/cgi-bin und zeigen auf /usr/bin/eibread-cgi bzw. /usr/bin/eibwrite-cgi. Passt hier das Verzeichnis /usr/bin? Also genügt es, dass die dort liegen, wohin der Link zeigt oder werden die tatsächlich in /usr/bin erwartet?

[Chris M.]

r und w müssen da liegen, wo der Web-Server sein CGI-BIN sucht - also i.d.R. in /usr/lib/cgi-bin.
Wenn die dort aber physikalisch nicht liegen, sondern das per Symlink gelöst wird ist das auch i.O. - wichtig ist dann, dass der Symlink halt im CGI-BIN Verzeichnis liegt und auf ein Programm verweist das auch existiert. Dazu müssen noch die Datei-Berechtigungen vom Symlink und vom Programm selbst passen.

Das scheint aber bei dir alles schon zu funktionieren, sonst gäbe es keine durch den Programmfluss selbst erstelle Antwort - die gibt es mit {'error': 'Open failed'} aber.

Also bleibt nur noch #1, dass der Socket nicht existiert bzw. an einer Stelle existiert an der nicht gesucht wird. Das haben wir aber mit dem vbusmonitor1time erfolgreich geprüft.

Und #2, dass der Socket zwar passt, aber eben nicht auf diesen zugegriffen werden kann/darf. Das haben wir mit dem su erfolgreich getestet.
Da habe ich jetzt nicht verstanden warum es zuerst nicht ging und dann mit genau der gleichen Berechtigung aber schon. (Evtl. ist hier irgend was grundsätzliches im Argen?)

Wenn das nun alles funktioniert fehlt mir die Phantasie was nun noch das Problem sein kann.

[Tontechniker]

By the way! Hat der Raspi eine ausreichende Stromversorgung?

[netfriend]

By the way! Hat der Raspi eine ausreichende Stromversorgung?

Ich gehe davon aus. Ich verwende das original Netzteil und habe keine Peripherie angeschlossen.

[Chris M.]

Und der andere Klassiker beim RPi: läuft der mit einer SD Karte und könnte die inzwischen eine Macke haben?

(Einen produktiv genutzten RPi sollte man immer nur mit einem stabilen Speichermedium betreiben, SD Karte und USB-Stick scheiden da aus)

[netfriend]

Guter Hinweis. Die SD-Karte ist nagelneu, die hab ich erst vor ein paar Tagen ausgepackt.