FREIGEGEBENE HAUPTVERSION V 4.01 verfügbar!
LOGIK! VISU! IFTTT! FIXES!
Infos im Wiki: https://elabnet.atlassian.net/l/cp/TrZ03Nr7

NEU! Ausführliches Video Tutorial zur VISU
Jetzt werden alle Fragen beantwortet. Das Video: https://youtu.be/_El-zaC2Rrs

[Frage] [V4.0 IP12] HA baut nach Neustart keine KNX Verbindung über TWS auf

Eure Wünsche und Phantasien
Forumsregeln
  • Denke bitte an aussagekräftige Titel und gebe dort auch die [Firmware] an. Wenn ETS oder CometVisu beteiligt sind, dann auch deren Version
  • Bitte mache vollständige Angaben zu Deinem Server, dessen ID und dem Online-Status in Deiner Signatur. Hilfreich ist oft auch die Beschreibung der angeschlossener Hardware sowie die verwendeten Protokolle
  • Beschreibe Dein Projekt und Dein Problem bitte vollständig. Achte bitte darauf, dass auf Screenshots die Statusleiste sichtbar ist
  • Bitte sei stets freundlich und wohlwollend, bleibe beim Thema und unterschreibe mit deinem Vornamen. Bitte lese alle Regeln, die Du hier findest: https://wiki.timberwolf.io/Forenregeln
Antworten

Ersteller
worie
Reactions:
Beiträge: 5
Registriert: Di Mai 28, 2024 10:33 pm
Danksagung erhalten: 5 Mal

[V4.0 IP12] HA baut nach Neustart keine KNX Verbindung über TWS auf

#1

Beitrag von worie »

Moin,

gibt es irgendwo in der Benutzeroberfläche ein Live Syslog welches ich beobachten kann?

Mein Problem ist, dass die KNX Integration von Homeassistant nach einem Neustart von Homeassistant so lange immer keine Verbindung zu KNX über Timberwolf Server herstellen kann, bis ich selbigen auch neu gestartet habe. Ich würde daher gerne sehen, warum Timberwolf die Verbindung ablehnt. Falls einer sonst einen Tipp hat, warum dies passiert nehm ich auch natürlich gerne direkt die Lösung statt selbst zu suchen ;)
Zuletzt geändert von Mibr85 am Di Jun 11, 2024 6:28 pm, insgesamt 2-mal geändert.
TWS1438 - 3500 / PBM
Nach oben

blaubaerli
Reactions:
Beiträge: 2429
Registriert: Sa Sep 15, 2018 10:26 am
Wohnort: Kerpen
Hat sich bedankt: 918 Mal
Danksagung erhalten: 716 Mal

#2

Beitrag von blaubaerli »

Hallo ????@worie,

zunächst mal herzlich willkommen hier bei uns im Forum. Wir sprechen uns hier gerne beim Vornamen an.

Bitte beachte doch auch unsere Forenregeln (siehe blaue Box oben) und füge die Versionsinformation deines TWS entsprechend im Betreff hinzu und den Rest dann bitte in deine Signatur.

Danke. :handgestures-salute:

Beste Grüße
Jens
wiregate1250 & timberwolf168 (2600er), VPN offen, Reboot nach Vereinbarung
Bitte WIKI lesen.
Nach oben
Benutzeravatar

cybersmart
Reactions:
Beiträge: 245
Registriert: Do Jan 20, 2022 6:15 pm
Wohnort: Germering
Hat sich bedankt: 144 Mal
Danksagung erhalten: 151 Mal
Kontaktdaten:
Kontaktdaten von cybersmart

#3

Beitrag von cybersmart »

Herzlich willkommen,

bzgl. Logs kann ich gerade nicht weiter helfen, aber du kannst statt den Server auch nur den KNX Deamon neu starten und mal prüfen ob das ausreicht.
Wie verbindet sich denn Home Assistant bei Dir mit KNX (nehme an Tunnel über den TWS?).
VG, Uwe

timberwolf765 VPN: offen Reboot: ok
Nach oben

gbglace
Reactions:
Beiträge: 3700
Registriert: So Aug 12, 2018 10:20 am
Hat sich bedankt: 1293 Mal
Danksagung erhalten: 1703 Mal

#4

Beitrag von gbglace »

