Openhab2 auf dedizierte Tunnel-Adresse

[PascalTurbo]

Hi Leute,

die Überschrift ist wohl etwas "schwierig". Ich hole mal weiter aus: Aktuell betreibe ich zwei OH-Instanzen parallel. Ein OH1 für den Produktivbetrieb und OH2, auf das demnächst migriert werden soll.
Offenbar kommen sich die beiden aber in die quere - mein Weinzierl 730 IP Interface gibt immer mal wieder "could not accept new connection (maximum reached)" zurück.
Nun kann das Interface bis zu 5 Tunnel-Connections gleichzeitig bereitstellen, jeweils über eine eigene Hardware-Adresse. Kann man OH2 irgendwie beibringen, nur eine dieser HW-Adressen zu verwenden?

VG
Pascal

[udo1toni]

Andersrum wird ein Schuh draus:

openHAB braucht eine eigene, nirgends im System verwendete physikalische Adresse.
openHAB soll keine (!) der reservierten Tunnel-Adressen verwenden. Das gilt sowohl für openHAB1 als auch für openHAB2

[reu]

Hallo,

wenn du Tunneling verwendest, kannst du eigentlich gar nicht entscheiden welche physikalische Adresse der Client (in dem Fall OH) benutzt. Du musst in der Konfigurationsdatei als type "TUNNEL" und die IP-Adresse deiner IP-Schnittstelle angeben (hast du aber offensichtlich getan).
OH fragt bei deiner Schnittstelle einfach eine Verbindung an, und wenn die Schnittstelle noch eine übrig hat, wird die Verbindung hergestellt, sonst wird die Verbindung mit einem Fehlercode abgewiesen (das passiert in deinem Fall). Wenn die Verbindung erstmal steht, werden die Telegramme von OH dann normalerweise mit der entsprechenden Quelladresse der IP-Schnittstelle auf KNX (TP) gesendet (auch wenn die Telegramme mit einer von dir vergebenen phy. Adresse gesendet werden, ist das für die Verbindung erstmal unwichtig, nur dafür dass die Telegramme auch in der richtigen Linie ankommen).

Normalerweise wird eine Tunneling-Verbindung nur für eine bestimmte Zeit zur Verfügung gestellt, dann beendet die IP-Schnittstelle die Verbindung (ABB IP/S beendet die Verbindung manchmal auch schon vorzeitig nachdem ein oder mehrere Telegramme übertragen wurden). Der Client muss dann die Verbindung erneut aufbauen. Manchmal kommt es vor (auch mit der ETS), dass der Client eine Verbindung einfach "vergisst" (z.B. nach einem Absturz), der Server (IP Interface) glaubt aber diese würde noch bestehen. Bei 5 Verbindungen ist es aber schon seltsam (außerdem sollte der Server diese Verbindung nach ner Zeit ohnehin wieder freigeben).
Hier müsste man wirklich genauer wissen wo das Problem liegt. Gerade habe ich in der Beschreibung von der IP-Schnittstelle gelesen, dass man die physikalischen Adressen erst manuell konfigurieren muss damit auch 5 Verbindungen zur Verfügung stehen (wenn ich das richtig verstehe), in der Werkseinstellung steht nur eine Verbindung zu Verfügung. Hast du geprüft ob das passt?

Das KNX-Binding version 1.x hat z.B. ein Konfigurationsparameter "numberOfThread" welcher per default auf 5 festgelegt ist, ich weiss aber wiederum nicht ob hier jeder Thread eine eigene Verbindung aufbaut (ich würde vermuten nicht, das wäre zumindest bei serieller Verbindung gar nicht möglich). Du könntest eventuell auch die "autoReconnectPeriod" setzen/erhöhen (10-30s). "localSourceAddr" bzw. "busaddr" würde ich an deiner Stelle entweder ganz frei lassen oder auf "0.0.0" setzen.
Du könntest aber auch grundsätzlich auf Routing umstellen, wenn du ein recht einfaches Netzwerk hast (OH und IP-Router im gleichen Subnetz) könnte das besser funktionieren. Habe aber gerade gelesen, dass du nur ein IP Interface hast, du bräuchtest natürlich einen KNX/IP-Router.

Hast du auf deinen OH-Instanzen auch unterschiedliche Binding-Versionen? Wie sehen die Konfigurationsdateien aus? Laufen die OH-Instanzen auf unterschiedlichen Rechnern?

