Grundlagen zum knxd (mit Installationsanleitung! Vor dem Schreiben lesen!)

[Smurf]

knxd ist ein Programm, das KNX-Pakete zwischen verschiedenen Schnittstellen und Programmen weiterleiten kann.

In diesem Thema findet ihr grundlegende Informationen zu Einrichtung und Konfiguration. Bitte erst lesen, dann verstehen, und dann eine Frage stellen.

Den Sourcecode der "stabilen" Version findet ihr hier: https://github.com/knxd/knxd/tree/stable

Dort gibt es auch eine Installationsanleitung und den Bugtracker (auf englisch).
Wenn du nicht weißt, ob ein Problem ein Fehler im knxd ist oder nicht: bitte erst hier fragen.

[Smurf]

Optionen

Der knxd versteht ziemlich viele Optionen (und bis zur Einführung einer Konfigurationsdatei wird das auch so bleiben). Wichtig: Optionen werden der Reihe nach abgearbeitet! Was er alles versteht, steht in der Onlinehilfe, die man mit "knxd --help" abfragen kann.

• Allgemeine Einstellungen

Darunter fallen zB die Einstellungen, welche Protokolldaten ausgegeben werden (-t XXX).

Dieser Bereich wird mit den Optionen "-e 9.9.1" und "-E 9.9.2:8" abgeschlossen. Die Busadressen sind willkürlich gewählt und müssen bei euch natürlich frei sein. "-e" ist die eigene Adresse des knxd; -E ist der Adressbereich, der automatisch Programmen zugewiesen wird, die sich mit dem knxd verbinden. Dazu später mehr.

Danach folgen

• Verbindungs-spezifische Einstellungen

Der knxd kennt eine Reihe von Wegen, mit KNX-Geräten oder -Programmen zu reden. Die Abfolge ist immer

• erst Optionen, die die darauffolgende Verbindung (und nur die) in irgendeiner Weise modifizieren (die können natürlich fehlen)
• dann die Option, welche Art Verbindung es sein soll

Verbindungsarten

• lokale Hardware

Dafür brauchen wir die Option "-b typ:Parameter…", also zB "-b tpuarts:/dev/ttyKNX1". Welche Typen der knxd kennt und welche Parameter sie brauchen, steht in der Hilfe.

• Hardware im Netzwerk

Für solche Geräte gibt es ein standardisiertes Tunnel-Protokoll. Die Option lautet vollständig "-B single --send-delay=70 -b ipt:192.168.1.33" (oder welche IP-Adresse oder welcher Hostname auch immer euer Interface hat). Die Verbindung läuft über UDP-Port 3671.
Das "-B single" braucht man bei manchen dieser Teile, weil sie davon ausgehen, dass sich über sie nur ein einzelner Client anschließt statt eines ganzen KNX-Netzes; der knxd muss folglich die Hardwareadressen verstecken. Das ist vor Allem dann relevant, wenn man Geräte programmieren will.
Den "--send-delay=70" braucht man bei vielen dieser Interfaces, wenn sie sich bei vielen gleichzeitigen Anfragen verschlucken. Symptom: die Visualisierung startet, fragt 20 Geräte nach ihrem Status, und bekommt nur von 20 eine Antwort.

• Multicast

Manche dieser Schnittstellen sind vollwertige knx-Router, die das lokale Netzwerk so behandeln wie ein drahtgebundenes KNX. Mit "-b ip:" kann man dem knxd sagen, dass er auch Multicast betreiben soll. Bei einigen Routern muss man diese Funktion erst mit der ETS konfigurieren.

Ein Router, der auch Tunnel ist, darf nicht gleichzeitig mit "-b ipt:" und mit "-b ip:" angesprochen werden. In diesem Fall ist Multicast vorzuziehen. (Das funktioniert aber nur im lokalen Netzwerk. Schlimmer: manche ältere WLAN-Router können kein Multicast.)

• knxd-fähige Programme

Für die Kommunikation mit dem knxd gibt es ein eigenes Protokoll. Manche Programme verstehen das. Mit der Option "-u" sagt man dem knxd, dass er unter "/run/knx" einen Unix-Socket zur Verfügung stellen soll, über den sich die mit ihm unterhalten können.

Wenn das Programm nicht auf demselben Rechner läuft, dann ist mit einem Unix-Socket nicht geholfen; mit "-i" öffnet man einen TCP-Socket auf Port 6720, über den auch Programme übers Netz mit dem knxd reden können.

Eines dieser Programme ist "knxtool", mit dem man auf den KNX-Bus schreiben oder aktuelle Werte abrufen kann.

• Standard-KNX-Programme

