knxd / TUL Probleme und meine Lösung

Begonnen von jmike, 23 Januar 2017, 15:37:48

Vorheriges Thema - Nächstes Thema

jmike

Hallo zusammen.

Ich möchte hier ein paar Erfahrungen teilen, die ich mit dem knxd gemacht habe.
Habe vor ein paar Tagen eine Merten KNX Anlage von EIBD auf knxd migriert und FHEM von OSX auf (ein frisches) Jessie.
Zur installation habe ich mir den wiki Artikel und die systemd Variante ausgesucht - und dann versucht mit all den Foren Threads das Zeug zum fliegen zu bekommen.

Das erste Problem war schon mal die knxd Config, denn am Ende hab ich es nur so zum laufen gebracht:
KNXD_OPTS="-i -b ipt:192.168.2.101"

Wobei hostid 101 natürlich das LAN Gateway ist.

Zweites Problem ist (aus meiner Sicht) der Misch-Masch zwischen systemd und runlevel script Verwendung.
Einige schreiben sie nutzen systemd zeigen dann aber Outputs von #> /etc/init.d/knxd oder servcice knxd status.

Wenn ich damit falsch liege korrigiert mich bitte, aber wenn ich systemd nutze (n möchte), dann sollte ich ausschliesslich systemctl start knxd nutzen.

Nun zu den Details.
Ich hatte explizit das Problem, dass nach dem Boot die knxd services nicht korrekt laden, und FHEM dann gar nicht geht.
Lustigerweise hat es gereicht, die knxd services per Hand zu re-starten um z.b. knxtool groupswrite zum funktionieren zu bekommen.
An dieser Stelle hatte ich schon das gefühl dass systemd und runlevel scripte sich im weg stehen.

Damit nicht genug, verlor FHEM den "define tul" beim neustart - und schrieb die config dann auch direkt so.
Und ein erneutes Absetzen von "define tul..." half nicht, denn die Zeile muss offensichtlich vor den Devices in die Config.

Also, reboot -> knxd restart -> FHEM stop -> config per Hand editieren -> FHEM start ging.
Nicht gerade was man sich so wünscht ;)


Am Ende habe ich es wie folgt zum laufen gebracht:
- runlevel scripte für knxd und FHEM entfernt:
- mv /etc/init.d/knxd /root/
- mv /etc/init.d/fhem /root/
- systemd config für FHEM angelegt und in Abhängigkeit zu knxd und knxd.service konfiguriert:
- systemctl daemon-reload && systemctl enable fhem.service (siehe https://wiki.fhem.de/wiki/Benutzer:Benheim/Startscript_systemd)

Hier noch meine systemd config:

/etc/systemd# cat system/fhem.service
[Unit]
Description=FHEM service
After=network.target knxd.service
Wants=knxd.service

[Service]
Type=forking
User=fhem
Group=dialout
WorkingDirectory=/opt/fhem
ExecStart=/usr/bin/perl fhem.pl fhem.cfg

[Install]
WantedBy=multi-user.target


/etc/systemd# cat system/multi-user.target.wants/knxd.service
[Unit]
Description=KNX Daemon
After=network.target

[Service]
EnvironmentFile=/etc/knxd.conf
ExecStart=/usr/bin/knxd $KNXD_OPTS
User=knxd
Group=knxd
Type=notify

Restart=on-failure
RestartSec=10

[Install]
WantedBy=multi-user.target
Also=knxd.socket


/etc/systemd# cat system/sockets.target.wants/knxd.socket
[Unit]
Description=KNX Daemon (socket)

[Socket]
ListenStream=/var/run/knx
ListenStream=6720

[Install]
WantedBy=sockets.target


Somit habe ich die alten runlevel scripts (hoffentlich korrekt) deaktiviert und sowohl knxd als auch FHEM über systemd laufen.
Nun bleibt auch meine TUL definition erhalten :)


Was mich bei der Diagnose zusätzlich Zeit gekostet hat ist, dass der Port 6720 bei einem reboot und systemd von 1/init geöffnet wird und nicht vom Daemon knxd (wie beim manuellen starten des Service).
Das liegt jedoch an der art wie systemd sockets verwaltet und kein Fehler an sich. Die runlevel Scripte verhalten sich hier z.b. anders!

Auch sollte man beim rum-testen mit knxd immer den knxd.socket mit stoppen, gestartet wird er vom "normalen" kxnd
# systemctl restart knxd
Job for knxd.service failed. See 'systemctl status knxd.service' and 'journalctl -xn' for details.
# systemctl stop knxd
Warning: Stopping knxd.service, but it can still be activated by:
  knxd.socket
# systemctl stop knxd.socket
# systemctl start knxd
# netstat -ltnp
...
tcp        0      0 0.0.0.0:6720            0.0.0.0:*               LISTEN      1032/knxd


Für einige wird das vermutlich common-knowledge sein, aber da als "KNX-Neuling" musste ich mir doch etliche Details mühsam zusammensuchen.
Eventuell gibts ja einen kleinen Austausch zu dem Thema (evtl mit nem Linux Crack), den ein oder andern Hinweis im Wiki Eintrag oder ich kann über diesen Thread jemand anders helfen. Vielleicht macht es auch Sinn zu dem Thema ein Troubleshooting Guide zu verfassen, das setup scheint ja öfter zu hakeln ;)

lg

crushvx

Hi,
ich denke jedes Setup ist irgendwie individuell.
Ich z.B. nutze Docker um knxd laufen zu lassen.

Die Start-Parameter sind aber auch da hakelig und es dauert bis es einmal so läuft wie man das will.

Von daher wird deine ausführliche Anleitung sicherlich dem ein oder anderen mit ähnlichem Setup nützlich sein.

In meinem ganzen Setup ist das der "nicht Anfassen"-Teil.
So lange es läuft bleibt es so.

VG,
Christian