ioBroker.knx
ioBroker.knx copied to clipboard
Anbindung an MDP IP Interface nach Restore
Hallo, nach einem Restore auf einem neuen NAS und einem neuen Docker-Container funktioniert in iobroker die KNX-Anbindung über ein MDT-IP Interface nicht mehr. Was könnten die Fehlerquellen sein:
KNX-Adresse im MDT-IP-Interface: es gibt 4, 15.15.241 bis 15.15.244, 15.15.241 ist belegt, die anderen 3 sind frei, Prog.-Modus wurde ON gesetzt, die Auswahl von einer der 3 freien führt zu dem späteren Log und bleibt ohne Erfolg:
Einstellungen im iobroker:
172.17.0.2 ist laut Synology die IP des Containers und wird von iobroker so erkannt, siehe Screenshot.
Die IP des Gateways und der Port stimmen auch. Hat jemand bitte eine Idee, warum die Kommunikation nicht zustande kommt? Ansonsten müsste das Interface gelöscht und neu installiert werden - aber dafür habe ich ja das Backup aus iobroker gemacht, damit keine Einstellungen verloren gehen.
VG
Gibt es denn eine entsprechende Route also kommst du vom ioBroker in dein zielnetz und umgekehrt? Eventuell Firewall Einstellungen? Eventuell würde ein erweitertes log mehr Aufschluss geben.
Das ist eine gute Frage. Ich weiß leider nicht, wie man bei der Erstellung eines Docker-Containers diese Route richtig einstellt und worauf es da ankommt. War das Log nicht bereits mit allen Details versehen?
Ein log vom knx-Adapter konnte ich leider nicht finden. Mit docker kenne ich mich nicht aus. Eventuell dort mal in den einschlägigen Foren suchen.
So sieht die Endlosschleife im Protokoll aus:
`
knx.0 | 2024-01-14 16:38:54.674 | info | Using UDP with local IP: 172.17.0.3 -- | -- | -- | --knx.0 | 2024-01-14 16:38:53.675 | info | STATE_NOT_CONNECTED : Stop connection : STATE_NOT_CONNECTED(0) to STATE_NOT_CONNECTED(0).
knx.0 | 2024-01-14 16:38:53.675 | info | ... not able to close connection, because already closed
knx.0 | 2024-01-14 16:38:53.674 | info | Connection persists.....closing now
knx.0 | 2024-01-14 16:38:53.674 | info | ...set STATE-NOT-CONNECTED
knx.0 | 2024-01-14 16:38:52.673 | info | STATE_NOT_CONNECTED : Try to connect / reconnect : STATE_DISCONNECT_REQUEST(15) to STATE_NOT_CONNECTED(0).
knx.0 | 2024-01-14 16:38:52.673 | info | ... not able to close connection, because already closed
knx.0 | 2024-01-14 16:38:52.672 | info | Connection persists.....closing now
knx.0 | 2024-01-14 16:38:52.672 | info | STATE_DISCONNECT_REQUEST : no defined handling for transition from State: STATE_CONNECTION_STATE_RESPONSE(6) to STATE_DISCONNECT_REQUEST(15).
knx.0 | 2024-01-14 16:38:52.672 | info | Received CONNECTIONSTATE_RESPONSE : 06 10 02 08 00 08 00 21 192.168.178.50:3671 ChID : 0 SeqCntIN : 0 SeqCntOUT : 0 msgCode : [object Object]
knx.0 | 2024-01-14 16:38:52.671 | info | STATE_CONNECTION_STATE_REQUEST : no defined handling for transition from State: STATE_DESCRIPTION_REQUEST(17) to STATE_CONNECTION_STATE_REQUEST(5).
knx.0 | 2024-01-14 16:38:52.671 | info | Send : UDP Connection State Request : 06 10 02 07 00 10 00 00 08 01 00 00 00 00 a4 2f sent from Port: to 192.168.178.50:3671
knx.0 | 2024-01-14 16:38:50.669 | info | Send : description Request : 06 10 02 03 00 0e 08 01 ac 11 00 03 a4 2f sent to 192.168.178.50:3671
knx.0 | 2024-01-14 16:38:50.669 | info | Connected - local UDP Server listening on 172.17.0.3:42031
knx.0 | 2024-01-14 16:38:50.669 | info | Event : UDP - listening
knx.0 | 2024-01-14 16:38:50.668 | info | Using UDP with local IP: 172.17.0.3
knx.0 | 2024-01-14 16:38:49.671 | info | STATE_NOT_CONNECTED : Stop connection : STATE_NOT_CONNECTED(0) to STATE_NOT_CONNECTED(0).
knx.0 | 2024-01-14 16:38:49.670 | info | ... not able to close connection, because already closed
knx.0 | 2024-01-14 16:38:49.670 | info | Connection persists.....closing now
knx.0 | 2024-01-14 16:38:49.669 | info | ...set STATE-NOT-CONNECTED
knx.0 | 2024-01-14 16:38:48.668 | info | STATE_NOT_CONNECTED : Try to connect / reconnect : STATE_DISCONNECT_REQUEST(15) to STATE_NOT_CONNECTED(0).
knx.0 | 2024-01-14 16:38:48.668 | info | ... not able to close connection, because already closed knx.0 | 2024-01-14 16:38:48.667 | info | Connection persists.....closing now knx.0 | 2024-01-14 16:38:48.667 | info | STATE_DISCONNECT_REQUEST : no defined handling for transition from State: STATE_CONNECTION_STATE_RESPONSE(6) to STATE_DISCONNECT_REQUEST(15). knx.0 | 2024-01-14 16:38:48.667 | info | Received CONNECTIONSTATE_RESPONSE : 06 10 02 08 00 08 00 21 192.168.178.50:3671 ChID : 0 SeqCntIN : 0 SeqCntOUT : 0 msgCode : [object Object] knx.0 | 2024-01-14 16:38:48.666 | info | STATE_CONNECTION_STATE_REQUEST : no defined handling for transition from State: STATE_DESCRIPTION_REQUEST(17) to STATE_CONNECTION_STATE_REQUEST(5). knx.0 | 2024-01-14 16:38:48.666 | info | Send : UDP Connection State Request : 06 10 02 07 00 10 00 00 08 01 00 00 00 00 dc 5b sent from Port: to 192.168.178.50:3671 knx.0 | 2024-01-14 16:38:46.665 | info | Send : description Request : 06 10 02 03 00 0e 08 01 ac 11 00 03 dc 5b sent to 192.168.178.50:3671 knx.0 | 2024-01-14 16:38:46.664 | info | Connected - local UDP Server listening on 172.17.0.3:56411 knx.0 | 2024-01-14 16:38:46.664 | info | Event : UDP - listening knx.0 | 2024-01-14 16:38:46.663 | info | Using UDP with local IP: 172.17.0.3
`
Du musst auch udp freigeben. Gibt es soetwas wie eine routing Tabelle oder ein Auszug der Firewall?...irgendwas blockiert da.
Kannst Du mir einen Tipp geben, wo ich suchen muss?
Die Synology-Firewall ist außer Betrieb.
In den Einstellungen des Docker-Containers?
Unter "Port" ist dort beides eingestellt:
Ohne Änderungen der Einstellungen am Docker-Image habe ich mal eben OpenKNX als Instanz installiert. Mit den gleichen Einstellungen im Adapter wie beim kostenpflichtigen KNX-Adapter wird die Instanz sofort "grün", das MDT-KNX-Interface zeigt an, dass ein der Tunnel mit udp erfolgreich verbunden ist.
Also muss es an dem kostenpflichtigen KNX-Adapter liegen.