Öfter keine freie Tunnel-Verbindung in ETS5

[Neelex]

Hi,

ich habe öfter das Problem, dass ich über den ProServ nicht mit der ETS auf den BUS zugreifen kann:

"Die Busverbindung KnxIPTunneling: KNX-proServ [IP-Adresse]:3671 der Linie 1.1 Linie 1 konnte nicht hergestellt werden. Die Schnittstelle wird gerade verwendet und hat keine freie Verbindung zum KNX Bus mehr."

Ich habe derzeit nur den Pro-Serv und RealKNX-Server in Betrieb, keine weiteren Geräte, die einen Tunnel benötigen. Auf Anraten von Christian habe ich bereits überprüft, ob die zusätzlichen Tunnel aktiviert sind. Dies scheint so zu sein, denn wenn in der ETS der Gruppenmonitor läuft (über 1.1.250) und ich einen Openhabian zum Testen starte, werden Lese- und Schreibvorgänge auf dem KNX-BUS von OpenHab über die 1.1.251 abgewickelt. (Die Adressen 1.1.250 - 254 werden nicht anderweitig von KNX-Teilnehmern verwendet, das habe ich geprüft.)

Derzeit programmiere ich zur Einbindung des ProServ und RealKNX-Servers öfters in Abständen von wenigen Minuten auch den ProServ über die ETS. Kann es sein, dass der ProServ nach diesem Programmiervorgang einen kurzen Reset macht, aber den bestehenden Tunnel zur ETS nicht ordentlich trennt? Dann würde nach jedem Programmiervorgang ein neuer Tunnel aufgebaut bis alle 5 Tunnel in Verwendung sind. Interessant ist nämlich, dass bei Programmierung mehrerer Geräte direkt nacheinander die Programmiervorgänge nach Programmierung ProServ immer fehlschlagen.

Was ich ebenfalls nicht verstehe ist, warum die Verbindung der ETS zum KNX-Bus wieder funktioniert, wenn der realKNX-Server einmal neugestartet wurde. Ich dachte der RealKNX-Server greift über den ProServ direkt auf den KNX-Bus zu und benötigt keinen dedizierten Tunnel?

Wie sind hier die Zusammenhänge und kann ich das Problem mit dem fehlenden Zugriff irgendwie vermeiden? Einzige Maßnahme ist im Moment den proServ und/oder den realKNX-Server neuzustarten. Und gibt es eine Möglichkeit zu sehen, welche Tunnel des ProServ in Verwendung sind?

Grüße
Jens

[multimedia]

Hallo Jens,

Kann es sein, dass der ProServ nach diesem Programmiervorgang einen kurzen Reset macht, aber den bestehenden Tunnel zur ETS nicht ordentlich trennt?

Ich habe diese Problembeschreibung an Fa. Weinzierl weitergegen, da hier Hard- und Firmware vom proServ entstand:
Die Tunnelverbindungen werden nach einem Download über die ETS oder einem Spannungsreset alle zurückgesetzt und sind somit wieder neu verfügbar.

Was ich ebenfalls nicht verstehe ist, warum die Verbindung der ETS zum KNX-Bus wieder funktioniert, wenn der realKNX-Server einmal neugestartet wurde. Ich dachte der RealKNX-Server greift über den ProServ direkt auf den KNX-Bus zu und benötigt keinen dedizierten Tunnel?

Es ist genau wie Du sagst, der realKNX Server kommuniziert nicht über den Tunnel mit dem Bus (es sei denn die SONOS Einbindung wurde konfiguriert). Die Verbindung zum Objectserver erfolgt separat über die Webservices (Port 80) und über das BAOS Protokoll (Port 12004).

Eine aussagekräftige Analyse kann nur über ein Mitschnitt mittels Wireshark gemacht werden.

Viele Grüsse
Christian

[MPolo]

Also ich kann das auch bestätigen. „Die Schnittstelle wird gerade verwendet...“
irgendsoeine Meldung kommt. Dann renne ich in den Keller und starte proserv und realKNX neu und es geht wieder.
Leider habe ich noch kein Schema gefunden, wann das auftritt, deshalb hatte ich das hier auch nicht gepostet.
Nun bin ich doch nicht alleine auf der Welt mit diesem Problem.
Christian, bitte poste das Ergebnis von Weinzierl hier.
Liebe Grüße aus Berlin

[Neelex]

Hallo Christian,

vielen Dank erstmal.

Es ist genau wie Du sagst, der realKNX Server kommuniziert nicht über den Tunnel mit dem Bus (es sei denn die SONOS Einbindung wurde konfiguriert). Die Verbindung zum Objectserver erfolgt separat über die Webservices (Port 80) und über das BAOS Protokoll (Port 12004).

