Ankündigung

Einklappen
Keine Ankündigung bisher.

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

Einklappen
X
 
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • pitschr
    antwortet
    Ich habe auch ähnliche Probleme mit meiner Podman (ist ähnlich wie Docker) gehabt und habe wie folgt gelöst. Die eigene CometVisu-Designs sollte man ausserhalb von Docker speichern, da jegliche Änderungen beim Neustart verloren gehen würde. Meine eigene Customizations / Designs habe ich unter /root/cometvisu-0.11.2/resource

    Code:
    podman run --rm -d -p=8888:80 --name cometvisu \
    --env KNX_INTERFACE=iptn:192.168.1.16 \
    --volume=/root/cometvisu-0.11.2/resource:/var/www/html/resource:Z \
    --volume=/root/cometvisu-0.11.2/resource/config:/var/www/html/resource/config:Z \
    cometvisu/cometvisu:0.11.2
    
    # Fix wrong design lookup by CometVisu
    podman exec cometvisu ln -s resource/designs designs
    In meinem Fall greife ich mit http://192.168.1.4:8888/ auf CometVisu. MDT Router hat die IP Adresse (statisch): 192.168.1.16. An KNXD o.ä. musste ich gar nicht ran.
    In deinem Fall probier mal zuerst mit (sofern IP Adresse 192.168.170.223 noch gültig ist):

    Code:
    docker run --rm -d -p=8888:80 --name cometvisu \
    --env KNX_INTERFACE=iptn:192.168.170.223 \
    cometvisu/cometvisu:0.11.2
    Falls du einen Firewall hast, dann könnte er auch daran hindern /tmp/eib anzulegen. In dem Fall muss KNX Port (3671/udp) freigeschaltet werden. Unter CentOS 8 (ich habe kein Raspberry) wäre die Firewall Regel wie folgt:
    Code:
    echo -n "Creating firewall service 'knx' ... "
    firewall-cmd -q --permanent --new-service=knx
    firewall-cmd -q --permanent --service=knx --set-description="KNXnet/IP is a part of KNX standard for transmission of KNX telegrams via Ethernet"
    firewall-cmd -q --permanent --service=knx --set-short=KNX
    firewall-cmd -q --permanent --service=knx --add-port=3671/udp
    echo "DONE"
    
    echo -n "Registering firewall service 'knx' to current zone ... "
    firewall-cmd -q --permanent --add-service=knx
    echo "DONE"
    KNX Firewall Regel aktivieren:
    Code:
    echo -n "Firewall service will be reloaded ... "
    firewall-cmd -q --reload
    echo "DONE"

    Einen Kommentar schreiben:


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

    Einen Kommentar schreiben:


  • Chris M.
    antwortet
    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)

    Einen Kommentar schreiben:


  • netfriend
    antwortet
    Zitat von Tontechniker Beitrag anzeigen
    By the way! Hat der Raspi eine ausreichende Stromversorgung?
    Ich gehe davon aus. Ich verwende das original Netzteil und habe keine Peripherie angeschlossen.

    Einen Kommentar schreiben:


  • Tontechniker
    antwortet
    By the way! Hat der Raspi eine ausreichende Stromversorgung?

    Einen Kommentar schreiben:


  • Chris M.
    antwortet
    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.

    Einen Kommentar schreiben:


  • netfriend
    antwortet
    Zitat von Chris M. Beitrag anzeigen
    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:
    Code:
    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.

    Zitat von Chris M. Beitrag anzeigen
    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?

    Einen Kommentar schreiben:


  • Chris M.
    antwortet
    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:
    Code:
    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

    Einen Kommentar schreiben:


  • netfriend
    antwortet
    Zitat von Chris M. Beitrag anzeigen
    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:
    Code:
    # 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:

    Code:
    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?


    Zitat von Chris M. Beitrag anzeigen
    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'}"


    Zitat von Chris M. Beitrag anzeigen
    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:

    Code:
    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!

    Einen Kommentar schreiben:


  • Chris M.
    antwortet
    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:
    Code:
    # 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

    Einen Kommentar schreiben:


  • netfriend
    antwortet
    Danke Chris für Deine Bemühungen !!!

    Zitat von Chris M. Beitrag anzeigen
    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.

    Zitat von Chris M. Beitrag anzeigen
    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 :-)

    Zitat von Chris M. Beitrag anzeigen
    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...

    Einen Kommentar schreiben:


  • Chris M.
    antwortet
    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 ?

    Einen Kommentar schreiben:


  • netfriend
    antwortet
    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

    Einen Kommentar schreiben:


  • netfriend
    antwortet
    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?

    Einen Kommentar schreiben:


  • Chris M.
    antwortet
    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:
    Code:
    Content-Type: text/plain
    
    {'error': 'Open failed'}

    Einen Kommentar schreiben:

Lädt...
X