Da knne auch was in der Verbindung HA zu TWS via LAN instabil sein und HA sukzessive die 25 Tunnel blockieren. Da würde ich dann mal im TWS in den KNX-Interfaces schauen.

Aber ohne die Versionsangaben der Software ist schwer zu beurteilen ob es bekannte gelöste oder neue Probleme sind.
Derrrrrelbst passt auch nicht ganz zum Inhalt, aber das kann man noch nachschärfen. Und Angaben zum Systemaufbau wie auf welcher Platform läuft der HA über welche Wege kann der den TWS erreichen. Alles Angaben die in der Beschreibung fehlen um eine sinnvolle Diagnose zu erstellen.
Grüße
Göran

#1 Timberwolf 2600 Velvet Red TWS #225 / VPN aktiv / Reboot OK
#2 Timberwolf 2600 Organic Silver TWS #438 / VPN aktiv / Reboot OK
#3 PBM 3 Kanäle, #4 Modbus-Extension
Nach oben

ms20de
Elaborated Networks
Reactions:
Beiträge: 1046
Registriert: Sa Aug 11, 2018 9:14 pm
Hat sich bedankt: 294 Mal
Danksagung erhalten: 539 Mal

#5

Beitrag von ms20de »

Hier ein Beispiel eine normalen Verbindungslog im Timberwolf Server. (KNX->Schnittstellen)

Bild

Man sieht die aktiven Verbindungen, die programmieren Tunnel PAs und während die Seite geöffnet ist auch die Zeitpunkte von Verbindungsab- und aufbau. Im Normalbetrieb sollte sich hier nicht viel verändern, sonst liegt wahrscheinlich ein Problem vor.

Viele Grüße,
Matthias
[ Timberwolf Entwicklung ]

TWS 2400 ID:102 VPN offen, Reboot auf Nachfrage
Nach oben

Ersteller
worie
Reactions:
Beiträge: 5
Registriert: Di Mai 28, 2024 10:33 pm
Danksagung erhalten: 5 Mal

#6

Beitrag von worie »

Moin,

danke für die zahlreichen Hinweise. Mir ging es wie gesagt in erster Linie um einen Log View der Anfragen die an den TWS gehen. Es handelt sich um einen 3500, mit Insider 4.0 Preview 12

Homeassistant läuft als VM im gleichen VLAN wie der TWS. Nach einem erfolgten Neustart des TWS sehe ich auch direkt die erfolgreiche Verbindung von HA. Wenn ich HA so aber durchstarte, kommt keine Verbindung mehr zustande. Ein Restart des KNX Daemons bringt hier nichts. Starte ich den TWS neu findet HA selbstständig direkt wieder die Verbindung und läuft auch schnell und performant mit einer IP Verbindung, es werden nicht immer wieder neue Verbindungen aufgebaut. Es scheint so, als ob der TWS die einmal verwendete Verbindung blockiert.

Viele Grüße

Wolf
TWS1438 - 3500 / PBM
Nach oben

gbglace
Reactions:
Beiträge: 3700
Registriert: So Aug 12, 2018 10:20 am
Hat sich bedankt: 1293 Mal
Danksagung erhalten: 1703 Mal

#7

Beitrag von gbglace »

Das ist komisch, da der TWS selbst keine Firewall hat würde ich sagen der ist da weniger Schuld dran das er einen Zugriff auf seine IP-Adresse mit den möglichen KNX-Ports blockiert.

Klingt mir eher an einer Einstellung im LAN die dazu führt, dass bei einem Reset der LAN Verbindung vom HA da nix mehr ankommt am TWS.

Aber da bin ich zu wenig Netzwerkjunkie um das genauer zu beurteilen.

Was organisierten denn bei Dir das VLAN?
Grüße
Göran

#1 Timberwolf 2600 Velvet Red TWS #225 / VPN aktiv / Reboot OK
#2 Timberwolf 2600 Organic Silver TWS #438 / VPN aktiv / Reboot OK
#3 PBM 3 Kanäle, #4 Modbus-Extension
Nach oben

Ersteller
worie
Reactions:
Beiträge: 5
Registriert: Di Mai 28, 2024 10:33 pm
Danksagung erhalten: 5 Mal

#8

Beitrag von worie »

