RasperberryPi, TUL TPUART, OpenHAB2, KNX-Binding und knxd 0.14

[Tatwaffe23mm]

Guten Abend,

nachdem ich jetzt 3 Abende daran verbracht habe OpenHAB2 auf einem RaspberryPi mit TUL TPUART-Stick und knxd 0.14 als IP-Router zusammenzubringen, dachte ich mir, ich schreibe es hier mal nieder, damit der nächste nicht noch einmal das gleiche Theater durchmachen muß. Insbesondere weil hier im Forum an der Funktionsfähigkeit dieser Zusammenstellung gezweifelt wird.
Das Problem ist der Hinweis zur IP in den OpenHAB config-Dateien. Speziell die /usr/knx.cfg von OpenHAB, die davon ausgehen, dass man ein KNX IP-Interface eines propietären Herstellers nutzt.

Mein System:

• RaspberryPi, Model B+ mit Raspbian Stretch
• TUL Busware, mit aktueller Firmware
• knxd 0.14, stable
• OpenHAB2

Nachdem der knxd kompiliert und der TUL TPUART Stick konfoguriert wurde, habe ich eine ini-Datei, entsprechend der Hilfe aufgebaut.
So sieht die ini dann aus. Ich habe sie unter /home/pi/knxd/config/knxd.ini abgelegt.

/home/pi/knxd/config/knxd.ini

[main]
name=knxpi
addr=1.1.0
client-addrs=1.1.65:8
connections=server,tpuarts
systemd=systemd

[tpuarts]
device=/dev/knx1 #dafür muss vorher der TPUART-Stick mit einer edev-rule versehen werden! Siehe knxd-README
driver=tpuart

[server]
server=ets_router
discover=true
debug=debug-server
router=router
tunnel=tunnel

[debug-server]
name=mcast:knxd

[A.pace]
delay=50
filter=pace

[tunnel]
filters=log

[systemd]
debug=debug-systemd
filters=log

[debug-systemd] #Debug-Level
#error-level=0x9
#trace-mask=0xfc

Anschließend in der /etc/knxd.conf folgende Zeile eintragen:

# configuration for knxd.service
KNXD_OPTS="/home/pi/knxd/config/knxd.ini"

Start ohne Kommandozeilenoptionen als daemon mit

sudo sysctl start knxd

Nun sollte der knxd laufen. Test mit

knxtool groupswrite ip:192.168.xxx.xxx <hier eine beliebige GA> <hier der Wert>

oder das Gerät in der ETS als IP-Router verwenden.

Die OpenHAB knx.cfg muß bei Verwendung eines TUL TPUART Sticks als IP-Router die Einträge folgende Einträge:

/etc/openhab2/services/knx.cfg

ip:127.0.0.1
type=TUNNEL
busaddr=1.1.64 #des TUL?
ignorelocalevents=true
port=3671
localIp=192.168.xxx.xxx

aufweisen. Bei anderen Koonfigurationen zeigte OpenHAB im Log zwar an, dass eine Verbindung zum Bus aufgebaut wurde, es ist aber in Wirklichkeit keine zustande gekommen (Timeouts).
Weder die eigene IP des PI (meist 192.168.xxx.xxx), noch die Multicast Adresse (224.0.23.12) als IP für den Router haben bei mir funktioniert. Lediglich der localhost (127.0.0.1). Warum das funktioniert? Keine Ahnung! Vielleicht kann mich einer aufklären?

Gruß André

[misa]

Ich empfehle knxd Downgrade auf 0.11.18. Ist etwas hakelig in der Installatin (erst 0.10.x bauen, 0.10 Installationsanleitung beachten), läuft aber prima. Hat alle Issues bei mir gelöst. Schau mal im knxd Forum.
Falls Du Probleme hast, melde dich einfach wieder.

[Tatwaffe23mm]

Meld. Das KNX-Binding ist bereits nach kurzer Zeit hängen geblieben. Der knxd läuft jedoch noch immer anstandslos. knxdtool konnte die GAs schalten, auch nachdem OpenHAB sich nicht mehr gerührt hat.

