knxd und OpenHAB

[Tatwaffe23mm]

Hallo,

der knxd vergibt die Gruppenadressen an seine Clients rotierend aus dem vorgegebenem Adressraum (-E 1.1.10:5). Dies macht offenbar Probleme bei der Verbindung mit OpenHAB, da OpenHAB immer die in der config angegebene Busadresse zugewiesen bekommen möchte, zBsp 1.1.11.
Nach einem Auto-Reconnect seitens OpenHAB bekomme ich jedenfalls keine schreibende Verbindung mehr zum Bus, nur lesen geht noch. Als Grund konnte ich die Neuzuweisung der Buasadressen einkreisen.

Ich habe in der Doku jetzt etwas über Filter gefunden, die das offenbar richten könnten.
Meine Fragen:

1. Ist der single-Filter oder der remap-Filter das Mittel der Wahl um OpenHAB glauben zu machen, dass er immer mit der gleichen Buasadresse kommunziert?
2. Wie konfiguriere ich die Filter richtig?

Gruß A.

[Smurf]

Wenn der OpenHAB die zugewiesene Adresse ignoriert, dann ist das Mittel der Wahl, ihm eine Adresse zu konfigurieren, die *nicht* aus dem -E-Bereich stammt. Das sollte eigentlich funktionieren.

Aber: kippe bitte unbedingt bei den OpenHAB-Leuten einen Bug ein. Wenn sie schon ein Protokoll nutzen, das dem OpenHAB eine knx-Adresse zuweist, dann sollen sie gefälligst diese zugewiesene Adresse auch tatsächlich verwenden. Dem OpenHAB in der Config eine feste Adresse zu verpassen sollte nur beim Muticast-Routing notwendig (bzw. erlaubt) sein.

[Tatwaffe23mm]

Guten Morgen,

vielen Dank für Deine schnelle Antwort. Ich werde das heute Abend gleich mal testen.

Danke und Gruß A.

[Tatwaffe23mm]

Hallo Smurf,

eine Weile ging das ganz gut (-E 1.1.245:1, OpenHBAB-config: busaddress: 1.1.255), heute verlor OpenHAB dann jedoch wieder die Verbindung und im Log gab es dann nur noch folgendes zu lesen:

13:32:57.549 [WARN ] [tuwien.auto.calimero                ] - KNXnet/IP Tunneling 127.0.0.1:3671: connection state response status: server could not find active data connection with specified ID
13:33:07.551 [WARN ] [tuwien.auto.calimero                ] - KNXnet/IP Tunneling 127.0.0.1:3671: connection state response status: server could not find active data connection with specified ID
13:33:17.553 [WARN ] [tuwien.auto.calimero                ] - KNXnet/IP Tunneling 127.0.0.1:3671: connection state response status: server could not find active data connection with specified ID
13:33:27.555 [WARN ] [tuwien.auto.calimero                ] - KNXnet/IP Tunneling 127.0.0.1:3671: connection state response status: server could not find active data connection with specified ID
13:33:37.558 [WARN ] [tuwien.auto.calimero                ] - KNXnet/IP Tunneling 127.0.0.1:3671: received disconnect response status 0x21 (no active data connection with that ID)
13:33:37.564 [WARN ] [nx.internal.connection.KNXConnection] - KNX link has been lost (reason: no heartbeat response on object tunneling link link (closed) 127.0.0.1:3671 TP1 medium, device 1.1.255, hopcount 6)
13:33:37.695 [WARN ] [tuwien.auto.calimero                ] - KNXnet/IP Tunneling 127.0.0.1:3671: close connection - no heartbeat response
13:33:37.966 [ERROR] [.binding.knx.internal.bus.KNXBinding] - Received detach Event.

Bei der Konfiguation mit -E 1.1.245:1 und OpenHAB-seitig busaddress: 1.1.245 hatte ich das Problem nicht.

Gruß A.

[Smurf]

Anscheinend ist da was durcheinandergekommen. Es kann durchaus sein, dass der knxd noch der Meinung ist, die Verbindung besteht. Und dann nimmt er natürlich keine weitere an. D.h. -E …:1 ist ungünstig. Mach den Bereich größer. Kann ja irgendwo anders im KNX-Adressraum sein.

Ansonsten brauche ich einen Pakettrace um das genauer nachvollziehen zu können.

tcpdump -ilo -w/tmp/trace port 3671

oder so.

[misa]

Hallo, meine Vermutung ist, dass Problem ggf. mit dem TPUART Driver zusammenhängt.
Bitte schaut mal hier: https://knx-user-forum.de/forum/proj...trying-to-send

[Tatwaffe23mm]