So, ich hab jetzt in HA die KNX logs aktiviert und folgendes gefunden

so sieht es aus, wenn HA vor dem TWS neu startet. Es wird scheinbar ein UDP an die Broadcast adresse gesendet, es kommt aber nie eine Antwort.

Code: Alles auswählen

2024-06-10 21:00:18.709 INFO (MainThread) [xknx.log] XKNX v2.12.2 starting automatic connection to KNX bus.
2024-06-10 21:00:18.749 DEBUG (KNX Interface) [xknx.log] Using local ip: 10.10.30.2
2024-06-10 21:00:18.749 DEBUG (KNX Interface) [xknx.log] Searching on enp0s18 / 10.10.30.2
2024-06-10 21:00:18.750 DEBUG (KNX Interface) [xknx.knx] Sending to 224.0.23.12:3671: <KNXIPFrame <KNXIPHeader HeaderLength="6" ProtocolVersion="16" KNXIPServiceType="SEARCH_REQUEST_EXTENDED" TotalLength="20" /> body="<SearchRequestExtended discovery_endpoint="10.10.30.2:59413/udp" srps="[<xknx.knxip.srp.SRP object at 0x7f1168c8a5d0>]" />" />
2024-06-10 21:00:18.750 DEBUG (KNX Interface) [xknx.knx] Sending to 224.0.23.12:3671: <KNXIPFrame <KNXIPHeader HeaderLength="6" ProtocolVersion="16" KNXIPServiceType="SEARCH_REQUEST" TotalLength="14" /> body="<SearchRequest discovery_endpoint="10.10.30.2:59413/udp" />" />
2024-06-10 21:00:21.753 DEBUG (KNX Interface) [xknx.log] Closing UDP transport.
Wenn man TWS im laufenden Betrieb von HA neu startet sieht die nächste Meldung zunächst genauso aus, nur dass diesmal eine Antwort vom TWS kommt welche die richtige IP des TWS enthält woraufhin der Tunnel aufgebaut wird. 10.10.30.2 ist HA, 10.10.30.5 ist der TWS

Code: Alles auswählen