[PascalTurbo]

Hi,

hab mal versucht herauszufinden, woran es hängen könnte. Das hinzufügen weiterer Tunnel-Adressen habe ich mehrfach durchgeführt. Dummerweise kann man nirgends sehen, ob diese Adressen tatsächlich angelegt wurden. Hab mal versucht, über ETS die Verbindung zu bspw. 15.15.252 aufzubauen - und hier meckert er an, dass diese bereits als weitere Tunneling-Connection aktiviert wurde. Sieht also richtig aus.
Im Gruppenmonitor sehe ich, dass alle Openhab-Anfragen von OH1 von 15.15.251 kommen - auch das klingt richtig.

Allerdings bekomme ich immer nur zwei Verbindungen gleichzeitig hin. Wenn OH1 + ETS laufen, verbindet sich OH2 nicht, Wenn OH1 + OH2 laufen, verbindet sich ETS nicht. Es ist zum Mäuse melken.

Eure Empfehlungen bzgl. busaddr gehen ja ziemlich weit auseinander. Da sie bislang auf beiden OH-Installation auf 0.0.0 standen, setze ich die jetzt mal für OH2 auf eine unbelegte Adresse.

Zu dem Betrieb:
- OH1 läuft auf nem Raspberry Pi mit dem 1.8er Binding (Das ist meine Produktivumgebung, da will ich möglichst wenig ran)
- OH2 läuft in nem Docker auf meiner Synology mit dem 2.0er Binding (Dort erprobe ich das zukünftige Upgrade)

VG
Pascal

[udo1toni]

Ich setze hier selbst ein Weinzierl 730 ein, welches 5 Tunnel-Verbindungen bietet. Es laufen hier zwei openHAB-Instanzen gleichzeitig (OH1.8 produktiv und OH2.4 Testumgebung, läuft in der Zwischenzeit dauerhaft, auch mit knx2), ETS lasse ich zeitweise laufen, wenn ich es gerade mal brauche, ich habe hierbei keine Probleme.
Die gemeldeten physikalischen Adressen für openHAB1 und 2 entsprechen hierbei den von mir vergebenen Adressen, das sind andere als die der Tunnel.

Ich habe bei mir allerdings auch schon die Situation gehabt, dass sich mehrere Tunnel "aufgehängt" hatten. Geholfen hat dann, das Interface einige Sekunden komplett stromlos zu machen (im Zweifel auch vom knx Bus zu trennen).

Wenn ich komplexe Programmierungen vornehmen will (z.B. meine Gira TS2plus programmieren), muss ich allerdings alle openHAB-Instanzen stoppen, da möchte ETS gerne exklusiven Zugriff auf den Bus haben.

[PascalTurbo]

Ich habe mir mal die Logs direkt nach dem Neustart von Openhab angeschaut und da sieht man schön 5x die Meldung, dass eine Verbindung hergestellt wurde. Daraufhin habe ich mal die Anzahl der parallelen Threads auf 2 begrenzt. Augenscheinlich zeigt dies Wirkung und ich kann OH1, OH2 und ETS parallel betreiben.

[reu]

Eure Empfehlungen bzgl. busaddr gehen ja ziemlich weit auseinander. Da sie bislang auf beiden OH-Installation auf 0.0.0 standen, setze ich die jetzt mal für OH2 auf eine unbelegte Adresse.

In der Tunneling-Spezifikation (v2.1) steht Folgendes:
"If the KNXnet/IP Tunnelling Client sends a cEMI frame L_Data.req with a KNX Individual Address (KNX Source Address) set to 0000h then the Tunnelling server shall enter the KNX Individual Address assigned to this Tunnelling connection. Otherwise the KNX frame shall be sent unchanged<...>."

Wenn der Client also mit einer Bestimmten phy. Adresse sendet, sollte diese beibehalten werden (sowie bei udo), wenn die Adresse 0.0.0 ist, sollte die Schnittstelle eine ihrer Adressen einfügen. Mit der Adresse 0.0.0 solltest du also meiner Meinung nach keine Probleme bekommen (ich nehme an du hast eine relativ kleine Anlage mit nur einer Linie, sonst würdest du die physikalische Adresse nicht auf 15.15.xxx einstellen), aber einen Versuch ist es wert.

