ElabNET Technik Forum

Hallo,
ich betreibe seit Jahren ein Wiregate und nutze dieses auch als IP-Router für KNX. Das hat eigentlich auch immer gut geklappt. Jetzt versuche ich aber mit ioBroker darauf zuzugreifen, was grundsätzlich auch klappt, leider aber nicht stabil. Der Grund hierfür ist scheinbar, dass Wiregate manchmal einen Verbindungs-Status sendet, den ioBroker nicht interpretieren kann.

ioBroker sendet regelmäßig einen "State_connection_request", welcher vom Wiregate normalerweise mit folgendem "CONNECTIONSTATE_RESPONSE" beantwortet wird:

Received CONNECTIONSTATE_RESPONSE : 06 10 02 08 00 08 02 00 192.168.178.32:3671 ChID : 2 SeqCntIN : 234 SeqCntOUT : 97 msgCode : [object Object]

Dann funktioniert auch alles vernünftig. Manchmal sendet Wiregate aber folgende Antwort:

Received CONNECTIONSTATE_RESPONSE : 06 10 02 08 00 08 02 15 192.168.178.32:3671 ChID : 2 SeqCntIN : 72 SeqCntOUT : 97 msgCode : [object Object]

Mit dieser Antwort kann ioBroker wohl nichts anfangen und beendet die Verbindung. Im Log sieht das dann so aus:

knx.0 (32461) STATE_DISCONNECT_REQUEST : no defined handling for transition from State: STATE_CONNECTION_STATE_RESPONSE(6) to STATE_DISCONNECT_REQUEST(15).
knx.0 (32461) Connection persists.....closing now
knx.0 (32461) ... not able to close connection, because already closed
knx.0 (32461) STATE_NOT_CONNECTED : Try to connect / reconnect : STATE_DISCONNECT_REQUEST(15) to STATE_NOT_CONNECTED(0).
knx.0 (32461) ...set STATE-NOT-CONNECTED
knx.0 (32461) Connection persists.....closing now
knx.0 (32461) ... not able to close connection, because already closed
knx.0 (32461) STATE_NOT_CONNECTED : Stop connection : STATE_NOT_CONNECTED(0) to STATE_NOT_CONNECTED(0).
knx.0 (32461) Using UDP with local IP: 192.168.178.162
knx.0 (32461) Event : UDP - listening
knx.0 (32461) Connected - local UDP Server listening on 192.168.178.162:38802

Kann mir jemand sagen, was der Status "15" wohl bedeutet? Wenn ich dann noch wüsste, wie ich dies verhindern kann, wäre es natürlich super..

Vielen Dank und liebe Grüße

Michael

Das wiregate nutzt als Schnittstelle den eibd, das ist eine nicht zertifizierte Software die das KNX-Routingprotokoll emuliert. Der iO-Broker ist ebenfalls nicht dafür bekannt eine saubere Umsetzung des KNX-Protokolls zu besitzen.

Das dann bei solchen Experimenten eine nicht unbedingt funktionierende Lösung raus kommt ist naheliegend.

Meine klare Empfehlung den io-Broker auf Tunneling Kommunikation statt Routing versuchen zu betreiben und dann auch das Routing im wiregate deaktivieren.

Und/oder statt des eibd eine zertifizierte Schnittstelle oder KNX-IP-Router benutzen.

Hallo,
vielen Dank für die Antwort. Ich befürchte, ich habe mich etwas falsch ausgedrückt oder ich habe etwas falsch verstanden. Im KNX-Adapter habe ich die IP-Adresse des Wiregate und den Port 3671 eingestellt. Dann müsste das Wiregate m. E. als Tunnel laufen und nicht als Router... Sorry!

Die IP-Adresse definiert ja nicht ob man sich per Tunneling oder Routing verbindet. Das mit dem port bin ich ehrlich überfragt. Aber ich habe noch von keinen Beiträgen gelesen das das die Art der Kommunikation beeinflusst. Da sollte es besser eine sehr klare Auswahloption geben.

Ein gutes Beispiel finde ich ist der KNX-Ultimate-Node im Nodered. Da ist das klar ersichtlich ob man den per Routing oder per Tunneling an den KNX andocken will. Und das es eben auch auf der eibd-Seite ggf. nicht klar ist wie es da weiter geht, würde ich eben da auch das Routing mal deaktivieren.

OK, kann mir denn jemand sagen, was der rückgemeldete Status "15" bedeutet? Ich habe mittlerweile auch schon von einem komplett anderen System aus versucht, sowohl als Tunnel als auch als Router auf den KNX-Bus zuzugreifen. In beiden Fällen das Gleiche: Rückmeldung vom Wiregate Status 15 und dann wird die Kommunikation neu aufgebaut. Wenn die Schnittstelle am Wiregate eine Macke hat, kaufe ich mir auch gerne eine Neue. Ich würde nur schon gern wissen, welche Fehlermeldung sich hinter dem Status verbirgt. Vielleicht wird ja auch nur ein Telegramm im IP-Netz verschluckt weil bspw. ein Netzwerkkabel eine Macke hat. Daher würde ich mich wohler fühlen, wenn ich weiß, welcher Fehler vorliegt.

Hallo Michael,

Micon hat geschrieben: ↑Mi Apr 14, 2021 9:09 amIch habe mittlerweile auch schon von einem komplett anderen System aus versucht, sowohl als Tunnel als auch als Router auf den KNX-Bus zuzugreifen.