2024-06-10 21:01:42.087 INFO (MainThread) [xknx.log] XKNX v2.12.2 starting automatic connection to KNX bus.
2024-06-10 21:01:42.125 DEBUG (KNX Interface) [xknx.log] Using local ip: 10.10.30.2
2024-06-10 21:01:42.126 DEBUG (KNX Interface) [xknx.log] Searching on enp0s18 / 10.10.30.2
2024-06-10 21:01:42.126 DEBUG (KNX Interface) [xknx.knx] Sending to 224.0.23.12:3671: <KNXIPFrame <KNXIPHeader HeaderLength="6" ProtocolVersion="16" KNXIPServiceType="SEARCH_REQUEST_EXTENDED" TotalLength="20" /> body="<SearchRequestExtended discovery_endpoint="10.10.30.2:44356/udp" srps="[<xknx.knxip.srp.SRP object at 0x7f116433ec30>]" />" />
2024-06-10 21:01:42.126 DEBUG (KNX Interface) [xknx.knx] Sending to 224.0.23.12:3671: <KNXIPFrame <KNXIPHeader HeaderLength="6" ProtocolVersion="16" KNXIPServiceType="SEARCH_REQUEST" TotalLength="14" /> body="<SearchRequest discovery_endpoint="10.10.30.2:44356/udp" />" />
2024-06-10 21:01:42.128 DEBUG (KNX Interface) [xknx.knx] Received from 10.10.30.5:3671: <KNXIPFrame <KNXIPHeader HeaderLength="6" ProtocolVersion="16" KNXIPServiceType="SEARCH_RESPONSE" TotalLength="76" /> body="<SearchResponse control_endpoint="10.10.30.5:3700/udp" dibs="[
2024-06-10 21:01:42.129 DEBUG (KNX Interface) [xknx.log] Found KNX/IP device at 10.10.30.5:3671/udp: GatewayDescriptor(
2024-06-10 21:01:42.129 DEBUG (KNX Interface) [xknx.log] Using interface: enp0s18
2024-06-10 21:01:42.129 DEBUG (KNX Interface) [xknx.log] Starting tunnel from 10.10.30.2:0 to 10.10.30.5:3700
2024-06-10 21:01:42.130 DEBUG (KNX Interface) [xknx.knx] Sending to 10.10.30.5:3700: <KNXIPFrame <KNXIPHeader HeaderLength="6" ProtocolVersion="16" KNXIPServiceType="CONNECT_REQUEST" TotalLength="26" /> body="<ConnectRequest control_endpoint="10.10.30.2:33999/udp" data_endpoint="10.10.30.2:33999/udp" cri="<ConnectRequestInformation connection_type="TUNNEL_CONNECTION" knx_layer="DATA_LINK_LAYER" />" />" />
2024-06-10 21:01:42.133 DEBUG (KNX Interface) [xknx.knx] Received from 10.10.30.5:3700: <KNXIPFrame <KNXIPHeader HeaderLength="6" ProtocolVersion="16" KNXIPServiceType="CONNECT_RESPONSE" TotalLength="20" /> body="<ConnectResponse communication_channel="1" status_code="ErrorCode.E_NO_ERROR" data_endpoint="10.10.30.5:3700/udp" crd="<ConnectResponseData request_type="ConnectRequestType.TUNNEL_CONNECTION" individual_address="1.0.2" />" />" />
2024-06-10 21:01:42.133 DEBUG (KNX Interface) [xknx.log] Tunnel established. communication_channel=1, address=1.0.2
2024-06-10 21:01:42.134 DEBUG (KNX Interface) [xknx.log] Closing UDP transport.
Hat jemand eine Erklärung, warum die Übersetzung von Broadcast in Tunnel nur einmal pro Neustart funktioniert?
TWS1438 - 3500 / PBM
Nach oben

gbglace
Reactions:
Beiträge: 3700
Registriert: So Aug 12, 2018 10:20 am
Hat sich bedankt: 1293 Mal
Danksagung erhalten: 1703 Mal

#9

Beitrag von gbglace »

worie hat geschrieben: ↑Mo Jun 10, 2024 9:12 pm so sieht es aus, wenn HA vor dem TWS neu startet. Es wird scheinbar ein UDP an die Broadcast adresse gesendet, es kommt aber nie eine Antwort.
Das klingt erstmal sehr logisch, wenn der TWS offline bzw der KNX noch nicht fertig mit hochfahren ist, kann er auch nicht antworten.

worie hat geschrieben: ↑Mo Jun 10, 2024 9:12 pm Wenn man TWS im laufenden Betrieb von HA neu startet sieht die nächste Meldung zunächst genauso aus, nur dass diesmal eine Antwort vom TWS kommt welche die richtige IP des TWS enthält woraufhin der Tunnel aufgebaut wird. 10.10.30.2 ist HA, 10.10.30.5 ist der TWS
Mir stellt sich eher die Frage wie oft versucht HA denn solch einen Netzwerkscan um KNX IP-Teilnehmer zu finden und nach einem Tunnel zu schauen?

Die beiden Szenarien mit dem Log hier sind erstmal kein fehlerhaftes Szenario. Da funktioniert das doch wie es soll.

Das Dritte Szenario was Du mit einem solchen Log zeigen solltest wäre. Der TWS ist online und läuft und nur HA startet neu.
Das Szenario fehlt und dazu bräuchte es ein Log.
Und da stellt sich dann die Frage wo hängt es. Im KNX-UF der Meti kennt sich da ganz gut aus beim Systemverhalten HA und Kommunikation mit diversen KNX-IP Schnittstellen. Ichglaube er entwickelt da auch einiges für HA.

Das letzte Szenario kannst auch mal im TWS-Monitor der KNX-Interfaces beobachten. Da sollte ein disconnect des HA wenn der abschaltet ja auch ersichtlich sein. Wenn nicht, dann wäre ein Ansatz das wenn der wieder kommt der TWS ggf denkt der war ja nie weg.
Grüße
Göran

#1 Timberwolf 2600 Velvet Red TWS #225 / VPN aktiv / Reboot OK
#2 Timberwolf 2600 Organic Silver TWS #438 / VPN aktiv / Reboot OK
#3 PBM 3 Kanäle, #4 Modbus-Extension
Nach oben

Ersteller
worie
Reactions:
Beiträge: 5
Registriert: Di Mai 28, 2024 10:33 pm
Danksagung erhalten: 5 Mal

#10

Beitrag von worie »

Moin,

beide Szenarien sind im jeweils laufenden Betrieb beider Komponenten, es geht um einen neustart. Es kommt sehr viel häufiger vor, dass HA zumindest teilweise neu startet als das es der TWS tut. Hier liefen also beide Instanzen, dann wurde HA nach einem Update neu gestartet und bekommt solange keine Verbindung, bis der TWS auch neustartet.

Das log sieht so aus wie der erste Codeblock und wiederholt sich alle paar Sekunden. Sobald der TWS nach dem Restart wieder auch nur teilweise oben ist, kommt sofort die Verbindung zustande. HA pingt also permanent die Verbindung, bis er ein ACK bekommt und dann über den Tunnel läuft.

noch einmal nachgestellt. HA im laufenden Betrieb neugestartet, TWS läuft durch

Code: Alles auswählen

2024-06-11 09:35:20.881 INFO (MainThread) [xknx.log] XKNX v2.12.2 starting automatic connection to KNX bus.
2024-06-11 09:35:20.927 DEBUG (KNX Interface) [xknx.log] Using local ip: 10.10.30.2
2024-06-11 09:35:20.929 DEBUG (KNX Interface) [xknx.log] Searching on enp0s18 / 10.10.30.2
2024-06-11 09:35:20.929 DEBUG (KNX Interface) [xknx.knx] Sending to 224.0.23.12:3671: <KNXIPFrame <KNXIPHeader HeaderLength="6" ProtocolVersion="16" KNXIPServiceType="SEARCH_REQUEST_EXTENDED" TotalLength="20" /> body="<SearchRequestExtended discovery_endpoint="10.10.30.2:56009/udp" srps="[<xknx.knxip.srp.SRP object at 0x7fdc76078da0>]" />" />
2024-06-11 09:35:20.931 DEBUG (KNX Interface) [xknx.knx] Sending to 224.0.23.12:3671: <KNXIPFrame <KNXIPHeader HeaderLength="6" ProtocolVersion="16" KNXIPServiceType="SEARCH_REQUEST" TotalLength="14" /> body="<SearchRequest discovery_endpoint="10.10.30.2:56009/udp" />" />
2024-06-11 09:35:23.933 DEBUG (KNX Interface) [xknx.log] Closing UDP transport.
2024-06-11 09:35:33.064 INFO (MainThread) [xknx.log] XKNX v2.12.2 starting automatic connection to KNX bus.
2024-06-11 09:35:33.150 DEBUG (KNX Interface) [xknx.log] Using local ip: 10.10.30.2
2024-06-11 09:35:33.166 DEBUG (KNX Interface) [xknx.log] Searching on enp0s18 / 10.10.30.2
2024-06-11 09:35:33.168 DEBUG (KNX Interface) [xknx.knx] Sending to 224.0.23.12:3671: <KNXIPFrame <KNXIPHeader HeaderLength="6" ProtocolVersion="16" KNXIPServiceType="SEARCH_REQUEST_EXTENDED" TotalLength="20" /> body="<SearchRequestExtended discovery_endpoint="10.10.30.2:54478/udp" srps="[<xknx.knxip.srp.SRP object at 0x7fdc5b6601d0>]" />" />
2024-06-11 09:35:33.168 DEBUG (KNX Interface) [xknx.knx] Sending to 224.0.23.12:3671: <KNXIPFrame <KNXIPHeader HeaderLength="6" ProtocolVersion="16" KNXIPServiceType="SEARCH_REQUEST" TotalLength="14" /> body="<SearchRequest discovery_endpoint="10.10.30.2:54478/udp" />" />
2024-06-11 09:35:36.172 DEBUG (KNX Interface) [xknx.log] Closing UDP transport.
2024-06-11 09:35:46.632 INFO (MainThread) [xknx.log] XKNX v2.12.2 starting automatic connection to KNX bus.
2024-06-11 09:35:46.671 DEBUG (KNX Interface) [xknx.log] Using local ip: 10.10.30.2
2024-06-11 09:35:46.672 DEBUG (KNX Interface) [xknx.log] Searching on enp0s18 / 10.10.30.2
2024-06-11 09:35:46.672 DEBUG (KNX Interface) [xknx.knx] Sending to 224.0.23.12:3671: <KNXIPFrame <KNXIPHeader HeaderLength="6" ProtocolVersion="16" KNXIPServiceType="SEARCH_REQUEST_EXTENDED" TotalLength="20" /> body="<SearchRequestExtended discovery_endpoint="10.10.30.2:45212/udp" srps="[<xknx.knxip.srp.SRP object at 0x7fdc5a3c6390>]" />" />
2024-06-11 09:35:46.672 DEBUG (KNX Interface) [xknx.knx] Sending to 224.0.23.12:3671: <KNXIPFrame <KNXIPHeader HeaderLength="6" ProtocolVersion="16" KNXIPServiceType="SEARCH_REQUEST" TotalLength="14" /> body="<SearchRequest discovery_endpoint="10.10.30.2:45212/udp" />" />
2024-06-11 09:35:49.676 DEBUG (KNX Interface) [xknx.log] Closing UDP transport.
2024-06-11 09:36:09.778 INFO (MainThread) [xknx.log] XKNX v2.12.2 starting automatic connection to KNX bus.
2024-06-11 09:36:09.817 DEBUG (KNX Interface) [xknx.log] Using local ip: 10.10.30.2
2024-06-11 09:36:09.818 DEBUG (KNX Interface) [xknx.log] Searching on enp0s18 / 10.10.30.2
2024-06-11 09:36:09.818 DEBUG (KNX Interface) [xknx.knx] Sending to 224.0.23.12:3671: <KNXIPFrame <KNXIPHeader HeaderLength="6" ProtocolVersion="16" KNXIPServiceType="SEARCH_REQUEST_EXTENDED" TotalLength="20" /> body="<SearchRequestExtended discovery_endpoint="10.10.30.2:42945/udp" srps="[<xknx.knxip.srp.SRP object at 0x7fdc5850b3b0>]" />" />
2024-06-11 09:36:09.818 DEBUG (KNX Interface) [xknx.knx] Sending to 224.0.23.12:3671: <KNXIPFrame <KNXIPHeader HeaderLength="6" ProtocolVersion="16" KNXIPServiceType="SEARCH_REQUEST" TotalLength="14" /> body="<SearchRequest discovery_endpoint="10.10.30.2:42945/udp" />" />
2024-06-11 09:36:12.822 DEBUG (KNX Interface) [xknx.log] Closing UDP transport.
In der TWS Schnittstellen Sicht verschwindet HA beim klick auf Neustart direkt aus der Liste der Verbindungen und kommt nicht wieder.

Nach einem Restart vom TWS bei laufendem HA sieht das log so aus. Einen fehlgeschlagenen Versuch habe ich zu dokumentationszwecken drin gelassen:

Code: Alles auswählen

2024-06-11 09:39:39.945 INFO (MainThread) [xknx.log] XKNX v2.12.2 starting automatic connection to KNX bus.
2024-06-11 09:39:39.992 DEBUG (KNX Interface) [xknx.log] Using local ip: 10.10.30.2
2024-06-11 09:39:39.993 DEBUG (KNX Interface) [xknx.log] Searching on enp0s18 / 10.10.30.2
2024-06-11 09:39:39.993 DEBUG (KNX Interface) [xknx.knx] Sending to 224.0.23.12:3671: <KNXIPFrame <KNXIPHeader HeaderLength="6" ProtocolVersion="16" KNXIPServiceType="SEARCH_REQUEST_EXTENDED" TotalLength="20" /> body="<SearchRequestExtended discovery_endpoint="10.10.30.2:37059/udp" srps="[<xknx.knxip.srp.SRP object at 0x7fdc58436900>]" />" />
2024-06-11 09:39:39.993 DEBUG (KNX Interface) [xknx.knx] Sending to 224.0.23.12:3671: <KNXIPFrame <KNXIPHeader HeaderLength="6" ProtocolVersion="16" KNXIPServiceType="SEARCH_REQUEST" TotalLength="14" /> body="<SearchRequest discovery_endpoint="10.10.30.2:37059/udp" />" />
2024-06-11 09:39:42.995 DEBUG (KNX Interface) [xknx.log] Closing UDP transport.
2024-06-11 09:41:03.181 INFO (MainThread) [xknx.log] XKNX v2.12.2 starting automatic connection to KNX bus.
2024-06-11 09:41:03.221 DEBUG (KNX Interface) [xknx.log] Using local ip: 10.10.30.2
2024-06-11 09:41:03.222 DEBUG (KNX Interface) [xknx.log] Searching on enp0s18 / 10.10.30.2
2024-06-11 09:41:03.223 DEBUG (KNX Interface) [xknx.knx] Sending to 224.0.23.12:3671: <KNXIPFrame <KNXIPHeader HeaderLength="6" ProtocolVersion="16" KNXIPServiceType="SEARCH_REQUEST_EXTENDED" TotalLength="20" /> body="<SearchRequestExtended discovery_endpoint="10.10.30.2:51028/udp" srps="[<xknx.knxip.srp.SRP object at 0x7fdc6ca75670>]" />" />
2024-06-11 09:41:03.223 DEBUG (KNX Interface) [xknx.knx] Sending to 224.0.23.12:3671: <KNXIPFrame <KNXIPHeader HeaderLength="6" ProtocolVersion="16" KNXIPServiceType="SEARCH_REQUEST" TotalLength="14" /> body="<SearchRequest discovery_endpoint="10.10.30.2:51028/udp" />" />
2024-06-11 09:41:03.225 DEBUG (KNX Interface) [xknx.raw_socket] Received from ('10.10.30.5', 3671): 06100202004c08010a0a1e050e743601020010010000009fa4ac22cc00000000d83addbab0c654696d626572776f6c6620536572766572000000000000000000000000000802020104010301
2024-06-11 09:41:03.225 DEBUG (KNX Interface) [xknx.knx] Received from 10.10.30.5:3671: <KNXIPFrame <KNXIPHeader HeaderLength="6" ProtocolVersion="16" KNXIPServiceType="SEARCH_RESPONSE" TotalLength="76" /> body="<SearchResponse control_endpoint="10.10.30.5:3700/udp" dibs="[
2024-06-11 09:41:03.226 DEBUG (KNX Interface) [xknx.log] Found KNX/IP device at 10.10.30.5:3671/udp: GatewayDescriptor(
2024-06-11 09:41:03.226 DEBUG (KNX Interface) [xknx.log] Using interface: enp0s18
2024-06-11 09:41:03.226 DEBUG (KNX Interface) [xknx.log] Starting tunnel from 10.10.30.2:0 to 10.10.30.5:3700
2024-06-11 09:41:03.227 DEBUG (KNX Interface) [xknx.knx] Sending to 10.10.30.5:3700: <KNXIPFrame <KNXIPHeader HeaderLength="6" ProtocolVersion="16" KNXIPServiceType="CONNECT_REQUEST" TotalLength="26" /> body="<ConnectRequest control_endpoint="10.10.30.2:41341/udp" data_endpoint="10.10.30.2:41341/udp" cri="<ConnectRequestInformation connection_type="TUNNEL_CONNECTION" knx_layer="DATA_LINK_LAYER" />" />" />
2024-06-11 09:41:03.233 DEBUG (KNX Interface) [xknx.raw_socket] Received from ('10.10.30.5', 3700): 061002060014010008010a0a1e050e7404041002
2024-06-11 09:41:03.233 DEBUG (KNX Interface) [xknx.knx] Received from 10.10.30.5:3700: <KNXIPFrame <KNXIPHeader HeaderLength="6" ProtocolVersion="16" KNXIPServiceType="CONNECT_RESPONSE" TotalLength="20" /> body="<ConnectResponse communication_channel="1" status_code="ErrorCode.E_NO_ERROR" data_endpoint="10.10.30.5:3700/udp" crd="<ConnectResponseData request_type="ConnectRequestType.TUNNEL_CONNECTION" individual_address="1.0.2" />" />" />
2024-06-11 09:41:03.233 DEBUG (KNX Interface) [xknx.log] Tunnel established. communication_channel=1, address=1.0.2
2024-06-11 09:41:03.233 DEBUG (KNX Interface) [xknx.log] Closing UDP transport.
Der TWS scheint also nur einmal auf einen Broadcast einer bestimmten IP zu reagieren und danach nicht mehr. Kann man das irgendwo anpassen?
TWS1438 - 3500 / PBM
Nach oben
Antworten

Zurück zu „Feature Requests & Diskussionen Timberwolf Allgemein“