Moin, das kann gut möglich sein. Gestern Abend fand ich im Log des knxd eine Fehlermeldung mit Hinweis auf den TPUART-Treiber. Ich bin noch dabei das Problem gezielt zu reproduzieren, was halt blöd ist, wenn die Kiste im Produktivbetrieb drinhängt. :/

Was ich schon mal sagen kann ist, dass ich eine Verbindung bekomme, wenn busaddress=1.1.255 ist und der knxd 1.1.245:4 vergibt. Allerdings bricht auch dann die Verbindung zum OpenHAB irgendwann ab und kann nicht wieder aufgebaut werden.

Stabil geht es aktuell nur mit der gleichen physikalen Adresse für den knxd (-E) und den OpenHAB (busaddress).

[Smurf]

Stabil geht es aktuell nur mit der gleichen physikalen Adresse für den knxd (-E) und den OpenHAB (busaddress).

Das halte ich für Zufall. Bzw eigentlich sollte der OpenHAB mit der -e (nicht -E)-Adresse gar nichts senden können …

[Tatwaffe23mm]

Hallo Smurf,

ich meinte die erste Adresse aus dem vom knxd verwalteten Adressraum. knxd -e 1.1.0 -E 1.1.245:1 .... und OpenHAB busaddress=1.1.245.
Entschuldigung, das war etwas mißverständlich ausgedrückt.

[Tatwaffe23mm]

Ich versteh die Welt nicht mehr. Seit einem Neustart des PI heute Abend, empfängt OH2 nur noch ganz vereinzelte Telegramme, nämlich dann wenn ich vorher etwas geschaltet habe. Die GroupValueRead-Anfragen des OH2 kommen auf dem Bus an, Die Antwort kommt vom Bus, bei OH2 kommt jedoch nichts mehr an. Ständig Timeouts...

2018-01-09 00:30:26.336 [INFO ] [tuwien.auto.calimero                ] - KNXnet/IP Tunneling 127.0.0.1:3671: establish connection from /192.168.178.3:41542 to /127.0.0.1:3671
2018-01-09 00:30:26.374 [DEBUG] [tuwien.auto.calimero                ] - KNXnet/IP Tunneling 127.0.0.1:3671: wait for connect response from /127.0.0.1:3671 ...
2018-01-09 00:30:26.408 [DEBUG] [tuwien.auto.calimero                ] - KNXnet/IP Tunneling 127.0.0.1:3671: using server-assigned data endpoint /192.168.178.3:3671
2018-01-09 00:30:26.438 [INFO ] [tuwien.auto.calimero                ] - KNXnet/IP Tunneling 127.0.0.1:3671: connection established
2018-01-09 00:30:26.611 [INFO ] [tuwien.auto.calimero                ] - calimero.link.127.0.0.1:3671: send message to 3/2/11, wait for confirmation
2018-01-09 00:30:26.655 [DEBUG] [tuwien.auto.calimero                ] - calimero.link.127.0.0.1:3671: cEMI L-Data.req from 1.1.255 to 3/2/11, low priority hop count 6 repeat tpdu 00 00
2018-01-09 00:30:26.683 [DEBUG] [tuwien.auto.calimero                ] - KNXnet/IP Tunneling 127.0.0.1:3671: sending cEMI frame seq 0, wait for cEMI.con, attempt 1 (channel 1) 06 10 04 20 00 15 04 01 00 00 11 00 bc e0 11 ff 1a 0b 01 00 00
2018-01-09 00:30:26.691 [DEBUG] [tuwien.auto.calimero                ] - KNXnet/IP Tunneling 127.0.0.1:3671: received cEMI L-Data.con with req 0
2018-01-09 00:30:26.702 [DEBUG] [tuwien.auto.calimero                ] - calimero.link.127.0.0.1:3671: confirmation of 3/2/11
2018-01-09 00:30:26.716 [DEBUG] [tuwien.auto.calimero                ] - calimero.link.127.0.0.1:3671: send to 3/2/11 succeeded
2018-01-09 00:30:26.744 [DEBUG] [tuwien.auto.calimero                ] - process 127.0.0.1:3671: sent group read request to 3/2/11
2018-01-09 00:30:36.668 [WARN ] [al.bus.KNXBindingDatapointReaderTask] - Autorefresh: Cannot read value for item 'HZG_OG_Ankleide_Betriebsart_setzen' from KNX bus: timeout waiting for group read response: timeout
2018-01-09 00:30:36.671 [INFO ] [tuwien.auto.calimero                ] - process 127.0.0.1:3671: timeout waiting for group read response

weil der knxd immer wieder stirbt:

Jan 09 00:29:12 knxpi knxd[1403]: E00000055: [17:B.tpuarts] Driver timed out trying to send (B.tpuarts)
Jan 09 00:29:12 knxpi systemd[1]: knxd.service: Main process exited, code=exited, status=1/FAILURE
Jan 09 00:29:12 knxpi systemd[1]: knxd.service: Unit entered failed state.
Jan 09 00:29:12 knxpi systemd[1]: knxd.service: Failed with result 'exit-code'.
Jan 09 00:29:22 knxpi systemd[1]: knxd.service: Service hold-off time over, scheduling restart.
Jan 09 00:29:22 knxpi systemd[1]: Stopped KNX Daemon.
Jan 09 00:29:22 knxpi systemd[1]: Starting KNX Daemon...
Jan 09 00:29:22 knxpi systemd[1]: Started KNX Daemon.
Jan 09 00:30:07 knxpi knxd[1902]: E00000055: [17:B.tpuarts] Driver timed out trying to send (B.tpuarts)
Jan 09 00:30:07 knxpi knxd[1902]: F00000000: [17:B.tpuarts] Link down, terminating
Jan 09 00:30:07 knxpi systemd[1]: knxd.service: Main process exited, code=exited, status=1/FAILURE
Jan 09 00:30:07 knxpi systemd[1]: knxd.service: Unit entered failed state.
Jan 09 00:30:07 knxpi systemd[1]: knxd.service: Failed with result 'exit-code'.
Jan 09 00:30:17 knxpi systemd[1]: knxd.service: Service hold-off time over, scheduling restart.
Jan 09 00:30:17 knxpi systemd[1]: Stopped KNX Daemon.
Jan 09 00:30:17 knxpi systemd[1]: Starting KNX Daemon...

Kann das ein Anzeichen für einen HW-Defekt sein?

knxd --GroupCache --eibaddr=1.1.0 --client-addrs=1.1.245:8 -D -T -R -S -b tpuarts:/dev/knx1

Ich bin ratlos, vor allem weil es bis heute Abend lief.

[Smurf]

Entweder das, oder irgendein anderer Prozess lauscht mit auf dem seriellen Port. Verifiziere mal, dass da wirklich kein getty läuft, keine Konsole, und (wenn Pi3) dass der Overlay gegen Bluetooth an ist.

[misa]

Das war bei mir auch. Versuch es mal mit dem Multi-Port Switch:

-A multi-port=true

Grüsse Michael

[Smurf]

??? Multi-port bezieht sich auf Multicast-Routing und hat mit dem TPUART exakt gar nichts zu tun.

[misa]

Das stimmt. Tatwaffe hat IMHO zwei unterschiedliche Probleme. Er ist meiner Meinung nach nun auf das Problem gelaufen, dass er nichts mehr senden kann.

https://knx-user-forum.de/forum/proj...ber-keine-mehr

[Tatwaffe23mm]

Hallo Micha, aktuell ist es beides. Senden geht, aber nur eine Weile. Bis gestern konnte ich mit -e 1.1.0 -E 1.1.245:1 und buasaddress=1.1.245 sicherstellen, dass senden/empfangen über mehrere Tage läuft. Nach dem gestrigen Neustart geht nun nichts mehr wie vorher. Egal ob

-e 1.1.0 -E 1.1.245:1; OH busaddress=1.1.245
-e 1.1.0 -E 1.1.245:1; OH busaddress=1.1.255
oder
-e 1.1.0 -E 1.1.245:8; OH busaddress=1.1.255

OH2 empfängt höchstens sporadisch eine Rückmeldung, wenn ich über das HabPanel das Licht schalte. Nach einigen Minuten ist die Verbindung dann weg. Das Log sieht immer aus, wie oben.
Leseanfragen seitens OH2 werden am Bus empfangen und auch beantwortet (sieht man in der ETS), bei OH2 kommt aber nichts an, als wenn es einen Filter dazwischen gibt. Ich habe gestern Abend dann auch mit allerhand debug-Output-Optionen herumgespielt aber nicht herausfinden können, ob OH2 oder der knxd das Problem erzeugt. Es ist halt ganz schön viel Ouptut der da auf einen zurauscht und die Materie ist auch neu für mich.

Interssant fand ich die Tatsache, dass der knxd/OH2 Verbund ohne den GroupCache quasi nicht arbeitsfähig ist, weil OH2 beim initalisieren den Bus mit Anfragen flutet.
Warum das so ist verstehe ich nicht, weil die ?Spec? für KNXnet/IP (KNX IP – using IP networks as KNX medium) ja sagt, dass

Any KNX IP device or KNXnet/IP Router SHOULD be capable of receiving and processing at least 12750 ROUTING_INDICATION datagrams per second on an assigned multicast address.

und es werden aktuell etwa 100 Dinge abgefragt.
Aber das ist ein anderes Thema.

@Smurf: Kannst Du mir mal einen Hinweis geben, welches die idealen Debugoptionen für den knxd wären um die Verbindung zwischen knxd und OH2 zu prüfen?