[Problem] IOBroker KNX-Schnittstelle periodische Unterbrechnung

[Gucki]

Die 2 Minuten ergeben sich aus dem Verbindungstimeout des KNX Tunnels. Der Standard schreibt 120s vor. Innerhalb dieser Zeitspanne muss mindestens ein ConnectionState-Request vom Client kommen. Wird diese Zeitspanne ueberschritten muss der Server die Verbindung abbauen. Offensichtlich erfolgt das geregelt, da die Verbindung durch den Client sofort nach dem Disconnect wieder aufgebaut wird.
Zur genauen Untersuchung brauche ich allerdings eine passende Testumgebung (eventuell den Container). Das wird gerade geklärt.

[Tomtheripper]

Hallo Thomas,

ich habe mir deinen Server angesehen. Im Portainer ist mir etwas seltsames aufgefallen:


Dieses Portmapping sollte nicht benötigt werden und könnte ggf. auch Probleme verursachen.

Welche Adresse gibst du in IOBroker bei der KNX-Verbindung zum Timberwolf an?

Viele Grüße,
Matthias

Hallo,

das sind die Ports meiner KNX-Schnittstellen. Brauch ich die gar nicht mappen?
Ich teste es ohne...

Gruß
Thomas

Edit:
OK, geht auch ohne
Hab' ich nie ohne Portmapping probiert (Schäm)

Nochmal Edit:
Den Disconnect hat das Entfernen der Portmappings nicht beeindruckt,
ebenso hat die Abschaltung des MDT-KNX-Routers keine Änderung ergeben:
Das mit den 120 Sekunden passt zum größten Teil, aber nicht immer...

@
Im iOBroker gebe ich die Adresse der KNX-Schnittstelle mit zugehörigem Port ein:
MDT-IP-Schnittstelle: keine Probleme.
TWS-IP-Schnittestelle: Problem: periodische Trennung der iOBroker KNX-Instanz.


knx.0 2019-10-23 19:26:26.042 info (1393) Connected - local UDP Server listening on 192.168.xxx:46008
knx.0 2019-10-23 19:26:26.039 info (1393) Using UDP with local IP: 192.168.xxx
knx.0 2019-10-23 19:26:24.038 info (1393) STATE_NOT_CONNECTED : Try to connect / reconnect : STATE_READY(7) to STATE_NOT_CONNECTED(0).
knx.0 2019-10-23 19:22:30.112 info (1393) Connected - local UDP Server listening on 192.168.xxx:36268
knx.0 2019-10-23 19:22:30.108 info (1393) Using UDP with local IP: 192.168.xxx
knx.0 2019-10-23 19:22:28.107 info (1393) STATE_NOT_CONNECTED : Try to connect / reconnect : STATE_READY(7) to STATE_NOT_CONNECTED(0).
knx.0 2019-10-23 19:20:04.039 info (1393) Connected - local UDP Server listening on 192.168.xxx:43256
knx.0 2019-10-23 19:20:04.035 info (1393) Using UDP with local IP: 192.168.xxx
knx.0 2019-10-23 19:20:02.034 info (1393) STATE_NOT_CONNECTED : Try to connect / reconnect : STATE_READY(7) to STATE_NOT_CONNECTED(0).
knx.0 2019-10-23 19:18:02.112 info (1393) Connected - local UDP Server listening on 192.168.xxx:57243
knx.0 2019-10-23 19:18:02.109 info (1393) Using UDP with local IP: 192.168.xxx
knx.0 2019-10-23 19:18:00.107 info (1393) STATE_NOT_CONNECTED : Try to connect / reconnect : STATE_READY(7) to STATE_NOT_CONNECTED(0).


(die ".xxx" kommen von mir)

Grüße
Thomas

[EarlBacid]

Im Gegenteil. was diese mapping macht, ist, dass es auf Seitens des Hosts versucht die Ports (3671 + 3674) zu öffnen und eingehende Verbindungen auf diesen Ports weiterzuleiten an den Docker, ebenfalls auf die Ports 3671 und 3674.
Dementsprechend versuchen auf dem TWS Host zwei Prozesse die selben Ports zu öffnen, der KNX Stack und der Docker Prozess. Das könnte durchaus zu sehr unschönem Verhalten führen und die Konfiguration macht so keinesfalls Sinn.
Was hattest du denn versucht zu erreichen mit diesem Mapping?