So wie man mit "-b ipt:" mit einem Tunnel-Interface oder mit "-b ip:" mit einem Router im lokalen Netz reden kann, so kann der knxd diese Dienste auch selbst bereitstellen. Dazu gibt es die Optionen "-D -T -R -S". Letztere öffnet den eigentlichen Mutlicast-Port. Die anderen drei modifizieren das -S und sagen ihm, was es tun soll und darf:
"-D" erlaubt das Antworten auf Anfragen vom Typ "welche Router gibt es denn im lokelan Netz?"
"-R" aktiviert den Multicast-Router.
"-T" aktiviert den Tunnel-Server.

Achtung: "-R" und "-b ip:" dürfen nicht gleichzeitig verwendet werden. (Zumindest nicht mit derselben Multicast-Adresse.) Wer eine IP-Schnittstelle hat, die routet und tunnelt, darf auch nicht gleichzeitig "-R" und "-b ip:" verwenden.

• … und sonst:

Group Cache: Der knx-Bus ist nicht dafür gedacht, dass jemand regelmäßig kommt und ein Gerät fragt, welchen Zustand es gerade hat – dazu ist die Datenrate zu niedrig. Stattdessen soll das Gerät bitte eine Nachricht schicken, sobald sich der Zustand ändert. Damit nun eine Visualisierung o.Ä. beim Neustart trotzdem erfahren kann, welchen Zustand die verwalteten Geräte haben, gibt es im knxd einen Zwischenspeicher, den man mit der Option "-c" aktiviert. Der speichert die letzte Nachricht auf allen Gruppenadressen (und damit den Gerätezustand). Die Visu kann das abfragen und auf neue Nachrichten reagieren, ohne selber Busteilnehmer zu sein.

[Smurf]

Fehlersuche

Option der Wahl zum Fehlersuchen ist "-f9 -t 1022". Die 1022 ist eine Bitmaske, kann man auch hexadezimal angeben (hier: 0xffe). Welche Bits was bedeuten, steht in den Sourcen; außerdem steht in jeder geloggten Zeile, welches Bit für sie verntwortlich ist. Generell ist Bit 0 am hardware-nähesten (deshalb hier auch aus, weil man es fast nie braucht).

'-t' ist sowohl generisch (dann kommt sie am Anfang, d.h. vor der '-e'-Option) als auch schnittstellenspezifisch (vor dem entsprechenden -b/-i/-u/-S). Damit kann man selektiv nur die Logs einschalten, die (hoffentlich) relevant sind.

Wo finde ich die Logs?

Das hängt davon ab, ob auf deinem Rechner systemd läuft und wie er konfiguriert ist. Mit systemd und Journal kann man alles, was der knxd seit dem letzten Neustart von sich gegeben hat, so aufrufen:

journalctl -u knxd.service -b

Mit "-n100" statt "-b" liefert er die letzten 100 Zeilen, und mit "-f" schreibt er in Echtzeit mit was der knxd gerade so von sich gibt.

Ohne systemd, oder mit einem systemd das ohne Logging konfiguriert ist, findet man die Logs entweder irgendwo unter /var/log, zB in /var/log/messages oder /var/log/syslog … oder gar nicht. Dann muss man den knxd anhalten und manuell starten.

Kleiner Exkurs zum Logging:
Ein Rechner mit einer SD-Karte, wie der Raspberrry Pi, sollte unbedingt nur ins RAM protokollieren, weil er sonst über kurz oder lang die SD-Karte schrottet. Dazu schreibt man in die /etc/systemd/journald.conf:

Storage=volatile
ForwardToSyslog=no

Danach am besten neustarten.

Was mache ich mit den Logs?

Aufmerksam lesen. In den meisten Fällen erledigt sich das Problem von selber.

Wenn das nichts hilft: hier ein neues Thema aufmachen und fragen. Mehr als zehn Zeilen Log bitte nicht direkt hier einstellen, sondern in einen Pastebin kopieren. Hier direkt reinkopierte Logs unbedingt zwischen CODE-Tags setzen (das ist im erweiterten Editor die '#'-Taste), sonst sind sie unleserlich.

[Smurf]

Start des knxd

• Ohne systemd

Unter Debian finden sich die Optionen in "/etc/default/knxd", mit "/etc/init.d/knxd start" o.Ä. sollte es loslaufen. Start beim Systemstart:

update-rc.d knxd defaults

Nicht vergessen: /etc/default/knxd anpassen: die Zeile "START_KNXD=no" auf "START_KNXD=yes" ändern.

• Mit systemd

Mit systemd ist das Ganze ein bisschen kompizierter, aber dafür kann der systemd auch mehr.

