UPGRADE IP 9 verfügbar!
Timberwolf VISU jetzt mit NEUEM Layout Editor
Freie Anordnung, Reihenfolge und Größe der Widgets - viele weitere Verbesserungen
Infos im Wiki: https://elabnet.atlassian.net/l/cp/06SeuHRJ

NEU! Insider & Leistungsmerkmale FÜR ALLE freigeschaltet
Damit kann nun jeder das Upgrade vornehmen und VISU & IFTTT testen. Alle Info hier: viewtopic.php?f=8&t=5074

[Problem] IOBroker KNX-Schnittstelle periodische Unterbrechnung

Alles rund um io:Broker im Allgemeinen und den entsprechenden Docker-Container für den Timberwolf Server im Speziellen.

Gucki
Elaborated Networks
Reactions:
Beiträge: 6
Registriert: So Aug 19, 2018 9:58 am
Danksagung erhalten: 8 Mal

#11

Beitrag von 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.

Ersteller
Tomtheripper
Reactions:
Beiträge: 135
Registriert: Mo Okt 01, 2018 11:34 am
Hat sich bedankt: 62 Mal
Danksagung erhalten: 37 Mal

#12

Beitrag von Tomtheripper »

ms20de hat geschrieben: Di Okt 22, 2019 1:41 pm Hallo Thomas,

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

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 :oops:
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
Zuletzt geändert von Tomtheripper am Mi Okt 23, 2019 7:38 pm, insgesamt 2-mal geändert.
TW2400 #149 / Wartungs-VPN an / Neustart jederzeit / TP-UART Light geflasht 8 Tunnel / PBM01-USB 542

EarlBacid
Reactions:
Beiträge: 371
Registriert: So Aug 26, 2018 5:59 pm
Wohnort: Herborn
Hat sich bedankt: 134 Mal
Danksagung erhalten: 235 Mal

#13

Beitrag von 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
Wiregate#1504 + PBM -
Timberwolf 950Q #233 / VPN aktiv / Reboot OK
EFH mit KNX, 1-Wire, DMX, PV und Strom über MQTT
Docker: MQTT Broker, Unifi WLAN Controller, NodeJS, CometVisu

ms20de
Elaborated Networks
Reactions:
Beiträge: 972
Registriert: Sa Aug 11, 2018 9:14 pm
Hat sich bedankt: 280 Mal
Danksagung erhalten: 498 Mal

#14

Beitrag von ms20de »

Tomtheripper hat geschrieben: Mi Okt 23, 2019 6:49 pm 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
[ Timberwolf Entwicklung ]

TWS 2400 ID:102 VPN offen, Reboot auf Nachfrage

Ersteller
Tomtheripper
Reactions:
Beiträge: 135
Registriert: Mo Okt 01, 2018 11:34 am
Hat sich bedankt: 62 Mal
Danksagung erhalten: 37 Mal

#15

Beitrag von Tomtheripper »

StefanW hat geschrieben: Di Okt 22, 2019 1:45 am 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
TW2400 #149 / Wartungs-VPN an / Neustart jederzeit / TP-UART Light geflasht 8 Tunnel / PBM01-USB 542

ms20de
Elaborated Networks
Reactions:
Beiträge: 972
Registriert: Sa Aug 11, 2018 9:14 pm
Hat sich bedankt: 280 Mal
Danksagung erhalten: 498 Mal

#16

Beitrag von ms20de »

Hallo Tom,

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

Bild

Viele Grüße,
Matthias
Zuletzt geändert von ms20de am Mo Nov 04, 2019 12:43 pm, insgesamt 1-mal geändert.
[ Timberwolf Entwicklung ]

TWS 2400 ID:102 VPN offen, Reboot auf Nachfrage

ms20de
Elaborated Networks
Reactions:
Beiträge: 972
Registriert: Sa Aug 11, 2018 9:14 pm
Hat sich bedankt: 280 Mal
Danksagung erhalten: 498 Mal

#17

Beitrag von 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. :shock:
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
Zuletzt geändert von ms20de am Di Nov 05, 2019 6:42 pm, insgesamt 1-mal geändert.
[ Timberwolf Entwicklung ]

TWS 2400 ID:102 VPN offen, Reboot auf Nachfrage

CHD
Reactions:
Beiträge: 302
Registriert: Fr Dez 14, 2018 9:32 pm
Wohnort: Gronau
Hat sich bedankt: 1026 Mal
Danksagung erhalten: 212 Mal

#18

Beitrag von CHD »

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

VG,
Christian
Viele Grüße, Christian

Timberwolf Server 2600 #200 ULTRA842 / PBM #778 / PBM #779 / PBM #780 / Reboot erlaubt / VPN offen

Ersteller
Tomtheripper
Reactions:
Beiträge: 135
Registriert: Mo Okt 01, 2018 11:34 am
Hat sich bedankt: 62 Mal
Danksagung erhalten: 37 Mal

#19

Beitrag von Tomtheripper »

ms20de hat geschrieben: Di Nov 05, 2019 6:41 pm 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. :shock:
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!!! :bow-yellow:
:handgestures-thumbupright:
TW2400 #149 / Wartungs-VPN an / Neustart jederzeit / TP-UART Light geflasht 8 Tunnel / PBM01-USB 542

Ersteller
Tomtheripper
Reactions:
Beiträge: 135
Registriert: Mo Okt 01, 2018 11:34 am
Hat sich bedankt: 62 Mal
Danksagung erhalten: 37 Mal

#20

Beitrag von Tomtheripper »

ms20de hat geschrieben: Mo Nov 04, 2019 12:42 pm Hallo Tom,

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

Bild

Viele Grüße,
Matthias

Hallo Matthias,

nur der Vollständigkeit halber:
Ich kann gar kein KNX-Send-Delay einstellen, wird bei mir nicht angezeigt.
Bild
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
TW2400 #149 / Wartungs-VPN an / Neustart jederzeit / TP-UART Light geflasht 8 Tunnel / PBM01-USB 542
Antworten

Zurück zu „Docker Container: ioBroker“