NEU! UPGRADE IP 11 verfügbar!
NEU! LICHTWIDGET - DPT 7.600 - Logik Manager Update - sowie viele weitere Verbesserungen
Infos im Wiki: https://elabnet.atlassian.net/l/cp/B9MUEJj2
Insider & Leistungsmerkmale FÜR ALLE freigeschaltet
Ab sofort kann jeder die neue VISU & IFTTT testen. Info: viewtopic.php?f=8&t=5074
Release V 4 am 15. Juni 2024
Es gibt nun einen fixen Termin. Info: viewtopic.php?f=8&t=5117
NEU! Ausführliches Video Tutorial zur VISU
Jetzt werden alle Fragen beantwortet. Das Video: https://youtu.be/_El-zaC2Rrs
NEU! LICHTWIDGET - DPT 7.600 - Logik Manager Update - sowie viele weitere Verbesserungen
Infos im Wiki: https://elabnet.atlassian.net/l/cp/B9MUEJj2
Insider & Leistungsmerkmale FÜR ALLE freigeschaltet
Ab sofort kann jeder die neue VISU & IFTTT testen. Info: viewtopic.php?f=8&t=5074
Release V 4 am 15. Juni 2024
Es gibt nun einen fixen Termin. Info: viewtopic.php?f=8&t=5117
NEU! Ausführliches Video Tutorial zur VISU
Jetzt werden alle Fragen beantwortet. Das Video: https://youtu.be/_El-zaC2Rrs
[Problem] IOBroker KNX-Schnittstelle periodische Unterbrechnung
-
- Elaborated Networks
- Reactions:
- Beiträge: 6
- Registriert: So Aug 19, 2018 9:58 am
- Danksagung erhalten: 8 Mal
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.
Zur genauen Untersuchung brauche ich allerdings eine passende Testumgebung (eventuell den Container). Das wird gerade geklärt.
-
- Reactions:
- Beiträge: 135
- Registriert: Mo Okt 01, 2018 11:34 am
- Hat sich bedankt: 62 Mal
- Danksagung erhalten: 37 Mal
Hallo,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:
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
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
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
-
- Reactions:
- Beiträge: 371
- Registriert: So Aug 26, 2018 5:59 pm
- Wohnort: Herborn
- Hat sich bedankt: 134 Mal
- Danksagung erhalten: 235 Mal
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
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
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
-
- Elaborated Networks
- Reactions:
- Beiträge: 995
- Registriert: Sa Aug 11, 2018 9:14 pm
- Hat sich bedankt: 281 Mal
- Danksagung erhalten: 500 Mal
Nein, die sollten nicht gemappt werden das kann zu Problemen mit dem KNX-Tunnel führen.Tomtheripper hat geschrieben: ↑Mi Okt 23, 2019 6:49 pm das sind die Ports meiner KNX-Schnittstellen. Brauch ich die gar nicht mappen?
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.
Matthias
[ Timberwolf Entwicklung ]
TWS 2400 ID:102 VPN offen, Reboot auf Nachfrage
TWS 2400 ID:102 VPN offen, Reboot auf Nachfrage
-
- Reactions:
- Beiträge: 135
- Registriert: Mo Okt 01, 2018 11:34 am
- Hat sich bedankt: 62 Mal
- Danksagung erhalten: 37 Mal
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
-
- Elaborated Networks
- Reactions:
- Beiträge: 995
- Registriert: Sa Aug 11, 2018 9:14 pm
- Hat sich bedankt: 281 Mal
- Danksagung erhalten: 500 Mal
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
kannst du uns bitte noch sagen, wasd du hier im IOBroker einstellst, wenn du die Verbindung zum Timberwolf machst?
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
TWS 2400 ID:102 VPN offen, Reboot auf Nachfrage
-
- Elaborated Networks
- Reactions:
- Beiträge: 995
- Registriert: Sa Aug 11, 2018 9:14 pm
- Hat sich bedankt: 281 Mal
- Danksagung erhalten: 500 Mal
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
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
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
TWS 2400 ID:102 VPN offen, Reboot auf Nachfrage
-
- Reactions:
- Beiträge: 304
- Registriert: Fr Dez 14, 2018 9:32 pm
- Wohnort: Gronau
- Hat sich bedankt: 1035 Mal
- Danksagung erhalten: 212 Mal
Uhi, jetzt supportet ihr ja auch noch über den TWS hinaus externe Software, wow
VG,
Christian
VG,
Christian
Viele Grüße, Christian
Timberwolf Server 2600 #200 ULTRA842 / PBM #778 / PBM #779 / PBM #780 / Reboot erlaubt / VPN offen
Timberwolf Server 2600 #200 ULTRA842 / PBM #778 / PBM #779 / PBM #780 / Reboot erlaubt / VPN offen
-
- Reactions:
- Beiträge: 135
- Registriert: Mo Okt 01, 2018 11:34 am
- Hat sich bedankt: 62 Mal
- Danksagung erhalten: 37 Mal
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.
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!!!
TW2400 #149 / Wartungs-VPN an / Neustart jederzeit / TP-UART Light geflasht 8 Tunnel / PBM01-USB 542
-
- Reactions:
- Beiträge: 135
- Registriert: Mo Okt 01, 2018 11:34 am
- Hat sich bedankt: 62 Mal
- Danksagung erhalten: 37 Mal
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
TW2400 #149 / Wartungs-VPN an / Neustart jederzeit / TP-UART Light geflasht 8 Tunnel / PBM01-USB 542