Socket-Aktivierung
Die Optionen "-u" und "-i" werden unter systemd nicht benötigt, weil die entsprechenden Ports bereits vom systemd offen gehalten und an den knxd weitergegeben werden. Das hat den Vorteil, dass man nicht auf die Reihenfolge achten muss, in der die diversen Programme gestartet werden. Zum "Ausgleich" kann man den knxd nicht mehr ohne Weiteres manuell laufen lassen. (Will man aber auch nicht – vor Allem, weil die Debug-Ausgaben unter systemd im Journal landen statt im Nirvana.)

Start:

systemctl start knxd.socket
systemctl start knxd.service

Stop:

systemctl stop knxd.socket
systemctl stop knxd.service

Auto-Start beim Systemstart:

systemctl enable knxd.service

[Smurf]

Quellen, Versionen, compilieren, installieren
Siehe https://github.com/knxd/knxd

Dort findet der geneigte Leser eine README-Datei mit ausführlicher Anleitung für Debian/Jessie.

Die aktuelle Entwicklung findet im "master"-Zweig statt. Außerdem gibt es die Zweige "stable" (v0.12) und "oldstable" (v0.10).
Für den produktiven Einsatz verwendet bitte den "stable"-Zweig:

    git clone https://github.com/knxd/knxd.git
    cd knxd
    git checkout stable ## oder v0.12

Die alte, auf pthsem basierende Version ist "v0.10" oder "oldstable".
Aktuelle Entwicklung findet im "master"-Zweig (oder einem Feature-Zweig) statt; der ist für den allgemeinen Konsum eher ungeeignet.

Zum Wechseln auf einen anderen Zweig tut man dies:

git fetch
git checkout stable ## oder welcher auch immer
git pull

In Folge will man auf die aktuelle Version in diesem Zweig updaten, das geht mit

git pull

"Fremde" Installationsskripte
Meine ehrliche Meinung: die im Netz verfügbaren "wie installiere ich den eibd/knxd"-Skripte sind zum Großteil veraltet. Das erkennt man daran, dass das Skript

• "pthsem" herunterlädt und installiert
• nicht den "stable"-Zweig verwendet
• systemd nicht erwähnt,/etc/rc.local modifiziert, …
• "make install" aufruft oder Dinge direkt nach /usr/local o.Ä. kopiert, statt den Paketmanager des Systems zu verwenden

Ich behaupte nicht, dass das, was ich hier und in den knxd-Sourcen schreibe, die eierlegende Wollmilchsau ist, aber:
wenn in den Quellen etwas steht, das nicht funktioniert oder unklar ist, dann kippt das bitte bei mir ein (ich höre zu…). Verweist bitte auf die "offizielle" Anleitung, statt etwas zu stricken, das nach ein paar Monaten nicht mehr funktioniert. Bringt den Menschen vor dem Bildschirm soweit, dass er/sie versteht was er/sie da tut, statt irgendwas am System zu ändern, das dieses bei einem Abbruch in einem halbdefinierten Zustand hinterlässt – den man, wenn man zum Fehlersuchen kommt, erstmal wieder aufräumen muss.

Danke.

[Smurf]

In eigener Sache

Die Arbeit an knxd und überhaupt mit dem KNX-Protokoll ist nichts, das man mal eben aus dem Ärmel schüttelt – das braucht Zeit, und dedizierte Hardware zum Testen. Einen frei verfügbaren Ersatz für die ETS5 gibt es auch nicht. (Das würde ich gerne ändern … leider sind die Dateien verschlüsselt …)

Als aktueller Haupt-Autor des knxd würde ich mich freuen, vom einen oder anderen User ein bisschen unterstützt zu werden, sei es finanziell oder mit Hardware"spenden".

• paypal: matthias@urlichs.de
• SEPA: DE25760400610535260401 @ COBADEFFXXX

Ich kann eine Rechnung stellen (mit Umsatzsteuer), wenn gewünscht.

Wer Hardware spenden will: bitte nachfragen!

[derneugierige]

Einen frei verfügbaren Ersatz für die ETS5 gibt es auch nicht. (Das würde ich gerne ändern … leider sind die Dateien verschlüsselt …)

Bist Du Dir da sicher?

Zumindest die .knxproj Dateien der ETS4 sind unverschlüsselte ZIP-Dateien.

Allerdings sind diese signiert, so dass ETS sich weigert, modifizierte Dateien zu laden.

[Smurf]

Ich meinte die Produktdateien (.knxprod und Konsorten).
Inzwischen habe ich aber die Passwörter.

[vento66]

Das alte gute Botanische? Sollte sicher hier im Forum irgendwo sicher zu finden sein...

[Smurf]

Das, und lateinische Miezekatzen.

[andreaskos]

Danke für diese wunderbare Zusammenstellung von Infos. Ich beschäftige mich erstmals mit knxd und bin für derlei geballtes Wissen sehr dankbar!