Dann macht mich das wirklich stutzig. Es ist definitiv so, dass sich ein Reboot des RealKNX-Servers manchmal auf die Tunnel auswirkt. Die ETS hat heute über die PA 1.1.251 kommunziert. Nachdem ich den realKNX-Server neu gestartet habe, kommunizierte die ETS über die PA 1.1.250. Programmiere ich nun den ProServ partiell, nutzt die ETS beim nächsten Programmiervorgang eines anderen Geräts wieder die 1.1.251. Ein weiterer Neustart des realKNX hatte aber nun nicht den Effekt, dass die Kommunikation wieder über die 1.1.250 läuft. So ein richtiges Schema finde ich auch nicht.

Eine aussagekräftige Analyse kann nur über ein Mitschnitt mittels Wireshark gemacht werden.

Was brauchst Du hier genau?

Viele Grüße
Jens

[PhilW]

Guten Morgen,

hab lustiger Weise grad genau das selbe Verhalten festgestellt. Ist mir aber noch nie so aufgefallen, und war das erste mal.

Ich glaube das hängt mit dem Bus-/Gruppenmonitor zusammen. Ich nutze normalerweise als Monitor den PEAKnx Adapter mit Monitor und kaum die Diagnose/Monitor Fenster der ETS.
Grade hatte ich kurz einen Wert über die ETS ausgelesen, und das ging dann natürlich über die poServ Schnittstelle. Und zack beim nächsten Programmierversuch: "Die Schnittstelle wird gerade verwendet...".
Ausschalten des Monitors bringt nix, und ich musste auch wie die Kollegen den proServ einmal neustarten.

Hilft vielleicht bei der Fehlersuche

[4rem]

Salü miteinander
Bin mir nicht sicher ob hier auch mein Problem liegt. Die Schnittstelle Schalter->Node Red Befehl hängt sich bei mir oft auf.Der Tastendruck wird im Busmonitor aufgezeichnet, aber leider findet keine Reaktion statt. Statusänderung im Node Red wird auch nicht angezeigt. Wenn ich aber einen manuellen Inject tätige, reagiert alles wie gewünscht. Proserv x-mal neu starten, realKNX x-mal starten reanimiert es dann wieder. Könnte das auch mit diesem Tunnel Problem zusammenhängen welches Ihr erwähnt?

[multimedia]

Könnte das auch mit diesem Tunnel Problem zusammenhängen welches Ihr erwähnt?

Nein, die Kommunikation von NodeRed läuft nicht über den UDP Tunnel (also nicht über Gruppenadressen) sondern über Kommunikationsobjekte und über TCP.

Die Schnittstelle Schalter->Node Red Befehl hängt sich bei mir oft auf

Haben das bislang nicht beobachtet, und es laufen inzwischen schon Riesenprojekte über diese Knoten.
Probier mal nach dem Neustart des Servers den betroffenen Knoten neu auszuwählen und dann wieder zu speichern.

[4rem]

error-realKNX Node-RED _ 192.168.178.28.png

Hab im Debugger diesen Fehler gefunden. Könnte das die Ursache sein?

[4rem]

Edit: Dies war nicht der Fehler. Hab den KNX easy Node gelöscht und nun verschwindet diese Meldung. Problem mit der fehlenden Verbindung realKNX-KNX besteht allerdings weiterhin

multimedia Das Problem bei realKNX besteht nur bei realKNX-in Nodes (inkl. Status). realKNX-out Nodes funktionieren. Hast du eine Idee?

[Neelex]

Hallo,
ich hoffe ihr alle hattet ein paar besinnliche Festtage

Ein kurzes Update zu dem Problem. Um das Problem nachzustellen reicht es schon, wenn man NodeRed ein paar Mal mit "Save" neustartet.

Hypothese: Der knxjs-node, den viele für die Uhrzeit-Sync verwenden, ist das eigentliche Problem. Der knxjs-Controller baut eine Tunnelverbindung über den ProServ auf. Jedes Mal, wenn man Node Red speichert, wird die Verbindung "geklaut" und der Tunnel somit nicht sauber geschlossen. Auf dem ProServ ist der Tunnel dann noch aktiv. Nach dem Starten baut der knxjs-Node einen neuen Tunnel auf, so lange, bis alle Tunnel in Verwendung sind.
.
Was ich sicher sagen kann ist, dass immer wenn ich NodeRed neu starte, die ETS-Verbindung eine andere PA verwendet, also

1.250 ---> Neustart --> 1.251 -->Neustart --> 1.252 usw.

[multimedia]