Wie sieht denn Deine config für OpenHAB und die Deines knxd aus? Hast Du auch o.g. Kombi am Start, also kein Hager/ABB/MDT/Anderer-Hersteller IP-Interface?

Mein Problem ist, dass ich noch nicht einmal verstehe warum knxd und OpenHAB zusammenrabeiten, wenn ich localhost als ip angebe und nicht, wenn ich 192.168.xxx.xxx angebe. Dann kommt zwar seitens OpenHAB auch die Meldung dass die KNX-Verbindung steht, aber es passiert nichts, bzw. zyklische Abfragen senden Timeouts.

Wenn ich

user@host: ping -p 3671 127.0.0.1

bekomme ich keine Fehlermeldung und wenn ich

user@host: ping -p 3671 192.168.xxx.xxx

eingebe auch nicht.

[misa]

Habe OH2.2.x im Einsatz auf einem RaspPi3. Als knx HW habe ich den TUL von Busware mit TUPART seriell FW.

Auf dem PI läuft Knxd 0.11.18 als Router.

Knx OH Binding habe ich auch als Router konfiguriert.

Bei knxd 0.14.x hatte ich das Problem, dass ich im Router Modus nicht senden konnte und dass der knxd regelmäßig angestürzt ist. Ich habe im knxd Forum dazu zwei Duskussionen gehabt. Auch der Tunnel-Modus ist öfters ausgestiegen.

Die kommunikation im Router Modus läuft über eine Multicast Adresse. D.h. Du musst die IP und Port im OH knx binding nicht setzen.

Ich schicke heute Abend meine Konfig, wenn ich wieder am Rechner bin.

[misa]

Hier wie versprochen meine Konfiguration.
Wenn Du knxd und OH2 zusammen im Router Modus verwendest, muss dein PI eine feste IP Adresse haben.
Die Kommunikation erfolgt dann über die Multi-Cast Adresse. Hier ist es wichtig zu verstehen, dass die Adresse wie eine Art Ether funktioniert. D.h. Client und Server lauschen und senden beide an die Adresse. Jeder Client, der an die Adresse etwas sendet, erreicht den knxd Router. Wenn der Router etwas sendet, dann wird es an alle Clients geschickt, die an der Adresse lauschen.

OpenHab 2 KNX 1 Binding:

# KNX gateway IP address 
ip=224.0.23.12

# (optional, defaults to 0.0.0)
busaddr=0.0.1


# (optional, defaults to false)
ignorelocalevents=true

type=ROUTER
port=3671

# Local endpoint to specify the multicast interface, no port is used (optional)
localIp=192.168.xx.xx <=== Deine PI IP-Adresse 

# (optional, default is 0)
autoReconnectPeriod=30

Für den knxd verwende ich die Version 0.11.18 mit folgender Konfiguration:

-e 15.15.1 -E 15.15.2:8 --GroupCache -D -T -R -S --tpuarts-ack-all-group -b tpuarts:/dev/ttyKNX1

Bitte beachte beim Bauen die Anleitung: https://github.com/smarthomeNG/smarthome/wiki/knxd-0.10


Die Source kannst Du mit

git checkout v0.10

runterladen. Genaus wie dann die funktionierende Version

git checkout v0.11.18

Meine Empfehlung: Erst knxd v0.10 bauen und anschliessend darüber knxd v0.11.18 bauen, da dort anscheinend ein paar Header Files fehlen.

Viel Erfolg!

[Tatwaffe23mm]

Danke!

Ich hoffe ich brauche es nicht noch einmal zu kompilieren. Seit dem letzten Neustart läuft das Interface offenbar stabil. Heute Abend lief es jedenfalls problemlos.
Ich werde es jetzt erst einmal so lassen.

BTW, eine Verständnisfrage: Ist der Tpuart-Stick im Zusammenspiel mit knxd ein Server oder ein IP-Interface?

Meine Konfiguration läuft aktuell mit Tunnel, deine mit Router.

[misa]

Der TUL Stick ist erst mal nur ein USB serielles Interface zum KNX Bus. Der knxd kann Tunnel, Router, Client, etc. sein, je nach Konfiguration und Deinen Bedürfnissen.

