knxd empfängt nur noch Daten, sendet aber keine mehr

[Smurf]

OK. Wenn groupswrite funktioniert und Ereignisse vom KNX im openHAB ankommen, dann ist das Problem definitiv auf openHAB-Seite zu suchen.

[misa]

... und der Re-Start von OH2 das Problem temporär behebt. Ich habe den knxd mal so umkonfiguriert, dass nur noch ein Gerät connecten kann, also -e 0.0.1 -E 0.0.2:1 -DTRS -b tpuarts:/dev/ttyKNX1.

[Stanis]

Ich hatte heute auch wieder das Problem. Das ich Licht anmachen aber nicht ausschalten konnte. Nach einem Neustart von Edomi hats wieder geklappt. Interessant ist, das zu dieser Zeit der groupwrite Befehl auch nicht geklappt hat. Jedoch nach einem Edomi Server Neustart klappt auch der wieder. Kann ich mir aktuell nicht erklären. Werde aber noch andere Szenarien ausprobieren.

[misa]

Seit ich knxd so konfiguriert habe, dass nur noch einen KNX Geräteadresse vergeben werden kann, ist das Problem nicht mehr aufgetreten.
Ich gehe davon aus, dass das OH2 KNX1 Binding mit den springenden Geräteadressen Probleme hat.
@Stanis: Du kannst das mal probieren zu verifizieren.

[Stanis]

Ich kann das Verhalten bestätigen. Auch klappt ohne das Springen der Geräteadresse das Programmieren in ETS - was vorher häufig mit der Fehlermeldung kam "es sind mehrere Geräte im Programmiermodus".

[Smurf]

Ich bin begeistert.

[smai]

Ich fürchte, dass ich dies auch bestätigen kann.
Mit der aktuellen stable Version funktioniert das Programmieren nur zuverlässig, wenn ich den Adressbereich auf 1 setze.

[misa]

Ich habe noch ein paar weitere Langzeit Tests gemacht:
1.) Bei der aktuellen 0.14.6 Version herhalte ich all 15 bis 30 Minuten folgende Fehlermeldung vom KNX Binding in OH2:

12:24:46.611 [WARN ] [tuwien.auto.calimero                ] - KNXnet/IP Tunneling 192.168.1.42:3671: connection state response status: server could not find active data connection with specified ID
12:24:56.612 [WARN ] [tuwien.auto.calimero                ] - KNXnet/IP Tunneling 192.168.1.42:3671: connection state response status: server could not find active data connection with specified ID
12:25:06.612 [WARN ] [tuwien.auto.calimero                ] - KNXnet/IP Tunneling 192.168.1.42:3671: connection state response status: server could not find active data connection with specified ID
12:25:16.612 [WARN ] [tuwien.auto.calimero                ] - KNXnet/IP Tunneling 192.168.1.42:3671: connection state response status: server could not find active data connection with specified ID
12:25:26.613 [WARN ] [tuwien.auto.calimero                ] - KNXnet/IP Tunneling 192.168.1.42:3671: received disconnect response status 0x21 (no active data connection with that ID)
12:25:26.613 [WARN ] [nx.internal.connection.KNXConnection] - KNX link has been lost (reason: no heartbeat response on object tunneling link link (closed) 192.168.1.42:3671 TP1 medium, device 0.0.200, hopcount 6)
12:25:26.615 [WARN ] [tuwien.auto.calimero                ] - KNXnet/IP Tunneling 192.168.1.42:3671: close connection - no heartbeat response
12:25:26.621 [ERROR] [.binding.knx.internal.bus.KNXBinding] - Received detach Event.

Nach 4 Fehlversuchen macht das KNX OH2 Binding dann einen Reset der Connection und dann läuft es wieder.

2.) Beim Downgrade auf 0.12.x tauchet mit gleicher Konfiguration das alte Problem wieder auf, dass nur noch empfangen aber nicht mehr gesendet wird.

[misa]

Also das ist komisch. Wenn ich beispielsweise den knxd mit "-c" parameter laufen lasse, so bekommen ich bei obiger Konfiguration auch wieder das Verhalten, dass nach einiger Zeit nur noch empfange und nicht mehr gesendet wird. Irgendwie zeigt wohl die Data Connection ID in den Wald...

[misa]

Jetzt habe ich noch eine Änderung vorgenommen:
Im O2 KNX Binding kann ich für OH2 eine Busadresse angeben. Die wird vom knxd allerdings komplett ignoriert, da der knxd seine eigenen Client Bus Adressen verwaltet. Ich hatte bisher immer 0.0.0 oder 0.0.200 angegeben und das liegt bekanntlich nicht im Adressraum von 0.0.2:1.

Jetzt habe ich den knxd Adressraum geändert auf 15.15.2:1 und die OH2 KNX Binding Adresse auf 15.15.2 gesetzt. Ich werde das mal länger beobachten.

BTW: Ein Test mit dem Adressraum 15.15.2:8 und gesetzter OH2 KNX Adresse 15.15.2 ist sofort gegen die Wand gelaufen, da knxd zufällig die Adresse 15.15.5 vergeben hat und ich dann genau wieder das alte Problem gesehen hatte.

Vielleicht kann mich hier noch jemand aufklären, ob knxd richtiger Weise nicht die angefragt Adresse vergeben müsste.

[Smurf]

Vielleicht kann mich hier noch jemand aufklären, ob knxd richtiger Weise nicht die angefragt Adresse vergeben müsste.

Welche angefragte Adresse? es gibt keine. Im Protokoll ist das nicht vorgesehen – weder das Senden der gewünschten noch das Empfangen der zugewiesenen Adresse. Wozu auch? das braucht niemand.

Trag in der OH2-Konfig 0.0.0 ein, das sollte funktionieren, diese Adresse wird in abgehenden Paketen vom knxd durch die zugewiesene ersetzt.

[misa]

Ok, macht Sinn. Bleibt das Problem, dass es nur mit der Einschränkung auf eine Busadresse läuft und die oben beschriebene disconnects. Hast Du da eine Idee?

[Smurf]

Nicht wirklich; ich versteh im ersten Anlauf nicht wieso das ein Problem sein sollte. Um das zu debuggen, brauche ich Logs mit einer und mit mehreren Adressen zum Vergleichen, in denen das Problem auftritt.

[Smurf]

Es dürfte am Einfachsten sein, OH2 im Routermodus zu verwenden. (Dann braucht es natürlich eine feste Adresse.)

NB², ich muss mich korrigieren, das KNX-Tunnelprotokoll überträgt durchaus Adressen. Braucht (in dieser Anwendung) trotzdem niemand.

[misa]

Ok, werde es nochmal mit dem Router Modus probieren. War bisher nicht von Erfolg gekrönt, da ich in das gleiche Issue gelaufen bin.