KNXD auf Raspberry Pi nicht mehr stabil

[joxn]

Hallo zusammen,

letzte Woche zum ersten Mal, heute zum zweiten Mal, ist die Verbindung zwischen KNXD und dem Bus ausgefallen. Ein Reboot des Raspberry Pi hat zwar direkt das Problem behoben, aber ich hätte gerne Hilfe, um es dauerhaft zu debuggen.

Hintergrund:
Seit einigen Jahren habe ich KNXD zusammen mit OpenHAB auf einem Raspberry Pi betrieben. Verbunden ist das Ganze über eine Gira USB Schnittstelle mit dem Bus. Nachdem ich vor vier, fünf Monaten zu HA gewechselt bin - was auf meiner Synology läuft - habe ich den Raspberry Pi neuaufgesetzt, um ein schlichtes - und stabiles! - KNXD-only System zu haben. Das lief auch einige Monate ohne Updates und ohne Reboots stabil.

Zum Einsatz kommen:
Raspberry Pi 4 mit Gira USB Schnittstelle
Raspberry Pi OS Lite 64 bit
knxd 0.14.54.1 wurde via apt-get aus dem Respository installiert
KNXD_OPTS="-e 1.1.201 -E 1.1.202:8 -D -T -R -S -B single -b usb:"

Wenn ich feststelle, dass HA nicht mehr schaltet, habe ich mich per ssh angemeldet und knxtool groupswrite ip:localhost 2/28 1 abgesetzt. Es kommt ein "Send request" zurück, aber die Steckdose wurde nicht geschaltet. Nach dem Reboot funktioniert der Befehlt einwandfrei.

Meine Fragen:
Wie würdet ihr den Fehler eingrenzen?
Wo finde ich überhaupt logs? - Unter /var/logs war nichts auffälliges dabei.

Sonstige Ideen und Vorschläge sind sehr willkommen!

[joxn]

Der Raspberry und KNXD liefen nun vier Tage stabil. Was könnte ich jetzt machen, um besseres Logging einzuschalten, so dass ich beim nächsten Mal eine bessere Ausgangsbasis für die Analyse habe?

[Noschvie]

Das lief auch einige Monate ohne Updates und ohne Reboots stabil.

Was hast du seit dem geändert, sodass die Stabilität verloren gegangen ist?

[wvhn]

Ich hab dazu leider (bzw. glücklicherweise) keine Erfahrung und habe mal aus Interesse das Wiki auf github und die Doku des ini-files durchsucht. Letztere enthält einige Info zum Logging und hilft Dir hoffentlich weiter.

Interessant ist auch dieses Issue.

Beim nächsten Auftreten des Fehlers würde ich statt eines Reboots mal testen, welche Komponente neu gestartet werden muss, um den Fehler zu beheben. Anfangen würde ich mit HA. Wenn das nicht hilft, knxd (dazu musst Du zuerst knxd.socket und dann knxd manuell stoppen und danach wieder beide starten).

Gruß
Wolfram

[Noschvie]

Wann hast du zuletzt KNXd upgedated? Versuche mal die Version von „damals“, vielleicht hat die aktuelle Version ein Problem mit dem USB

[Smurf]

Wenn das nicht hilft, knxd (dazu musst Du zuerst knxd.socket und dann knxd manuell stoppen und danach wieder beide starten).

Wieso das denn? Ein einfaches "systemctl restart knxd" reicht vollkommen aus.

[wvhn]

Das steht so seit langer Zeit in der Kurzanleitung der smartVISU für den Fall, dass man knxd-Einstellungen ändert:

Der knxd hat zwei Einträge, zum einen knxd.socket der die normalerweise die Kommunikation über der Port 6720 übernimmt und der knxd.service der die restlichen Aufgaben übernimmt. Zunächst beenden des knxd:

sudo systemctl stop knxd.socket
sudo systemctl stop knxd.service

Die Reihenfolge ist wichtig: beenden wir erst den knxd, kann ein Prozess genau dann einen Socket öffnen und der systemd startet ihn sofort wieder.
Jetzt können wir den knxd starten mit

sudo systemctl start knxd.socket
sudo systemctl start knxd.service

Auch hier ist die Reihenfolge wichtig: Starten wir erst den Service, werden dem knxd die Sockets nicht vom systemd übergeben.

Wenn das so nicht (mehr) stimmt, bitte ich um Info. Dann korrigiere ich die Kurzanleitung.

Gruß
Wolfram

[Noschvie]

Habe eine „alte“ KNXd version "0.14.30" im Einsatz, zweimal als LoxBerry Plugin ohne Probleme, seit Jahren. Und hoffe, dass es dabei bleibt :-)

[Smurf]

Wenn das so nicht (mehr) stimmt, bitte ich um Info. Dann korrigiere ich die Kurzanleitung.

Das stimmt alles – für den Fall, dass man den knxd nachhaltig beenden und irgendwann-später wieder starten will.

Aber: für einen simplen Neustart-wegen-Konfig-Änderung ist das fehleranfälliger Overkill. Dafür reicht ein "systemctl restart", zumindest wenn man mit INI-Datei arbeitet. Für die "alte" Konfigmethode via Befehlszeile braucht es davor einen "systemctl daemon-reload". (Das gilt auch für die "lange" Methode …)