Wow, vielen Dank!
Da ich den knxjs.node nie nutze, ist mir das nicht aufgefallen.
Nicht sicher, ob wir da kurzfristig was machen können.
Nach 2 Minuten werden unbenutzte Tunnel übrigens wieder freigegeben. Ansonsten hilft auch den proServ spannungslos machen, der ist nach 2 Sekunden wieder fit.

[Neelex]

Wow, vielen Dank!
Da ich den knxjs.node nie nutze, ist mir das nicht aufgefallen.
Nicht sicher, ob wir da kurzfristig was machen können.
Nach 2 Minuten werden unbenutzte Tunnel übrigens wieder freigegeben. Ansonsten hilft auch den proServ spannungslos machen, der ist nach 2 Sekunden wieder fit.

Hallo Christian,

Ich habe den ganzen knxjs-Node inkl Controller gelöscht und kann bestätigen, dass das Problem dann nicht mehr auftritt. Es liegt also definitiv am knxjs.

Ich denke an der Arbeitsweise des knxjs-Controllers können wir ohnehin nichts ändern. Der Controller prüft bei Neustart von NodeRed nicht mal, ob ein freier Tunnel zur Verfügung steht und "behauptet" einfach das Telegramm wäre korrekt gesendet.

Was ich nicht verstehe: Ich habe das Problem gestern Abend nachgestellt und konnte mit der ETS keine Verbindung aufbauen, da alle Tunnel in Verwendung waren. Ich hätte jetzt erwartet, dass nach 2 Minuten nach und nach alle Tunnel, die nicht korrekt terminiert wurden, wieder zur Verfügung stehen. Aber selbst heute morgen kann ich mit der ETS keine Verbindung aufbauen. Faktisch kann es aktuell ja nur ein aktiver Tunnel sein, der von dem knxjs-Controller verwendet wird ( mit der PA 1.254).

Es gibt da nun ein paar Möglichkeiten:

1. Die Tunnel 1.250 - 1.253 werden icht verwendet, solange der einzige aktive Tunnel der 1.254 ist
2. Der ProServ trennt die Tunnel nicht
3. Es liegt speziell am knxjs über NodeRed

Mit einem openHabian konnte ich das Problem nicht nachstellen. Hier werden immer die 1.250 und 1.251 verwenden, auch wenn man den openHabian mehrfach kurz spannungslos gemacht hat. Somit könnte das Problem wirklich speziell am knxjs liegen. Der Neustart des openHabian dauert allerdings gefühlt 10 Minuten, auf jeden Fall länger als die 2 Minuten, nach denen der ProServ die Tunnel zurücksetzt. Möglicherweise mag der ProServ keine Tunnelanfragen während das Timeout für inaktive Tunnel läuft? Aber das sind alles Mutmaßungen.

Mit dem Wissen um das Problem kann man ja nach dem Arbeiten mit NodeRed einfach den ProServ und den realKNX einmal neustarten, man muss nur dran denken. Eine zuverlässige Uhrzeit-Synchronisation ist das leider trotzdem nicht. Hatte das nun schon öfters, das der knxjs nichts mehr gesendet hat und ich es erst nach Tagen gemerkt habe, weil die Abweichung auf manchen Tastern zu meinem Smartphone im Minutenbereich lag.

Kriegen wir den Uhrzeit/Datum-Output aus NodeRed auf den Bus nicht auch mit dem RealKnx-Out Node hin? Das läuft ja extrem zuverlässig.

[PhilW]

Tach,

kann ich alles genau so bestätigen und nachvollziehen.
Der knxEasy Knoten verhält sich genau so dämlich und "blockiert", wenn er dann auf der 254 ist alle anderen Tunnel. Mein OpenHAB kam auch nicht mehr zum Zuge.
Ich hatte zwischendurch sogar auch mehrmals Probleme die IKnix App zu aktualisieren. Nachdem der Knoten jetzt deaktiviert ist läuft alles wieder.
Ich hab zum Glück ne GBZ im Einsatz die mir die Uhrzeit liefert.

Kriegen wir den Uhrzeit/Datum-Output aus NodeRed auf den Bus nicht auch mit dem RealKnx-Out Node hin?

Geht das nicht mit den Uhrzeit/Datums KO's des ProServ?

Gruss
Guido

[multimedia]

Geht das nicht mit den Uhrzeit/Datums KO's des ProServ?

...bis jetzt noch nicht. Da müssen wir noch einige Ergänzungen einbauen.

[PhilW]

Da hab ich dann aber ein Verständnissproblem! (Mal wieder, kommt in letzter Zeit oft vor, aber dafür hab ich mir zu Weihnachten ja den "Eibmeier" gegönnt )

Uhrzeit und Datum sind doch beides In/Out KO's, oder?