Irgendwie sieht es eher so aus als hätte deine Schnittstelle momentan einfach nicht mehr als zwei Tunneling-Verbindungen zur Verfügung, wieso auch immer. Du könntest das testen wenn du Net'n'Node von Weinzierl runterlädst. Du kannst mehrere Instanzen von Net'n'Node starten (Programm mehrmals aufmachen, im Gegensatz zu ETS) und testen wieviele Verbindungen gleichzeitig hergestellt werden können. Außerdem siehst du dann genau welche physikalische Adresse die jeweilige Verbindung bekommt.
Tatsächlich konnte ich gerade sogar die zusätzlichen phy. Adressen von einem Gira KNX/IP-Router auslesen, ich weiß aber nicht ob das mit der 730 ebenfalls funktioniert. Dazu gehst du auf Tools>Edit Properties..., stellst dann die physikalische Adresse deiner Schnittstelle ein (15.15.250?, die siehst du aber in den Eigenschaften von der Schnittstelle) und gehst dann unten auf "Scan". Dann sollte die Software die Verfügbaren Parameter auslesen. Wenn es eine Gruppe mit der Bezeichnung "KNXnet/IP Parameter Object" gibt, klappst du diese auf, dort sollte es einen Parameter "Additional Individual Addresses" geben, den klickst du an und gehst auf "Read". Dann sollten die für die Tunneling-Verbindungen verfügbaren Adressen ausgelesen werden, wenn du dann die Parametergruppe ""Additional Individual Addresses" ausklappst sollten dort mehrere Elemente sein (am besten 5), deren jeweiliger Wert der physikalischen Adresse entspricht (Hexadezimal, bei dir sollte also sowas wie FF FB für 15.15.251 und FF FC für 15.15.252 usw. da stehen).
Hier sollten übrigens auch keine Duplikate stehen (was wohl durchaus sein kann laut Spezifikation). Wenn eine oder mehrere Adressen mehrfach vorkommen, kann es sein dass die Verbindung mit dem Fehler "NO_MORE_UNIQUE_CONNECTIONS" statt "NO_MORE_CONNECTIONS" abgewiesen wird. Evtl. unterscheidet OH zwischen den beiden da nicht so genau (oder möchte nicht den Nutzer mit unnötigen Details überfordern).

[udo1toni]

Was mich irritiert, ist der Punkt mit den Threads. openHAB sollte eigentlich niecht mehrere Verbindungen öffnen. Die Threads sind dazu gedacht, mehrere Aufgaben parallelisiert abzuarbeiten. Wenn das aber dazu führt, dass mehrere Tunnel parallel geöffnet werden, ist das ein fetter Fehler, der eigentlich auch als critical eingestuft werden müsste. Ic hkann dieses Verhalten hier nicht beobachten, es wäre interessant, herauszufinden, unter welchen Bedingungen dieses Problem auftritt.

[PascalTurbo]

Was mich irritiert, ist der Punkt mit den Threads. openHAB sollte eigentlich niecht mehrere Verbindungen öffnen. Die Threads sind dazu gedacht, mehrere Aufgaben parallelisiert abzuarbeiten. Wenn das aber dazu führt, dass mehrere Tunnel parallel geöffnet werden, ist das ein fetter Fehler, der eigentlich auch als critical eingestuft werden müsste. Ic hkann dieses Verhalten hier nicht beobachten, es wäre interessant, herauszufinden, unter welchen Bedingungen dieses Problem auftritt.

Ist die Frage, ob es sich lohnt, dem Problem nachzugehen, da der 1.x Strang sowieso nicht weiterentwickelt wird.

[udo1toni]

Ich dachte eigentlich, dass die Änderung auf 2 Threads in openHAB2 erfolgt ist? Aber in der Tat, wenn Du die Änderung ausschließlich auf der OH1.8-Seite vorgenommen hast, ist es eher nicht so dringend

[PascalTurbo]

Ich dachte eigentlich, dass die Änderung auf 2 Threads in openHAB2 erfolgt ist? Aber in der Tat, wenn Du die Änderung ausschließlich auf der OH1.8-Seite vorgenommen hast, ist es eher nicht so dringend

Nein, war auf OH1.8-Seite. Sofern ich das gleiche Verhalten nicht irgendwann auf OH2 beobachten kann, halte ich mal die Füße still