VG
Earl

[ms20de]

das sind die Ports meiner KNX-Schnittstellen. Brauch ich die gar nicht mappen?

Nein, die sollten nicht gemappt werden das kann zu Problemen mit dem KNX-Tunnel führen.
Bitte gib und noch Bescheid ob das Problem so gelöst wurde, oder es wieder auftritt.

Für alle die mitlesen und noch Probleme einen KNX-Tunnel und einem Container haben:

• Wird das standardmäßige "bridge" Netzwerk im Portainer verwendet, bitte die IP 172.17.0.1 in Container verwenden um den KNX-Daemon im Timberwolf anzusprechen.

• Wird ein MACVLAN-Netwerk im Container verwendet, die IP des Timberwolfs für die KNX-Kommunikation angeben. Die Netzwerkkarte des Timberwolfs muss im MACVLAN-Modus sein, sonst kommt keine Verbindung zustande.

Viele Grüße,
Matthias

[Tomtheripper]

Hallo Tom,

die Referenz für die Nutzung unserer Tunnel ist die ETS, weil darauf wurden wir zertifiziert. Daher die Frage:

==> Gibt es auch solche Verbindungsabbrüche auch mit der ETS, wenn Du damit einen Tunnel benutzt (also z.B. ETS mit Busmonitor starten und laufen lassen).

@ALL: Noch jemand der Probleme mit ioBroker bestätigen (oder auch nicht bestätigen) kann. Wir müssten schon wissen, ob das ein Einzelfall ist oder nicht

lg

Stefan

Nein, mit der ETS und TWS als Schnittstelle gibt es keine Verbindungsabbrüche!

Gruß
Thomas

[ms20de]

Hallo Tom,

kannst du uns bitte noch sagen, wasd du hier im IOBroker einstellst, wenn du die Verbindung zum Timberwolf machst?



Viele Grüße,
Matthias

[ms20de]

Hallo Zusammen,

wir haben das Problem mit den Verbindungsabbrüchen ins Zusammenhang mit IOBroker untersucht.
Beim Verbindungaufbau des KNX IP Tunnels scheinen vom IOBroker KNX Adapter Daten gesendet zu werden, die der KNX Standard nicht so vorsieht.
Aus diesem Grund werden die Anfragen zum Status der Verbindung nicht beantwortet und die Verbindung wird nach zwei Minuten geschlossen.
Wir haben diesbezüglich das Team für den IOBroker Adapter kontaktiert.

Viele Grüße,
Matthias

[CHD]

Uhi, jetzt supportet ihr ja auch noch über den TWS hinaus externe Software, wow

VG,
Christian

[Tomtheripper]

Hallo Zusammen,

wir haben das Problem mit den Verbindungsabbrüchen ins Zusammenhang mit IOBroker untersucht.
Beim Verbindungaufbau des KNX IP Tunnels scheinen vom IOBroker KNX Adapter Daten gesendet zu werden, die der KNX Standard nicht so vorsieht.
Aus diesem Grund werden die Anfragen zum Status der Verbindung nicht beantwortet und die Verbindung wird nach zwei Minuten geschlossen.
Wir haben diesbezüglich das Team für den IOBroker Adapter kontaktiert.

Viele Grüße,
Matthias

Vielen Dank, das ist ist super!!!

[Tomtheripper]

Hallo Tom,

kannst du uns bitte noch sagen, wasd du hier im IOBroker einstellst, wenn du die Verbindung zum Timberwolf machst?



Viele Grüße,
Matthias

Hallo Matthias,

nur der Vollständigkeit halber:
Ich kann gar kein KNX-Send-Delay einstellen, wird bei mir nicht angezeigt.

Aber ihr habt ja schon rausgefunden, dass das Problem beim knx-Adapter zu suchen ist und dem Entwickler mitgeteilt.
Nochmals Danke!!!

Beste Grüße
Tom