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.

[netfriend]

Super, danke für die gute Erklärung. Hat problemlos funktioniert. 👍

[Chris M.]

Die Datei erst mal in den Media-Ordner legen, dann wie im oben verlinkten Handbuch-Ausschnitt beschrieben unter <meta> in der Config-Datei einbinden.
Egal welches Design die Config-Datei auswählt (wie z.B. metal), am Schluss wird die per <meta> eingebundenen CSS-Dateien drüber geladen.

Wenn Docker (z.B. über die docker-compose.yaml) schon so gestartet wird, dass /config auf einem Volume liegt, dann passt alles.
Es ist ja so: dem Docker ist die custom.css egal, der custom.css dagegen nicht (genauer: auch der ist es egal, wenn's Du aber den Container neu lädst, dann ist alles weg, was nicht in einem Volume war)

[netfriend]

So kann die überschreibende CSS-Datei nun ganz sauber im config/media/-Ordner liegen.

Außerdem sollte ja bei Docker das ganze Config-Verzeichnis in einem Volume liegen, damit das Neuinstallationen übersteht

Das Config-Verzeichnis habe ich exportiert. Reicht es nun die custom.css dort im media-Ordner flach reinzulegen oder muss die noch in einen Unterordner? Wie erfolgt die Zuordnung zum metal-design?

Muss dazu noch was in der docker-compose.yaml eingetragen werden oder wird die automatisch verwendet wenn die custom.css existiert?

[Chris M.]

Noch ne Frage zur CometVisu im Docker-Container: Komme ich an die designs ran, um hier eigene Anpassungen vornehmen zu können?

Klar!

Wichtig ist, wenn Du von einer (ur-)alten Version auf die aktuelle wechselst, dass das Custom-Design nun direkt in der Konfig mit angezogen wird: https://www.cometvisu.org/CometVisu/...sign-verandern
So kann die überschreibende CSS-Datei nun ganz sauber im config/media/-Ordner liegen.

Außerdem sollte ja bei Docker das ganze Config-Verzeichnis in einem Volume liegen, damit das Neuinstallationen übersteht: https://www.cometvisu.org/CometVisu/...ations-dateien

[netfriend]

Noch ne Frage zur CometVisu im Docker-Container: Komme ich an die designs ran, um hier eigene Anpassungen vornehmen zu können? Bisher war das z.B. im /resource/designs/metal - Verzeichnis zu finden. Hier konnte man Änderungen vornehmen, z.B. an der custom.css.

[Chris M.]

Ich vermute mal, dass das auch mit der systemd Konfig des linknx geht. Und evtl. dazu eine eigene Konfig die den Docker startet und von der dann der linknx abhängt (statt bisher vom knxd)
Aber da kenne ich mich nicht wirklich aus.

[netfriend]

Da Du lokal den knxd nicht mehr starten möchstest muss diese Abhängigkeit auf dem linknx.service natürlich raus (Zeilen 3 und 4)

Kann man stattdessen die Abhängigkeit zum CometVisu-Docker-Container setzen, so dass linknx erst startet wenn der Container läuft?
Weißt Du wie das geht?

[netfriend]

BIn gerade am Lesen und Probieren.
Muss ich den knxd im Container noch irgendwie parametrieren, z.B. einen unix socket?
Lt. der Doku wäre das der Parameter -u mit standardmäßig /tmp/eib als File, wahlweise kann auch ein anderes File angegeben werden.
Wenn ich das in der docker-compose.yaml angeben will, klappt das irgendwie nicht.
Weder so

environment:
KNX_INTERFACE: "iptn:192.168.170.222:3671"
KNX_PA: "1.1.252"
KNXD_PARAMETERS: "-u"

noch so:

environment:
KNX_INTERFACE: "iptn:192.168.170.222:3671"
KNX_PA: "1.1.252"
KNXD_PARAMETERS: -u

Lasse ich KNXD_PARAMETERS weg, startet der Container und ich kann die CometVisu anzeigen. Ist der Parameter vorhanden -egal welcher Inhalt- startet zwar der Container, aber die CometVisu-Seite wird nicht geöffnet.

Was mache ich falsch?

[Chris M.]

Die Freuden des systemd.

Da Du lokal den knxd nicht mehr starten möchstest muss diese Abhängigkeit auf dem linknx.service natürlich raus (Zeilen 3 und 4) und Du bist selber dafür verantwortlich. stehe

Wie der linknx auf den knxd zugreift steht dort in der Doku: https://github.com/linknx/linknx/wiki/Services
=> Ja nach dem was Du in knxconnection stehen hast musst Du den Socket oder den Port aus dem Container bereit stellen

[netfriend]

Ja, im Container läuft ein knxd. Ich weiß nicht wie der linknx darauf zugreift.
Wenn es über den Port ist, so musst Du diesen Port vom Container aus exportieren und den linknx darauf zugreifen lassen (analog zum Port 80 für den Web-Browser).
Oder, wenn der linknx über den Socket zugreifen möchte, dann musst Du diesen Sockert per Mount exportieren (so wie die Config-Dateien oder die RRD Dateien).

Klingt nachvollziehbar. Ich weiß bisher nicht, wie der linknx auf den knxd zugreifen möchte.
Wenn ich linknx starte (systemctl start linknx), erhalte ich folgende Fehlermeldung: "Failed to start linknx.service: Unit knxd.service not found."

In der /usr/lib/systemd/system/linknx.service steht:

[Unit]
Description=Linknx Daemon
Requires=knxd.service
After=knxd.service
[Service]
ExecStart=/usr/local/bin/linknx --config=/var/lib/linknx/linknx.xml --pid-file=/var/run/linknx.pid --daemon=/var/log/linknx.log
Type=forking
User=root
Restart=on-failure
RestartSec=3
[Install]
WantedBy=multi-user.target

Hat jemand ne Idee, wie der linknx auf den knxd im Container zugreifen kann?
Was kann ich tun, damit das klappt?
Wer kann helfen? Danke.

[netfriend]

Der Container erwartet fest und unveränderlich, dass die anzuzeigenden RRDs in seinem Ordner /var/www/rrd liegen. Das erreichst Du dadurch, dass Du das lokale Verzeichnis bei Dir, in dem diese Dateien wirklich liegen, eben auf /var/www/rrd im Container gemountet werden.

Die Erklärung hat mir geholfen. In der docker-compose.yaml habe ich folgendes hinzugefügt:

volumes:
  - ./resource/config:/var/www/html/resource/config
  - ./resource/rrd:/var/www/rrd

Ich habe einen Ordner /root/resource/rrd erstellt und dort von meinem bisherigem Raspi ein paar rrd's hinkopiert, den Container gestartet und siehe da, die Diagramme wurde angezeigt! Wieder ein Schritt weiter, herzlichen Dank Chris!

Ja, im Container läuft ein knxd. Ich weiß nicht wie der linknx darauf zugreift.
Wenn es über den Port ist, so musst Du diesen Port vom Container aus exportieren und den linknx darauf zugreifen lassen (analog zum Port 80 für den Web-Browser).
Oder, wenn der linknx über den Socket zugreifen möchte, dann musst Du diesen Sockert per Mount exportieren (so wie die Config-Dateien oder die RRD Dateien).

D.h. ja, es sollte gehen.

Das muss ich mir als nächstes ansehen. Hoffe, dass ich da noch ne Lösung finde
Einen zweiten knxd finde ich eher unschön.

OK, das sind Punkte die wir gerne mit aufnehmen können.

Prima!

[Chris M.]

Genügt es dann, die rrd-Dateien in den genannten Ordner /var/www/rrd zu legen oder muss das dem Container noch irgendwie mitgeteilt werden? Wenn ja, wie?

Der Container erwartet fest und unveränderlich, dass die anzuzeigenden RRDs in seinem Ordner /var/www/rrd liegen. Das erreichst Du dadurch, dass Du das lokale Verzeichnis bei Dir, in dem diese Dateien wirklich liegen, eben auf /var/www/rrd im Container gemountet werden.

Habe nun versucht, linknx auf dem Raspi zu installieren. Allerdings kommt die Fehlermeldung, dass kein knxd vorhanden ist. Stimmt ja insofern, da dieser im Docker-Container läuft. Kann man den mitverwenden? Falls ja, wie?

Ja, im Container läuft ein knxd. Ich weiß nicht wie der linknx darauf zugreift.
Wenn es über den Port ist, so musst Du diesen Port vom Container aus exportieren und den linknx darauf zugreifen lassen (analog zum Port 80 für den Web-Browser).
Oder, wenn der linknx über den Socket zugreifen möchte, dann musst Du diesen Sockert per Mount exportieren (so wie die Config-Dateien oder die RRD Dateien).

D.h. ja, es sollte gehen.

Oder muss man nochmals knxd installieren - außerhalb des Containers?

Diese Möglichkeit besteht auch. Sollte aber nicht unbedingt notwendig sein.

Mir war anfangs nicht klar, was ich mit den genannten Umgebungsvariablen anfangen muss. Erst im Forum durch lesen bzw. nachfragen war mir klar, dass diese unter "service" in die docker-compose.yaml eingetragen werden müssen. Mag für die Ersteller des Containers selbstverständlich sein, für Erstbenutzer nicht

Das ist genau die Schwierigkeit beim Schreiben des Handbuchs: Es ist ein Handbuch für die CometVisu und keines für Docker. Dafür gibt es andere Handbücher, Tutorials, ... Würde das CometVisu-Handbuch hier bei Docker zu sehr in die Tiefe gehen ist das nur ein noch größerer Pflege-Aufwand, da dieser Text nicht nur den aktuellen Stand der CometVisu, sondern auch noch den des Dockers beschreiben müsste.

Ein Verweis auf die docker-compose.yaml und ein kleines Beispiel wären hilfreich. Auch der Hinweis, was nur für die CometVisu notwendig ist und was man zusätzlich für openHAB braucht. Das waren die größten Stolpersteine.

OK, das sind Punkte die wir gerne mit aufnehmen können.

[netfriend]

Die wichtigsten Infos dazu stehen im Handbuch: https://www.cometvisu.org/CometVisu/...ll/docker.html

Z.B. zu Deiner Frage mit den RRDs:

=> Ja, Du brauchst irgend eine Logik (wie z.B. linknx), dass die RRDs befüllt
=> Diese RRDs dürfen nicht im Docker Container liegen - denn alles was im Container liegt ist nach einem Update (bewusst!) weg
=> Also müssen die RRDs auf dem Rechner liegen, der auch den Docker laufen lässt - und per Mount in den CometVisu Container eingebunden werden, unter dem im Handbuch angegebenen Pfad

Genügt es dann, die rrd-Dateien in den genannten Ordner /var/www/rrd zu legen oder muss das dem Container noch irgendwie mitgeteilt werden? Wenn ja, wie?

Habe nun versucht, linknx auf dem Raspi zu installieren. Allerdings kommt die Fehlermeldung, dass kein knxd vorhanden ist. Stimmt ja insofern, da dieser im Docker-Container läuft. Kann man den mitverwenden? Falls ja, wie?
Oder muss man nochmals knxd installieren - außerhalb des Containers?

Wenn was im Handbuch fehlt oder missverständlich ist, können wir das gerne anpassen.

Mir war anfangs nicht klar, was ich mit den genannten Umgebungsvariablen anfangen muss. Erst im Forum durch lesen bzw. nachfragen war mir klar, dass diese unter "service" in die docker-compose.yaml eingetragen werden müssen. Mag für die Ersteller des Containers selbstverständlich sein, für Erstbenutzer nicht

Ein Verweis auf die docker-compose.yaml und ein kleines Beispiel wären hilfreich. Auch der Hinweis, was nur für die CometVisu notwendig ist und was man zusätzlich für openHAB braucht. Das waren die größten Stolpersteine.

[Chris M.]

Die wichtigsten Infos dazu stehen im Handbuch: https://www.cometvisu.org/CometVisu/...ll/docker.html

Z.B. zu Deiner Frage mit den RRDs:

Für das Diagram-Plugin können die Zeitserien als RRD-Dateien bereit gestellt werden. Diese müssen unter dem Pfad /var/www/rrd als Mount eingebunden werden. Die RRD-Dateien selbst müssen außerhalb befüllt und aktualisiert werden, z.B. von einem anderen Container der dieses Volume gleichzeitig mit einbindet.

=> Ja, Du brauchst irgend eine Logik (wie z.B. linknx), dass die RRDs befüllt
=> Diese RRDs dürfen nicht im Docker Container liegen - denn alles was im Container liegt ist nach einem Update (bewusst!) weg
=> Also müssen die RRDs auf dem Rechner liegen, der auch den Docker laufen lässt - und per Mount in den CometVisu Container eingebunden werden, unter dem im Handbuch angegebenen Pfad

Wenn was im Handbuch fehlt oder missverständlich ist, können wir das gerne anpassen.

Die Funktionalität des Images kann man sicher auch mit der Docker-Version erreichen. Hier könnte es helfen so ein Image, oder besser noch eine Klick-Anleitung, bereit zu stellen. Da ich keinen RPi habe (bzw. meiner ist uralt und hat mangels Anwendung keinerlei Betrieb gesehen) bin ich in dem Thread nicht unterwegs und kann dort leider auch nicht weiterhelfen.
Wenn es aber eine Klick-Anleitung gibt können wir die gerne auch im Handbuch einbinden, damit die auch von anderen schnell und leicht gefunden werden kann.