Die beiden Betriebsarten unterscheiden sich fundamental.

Micon hat geschrieben: ↑Mi Apr 14, 2021 9:09 amWenn die Schnittstelle am Wiregate eine Macke hat, kaufe ich mir auch gerne eine Neue.

Das kann möglich sein. Ist schwer zu sagen, weil wir haben über die Zeit drei Schnittstellen verkauft und Du hast nicht angegeben welche.

Von einer zugekauften Schnittstelle wissen wir, dass bei ungünstiger Drift der Quarzfrequenz durch Alterung es zu Unterbrechungen kommen kann.

Allerdings ist io:Broker schon mehrmals aufgefallen dadurch, dass es Tunnel öffnet, aber den Timeout nicht bedient, so dass der Server Tunnel dann zurücksetzen muss. Bitte eine der aktuelleren Versionen verwenden bitte, da könnte das behoben sein. Allerdings ist auch der eibd an mehr als einem Dutzend Stellen fehlerhaft, das war der Grund, warum wir für den Timberwolf Server einen eigenen Stack entwickelt und von einer Zertifizierungslabor auf Herz und Nieren haben testen lassen.

Eine definitive klare Aussage zu Deinem Problem können wir hier leider nicht treffen, ich wollte Dich nur nicht ohne Antwort lassen.

lg

Stefan

Hallo Stefan,

vielen Dank für Deine Hilfe! Ich habe mittlerweile herausgefunden, dass es wohl wirklich am KNX-Adapter im ioBroker liegt. Ich habe auf zwei unabhängigen Maschinen ioBroker testweise installiert und die Logs verglichen. Dabei habe ich herausgefunden, dass bei allen Heartbeats, die negativ beantwortet wurden, die Zeitdauer zwischen dem letzten Heartbeat und dem aktuellen mehr als 120 Sekunden beträgt. Wiregate bzw. EIBD setzt dann nach 120 Sekunden wohl KNX-konform den Tunnel zurück und sendet beim verspäteten Heartbeat dann richtigerweise den Status zurück, dass der angefragte Tunnel nicht mehr existent ist. Von daher ist auf Seiten Wiregate/EIBD wohl (für mich) alles in Ordnung. Ich habe den issue mal bei Github platziert, vielleicht bekomme ich da ja eine Antwort bzw. bestenfalls einen Fix. Ansonsten werde ich mich nach einem anderen System umschauen. Wenn der Tunnel alle paar Minuten getrennt wird, ist das keine vernünftige stabile Lösung für mich.

Liebe Grüße

Michael

D.h. am Ende stellt sich die Überschrift als falsch heraus. Besser passen würde z.B.
ioBroker: Connection State Response Fehler

Nun ist das Wiregate inzwischen "veraltete" Technik. Dennoch lerne ich auch bezogen auf den TWS für mich daraus, auf eigene oder individuelle Lösungen im Container weitestgehend zu verzichten. Ich hätte einen solchen Fehler nicht lokalisieren können. Was anfänglich noch mit Hobby zu rechtfertigen sein mag, ist dann am lange Ende eine Versklavung durch Technik. Wie viele Menschen wollen bzw. können sich das bis zu welchem Lebensjahr antun und was ist auf Dauer wirklich smart?

Ergo: Mein idealer Timberwolf kommt ohne eigene/individuelle Container aus. Aber wo ist die Welt schon ideal...

Hallo Michael,

Micon hat geschrieben: ↑Mi Apr 14, 2021 11:47 amDabei habe ich herausgefunden, dass bei allen Heartbeats, die negativ beantwortet wurden, die Zeitdauer zwischen dem letzten Heartbeat und dem aktuellen mehr als 120 Sekunden beträgt. Wiregate bzw. EIBD setzt dann nach 120 Sekunden wohl KNX-konform den Tunnel zurück und sendet beim verspäteten Heartbeat dann richtigerweise den Status zurück, dass der angefragte Tunnel nicht mehr existent ist. Von daher ist auf Seiten Wiregate/EIBD wohl (für mich) alles in Ordnung. Ich habe den issue mal bei Github platziert, vielleicht bekomme ich da ja eine Antwort bzw. bestenfalls einen Fix.

Ja, der Fehler bei io:Broker ist lange bekannt. Ich war mir zunächst nicht völlig sicher, ob es sich im den gleichen Fehler handelt.

Schließlich hatten unsere Entwickler den Fehler bereits im letzten Jahr auf Github gemeldet. Ich dachte, dass dieses nicht konforme Verhalten des io:Broker längst erledigt wäre.

lg

Stefan

Ja Markus,

Smart Jeanie hat geschrieben: ↑Mi Apr 14, 2021 12:16 pmWas anfänglich noch mit Hobby zu rechtfertigen sein mag, ist dann am lange Ende eine Versklavung durch Technik. Wie viele Menschen wollen bzw. können sich das bis zu welchem Lebensjahr antun und was ist auf Dauer wirklich smart?

Richtig, das war letztlich die Idee hinter dem Timberwolf Server und dem Care-Programm. Wir sorgen uns um die Details und kümmern uns um Qualität und Kompatibilität. Der Nutzer drückt nur ab und an auf den Update-Knopf (womöglich erst bei Problemen) und die Sache sollte gefixt sein. Ansonsten Problem im Forum erklären und wir sehen zu, dass wir zügig eine Lösung finden.

So war es gedacht, so haben wir es umgesetzt.


lg

Stefan