Mit Tunnel machst Du eine Punkt zu Punkt Verbindung auf. Das ist sinnvoll, wenn Du ggf. schon einen knx Router im Netzwerk hast.

Hast du mehrere Clients, die mit dem knxd sprechen wollen, dann ist der Router sinnvoll. Den darf es aber nur einmal pro sub net geben.

Hängt also stark von Deinem Anwendugsfall ab.

[Tatwaffe23mm]

Ok, dann reicht mir die Tunnelvariante aus, ich habe nur de Pi mit openHAB dahinter. Vielen Dank für Deine Erklärung, das hat mir zum Verständnis noch gefehlt.

[misa]

Gerne. Bei mir ist der 0.14 im Tunnel immer mal hängengeblieben, so alle 2-3 Tage. Ggf. würde das Problem behoben.

[Tatwaffe23mm]

Hallo misa,

ich hatte jetzt wochenlang doch das gleiche Problem. Die Tunnelverbindung blieb nach vorhersagbarer Zeit hängen. Ursache waren/sind Gruppenschaltungen über das rules-Modul aus OpenHAB heraus. Warum auch immer, verliert OpenHAB dabei die Verbindung.

Mit dem setzen von

AutoReconnectPeriod=30

in der OpenHAB knx.cfg konnte ich eine neue Fehlermeldung ausmachen, die anzeigte, dass die Verbindungs-ID, die OpenHAB erwartete nicht wieder zustande kam.

Das Problem liegt nun bei OpenHAB, das die vorher in der knx.cfg festgelegte Busaddresse (wieder)haben will. Das klappt aber nur, wenn der knxd nur einen Adressraum mit genau einer Adresse, nämlich der in der knx.cfg festgelegten, zur Verfügung stellt.

Etwas mehr dazu hier.

Gruß A.


Nachtrag:
knxd.ini

[main]
name=knxpi
addr=1.1.0
client-addrs=1.1.255:1
connections=server,tpuarts
systemd=systemd

knx.cfg

ip:127.0.0.1
type=TUNNEL
busaddr=1.1.255
ignorelocalevents=true
port=3671
localIp=192.168.xxx.xxx
autoReconnectPeriod=60

[misa]

Hallo Tatwaffe23mm
ja, das stimmt. Ich hatte die Tunnel-Konfiguration länger am Laufen. Das Problem mit dem Re-Connect ist, dass dabei das eigentliche Komando verloren geht.
Wenn ich z.B. Alle Rolladen im EG schließe via OH2 Gruppensteuerung, dann gehen ggf nur 5 von 7 zu.
Wie gesagt, Ich habe alles nun auf knxd im Router Modus umgestellt und einen Downgrade auf 0.11.x gemacht. Funktioniert reibungslos seit 3 Monaten.

[hypoch]

Hallo misa,
nach ich mich auch seit Tagen mit Problemen rumschlage zwischen KNX-Binding und knxd habe ich den Weg aus #5 eingeschlagen. Als Basis habe ich zunächst das aktuellste openhabian-image aufgespielt, dann die Anleitung zur Installation des knxd 0.10 begonnen. Leider komme ich da nicht ohne Fehler zu Ende:

[11:01:38] openhabian@openHABianPi:~/knxd$ sudo apt-get install libsystemd-daemon-dev
Reading package lists... Done
Building dependency tree
Reading state information... Done
Package libsystemd-daemon-dev is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source
However the following packages replace it:
  libsystemd-dev

E: Package 'libsystemd-daemon-dev' has no installation candidate
[11:01:50] openhabian@openHABianPi:~/knxd$ sudo apt-get install libsystemd-dev:i386 libsystemd-dev
Reading package lists... Done
Building dependency tree
Reading state information... Done
E: Unable to locate package libsystemd-dev:i386

Wie kann ich das beheben?
Gruß
Christian

[misa]

Hallo Christian, probier es mal mit

sudo apt-get install libsystemd-dev

[hypoch]

Super, danke!
es läuft