OH 2.3/ KNX2 - IP Gateway geht immer offline

[andrep]

Hallo,

ich kämpfe mit den gleichen Problemen, bei mir läuft 2.5.0.M1 auf einem Windows Server. Ich denke dass es an Raspberry Pi, RAM Auslastung oder CPU Load liegt kann man ausschließen, der Server ist nicht besonders ausgelastet:
serverlast.PNG

Ich nutze momentan den Tunnel Mode, da geht die Bridge nach einer Weile offline.

Mit dem alten KNX Binding habe ich den Router Mode genutzt, da hatte ich nie Probleme mit KNX. Wenn ich den Router Mode mit dem neuen Binding verwende, geht die Bridge zwar nie offline, aber irgendwann erhält er einfach nichts mehr vom Bus (meine Lüftungsanlage sendet eigentlich alle paar Sekunden die aktuelle Luftmenge/h).

Habe schon diverse Parametersettings probiert, Router, Tunnel, localIp und ipAddress und Timeout-Varianten.

Achja mein Gateway zum Bus ist ein Raspberry Pi auf dem KNXD läuft und an dem ein TPUART hängt - wie gesagt mit dem alten Binding lief er ohne Probleme.

Interessant ist noch das in der ETS5 die auch an den Pi als Gateway geht der Status von der Lüftungsanlage im Gruppenmonitor ankommt, selbst wenn das Binding nicht mehr funktioniert. Damit kann man das Gateway als Ursache glaube ich definitiv ausschließen.

Auch wenn ich die ETS5 auf dem Windows Server starte geht es - es liegt also auch nicht am Netzwerk zwischen Server und Raspberry Pi.

Und gerade zufällig beobachtet: Wenn ich in der Shell in der Openhab läuft während des log:tail einfach nur einen Bereich markiere (Openhab pausiert vermutlich in der Zeit unter Windows) und es danach weitergeht (meine responseTimeout ist mittlerweile verstrichen) bricht die Tunnel Verbindung ab und kommt nicht wieder! Vielleicht kann das jemand reproduzieren. Ich glaube es klappt einfach im Binding prinzipiell nicht eine Verbindung wieder neu aufzubauen (warum es beim Router Mode auch nicht geht erklärt die Idee aber nicht wirklich).

[4media]

Hallo @andrep,

die beobachtete Häufung von Abbrüchen im Tunnel Mode, ist schon recht gut dokumentiert. Allerdings wundert mich, dass im Router Mode auch solche Fehler auftauchen, das wäre neu.

Ich würde immer den Router Mode bevorzugen, da er durch seine fehlende feste Verbindung fehlertoleranter ist.

Seitdem die Probleme auftauchen, habe ich einige Syteme auf TUNNEL umgestellt und kann die Abbrüche leider immer noch nicht reproduzieren.

Aufgrund der Aussagen der zahlreichen Betroffenen, bin ich mir aber sicher, dass die Logik für das wieder verbinden überarbeitet werden muss. Ob der Fehler in der Calimero Library liegt oder direkt im openHAB Binding kann ich noch nicht sagen.

Ich denke sehr oft an das Thema, habe aber aktuell leider extrem wenig Zeit mich aktiv damit auseinanderzusetzen.

Bewährte Konfigurationen:

Bridge knx:ip:bridge [
type="ROUTER",
localSourceAddr="0.0.50",
portNumber=3671,
readingPause=50,
responseTimeout=10,
readRetriesLimit=3,
autoReconnectPeriod=60
] {...}

Bridge knx:ip:bridge [
type="TUNNEL",
localSourceAddr="0.0.0",
ipAddress="192.168.0.62",
portNumber=3671,
readingPause=50,
responseTimeout=10,
readRetriesLimit=3,
autoReconnectPeriod=60
] {...}

[andrep]

Hallo,

meine aktuelle Konfiguration ist so (also sehr ähnlich):

ipAddress="224.0.23.12",
portNumber=3671,
localIp="192.168.178.225",
type="ROUTER" ,
readingPause=50,
responseTimeout=10,
readRetriesLimit=3,
autoReconnectPeriod=30,
localSourceAddr="15.10.1"

Damit verhält es sich so, dass von der Lüftung nach einiger Zeit keine Updates mehr in Openhab ankommen.

Als workaround habe ich jetzt eingebaut, dass ich alle 5 Sekunden die ntp Zeit auf den Bus schicke. Damit läuft es jetzt schon mehrere Tage ohne Probleme. Das schicken der Zeit scheint die Verbindung irgendwie wieder neu aufzubauen und dafür zu sorgen, dass auch die Pakete von der Lüftung in Openhab ankommen.

Nicht schön, aber jetzt kein Blocker für die neue Version mehr.

[4media]

ipAddress="224.0.23.12",
portNumber=3671,

ipAddress="224.0.23.12", ist default eingestellt, kannst Du weglassen
portNumber=3671, Ist default eingestellt, kannst Du weglassen

Hast Du zwei Netzwerkkarten im Rechner? Wenn nicht:
localIp="192.168.178.225", kann zu Fehlinterpretationen kommen, würde ich definitiv weglassen! Gift wird diese Angabe, in DHCP Umgebungen in Verbindung mit zB einer Fritzbox!

[heiko74]

Hallo,

zu diesem Thema hätte ich noch einen Erfahrungsbericht.
Als ich opbeHAB2 aufgesetzt habe (ausschließlich über Text-Dateien) hatte ich KNX nach dieser Anleitung gemacht und kam auf folgendes Ergebnis:

Bridge knx:ip:bridge
[
ipAddress="192.168.2.80",
portNumber=3671,
localIp="192.168.2.25",
type="TUNNEL",
readingPause=1000,
responseTimeout=10,
readRetriesLimit=3,
autoReconnectPeriod=10,
localSourceAddr="0.0.0"
]

Nachdem die Verbindung stand (ein paar Schalter) hatte ich die Installation erst einmal stehen gelassen. Die Verbindung zum Bus ist nach einiger Zeit (deutlich mehr als eine Stunde) verloren gegangen. Das erste Schalten aus der Sitemap danach brauchte gefühlt ewig (wohl ca. 5 Sekunden). Die Verbindung wurde von OH aus also wieder hergestellt. Alle weiteren Schaltvorgänge gingen gewohnt schnell.
In der Zwischenzeit habe ich noch ein paar Sensoren, die regelmäßig Werte senden und viele Module senden is-Alive Telegramme. So ist zwischen KNX und OH immer etwas los.
Mein Stand nun ist, daß bei mir die Kommunikation soweit stabil läuft. Vermutlich braucht das Binding etwas Verkehr, damit es stabil läuft.

Hardwarekonfiguration:
* MiniPC mit Ubuntu 18.04 LTS (alle IP-Adressen fest)
* openHAB 2.4.0 Release Build mit KNX2.x-Binding
* Weinzierl IP BAOS 774

Heiko

[udo1toni]

Meine Erfahrung ist, dass die Verbindung, wenn sie mal weg ist, auch nicht mehr wieder kommt.
Die einzige Möglichkeit der Wiederbelebung ist dann ein Restart des knx2 Addons.

Da mein Produktivsystem (zumindest was knx betrifft) immer noch OH1.8 ist, fällt mir ein Busausfall vor allem durch fehlende Temperaturwerte oder auch die OFFLINE Meldung der Things auf.
Da ich auch nur sehr selten an der Konfiguration schraube, wird das System normalerweise nicht neu gestartet.
Probleme treten normalerweise nach etwa drei bis vier Wochen auf, manchmal aber auch schon nach ein paar Tagen.
openHAB 1.8 ist davon dann nicht betroffen, sprich, dort läuft alles normal weiter, nur das knx2 Binding verliert den Kontakt.

Ich bin mit diesem Testsystem auf OH2.5.0 #1505 und warte jetzt, bis Merge und Umstellung auf das neue Build System vollzogen sind.
Vorher hat ein Update des Systems auf eine aktuelle nightly Version keinen Sinn.
Allerdings wurde meines Wissens an knx2 ohnehin schon länger nichts mehr geändert...

Hardware:
* xen VM (debian stretch 64Bit, fixe DHCP IP Adresse)
* Oracle Java 8u202 64Bit (ich hab aber noch ein anderes System mit Zulu 8u202)
* Weinzierl 730 v2 (5 Tunnel)

[andrep]

ipAddress="224.0.23.12", ist default eingestellt, kannst Du weglassen
portNumber=3671, Ist default eingestellt, kannst Du weglassen

Hast Du zwei Netzwerkkarten im Rechner? Wenn nicht:
localIp="192.168.178.225", kann zu Fehlinterpretationen kommen, würde ich definitiv weglassen! Gift wird diese Angabe, in DHCP Umgebungen in Verbindung mit zB einer Fritzbox!

Ja, mehr als eine Netzwerkkarte, ist ein HP ProLiant. Eine Fritzbox mit DHCP Server läuft auch im Netz, sollte aber unproblematisch sein da der Server feste IPs hat und nicht in der DHCP Range liegt.

[agh]

Moin,
Fortsetzung meines Posts #67, bin jetzt allerdings bei Build 1564

Nachdem ich die Protokollierung eingeschaltet habe, diese daraufhin meine Protokolldateien gefüllt hat und alles stabil lief habe ich 14 Tage später die Protokollierung abgeschaltet. Dann habe ich mir mal die Auslastung meines Raspi Pi angesehen. Die Speicherauslastung lag zwischen 750-790MB. Fand ich ziemlich hoch. Der größte Speicherfresser war Note Red. Da ich das noch nicht nutze, habe ich den Dienst abgeschaltet.

Und nun: Heute Nacht ist die KNX-Verbindung mit folgenden Fehlern abgebrochen:

2019-04-15 23:05:56.731 [WARN ] [ip.KNXnet/IP Tunneling 10.3.2.6:3671] - connection state response: server could not find active data connection with specified ID (channel 11)
2019-04-15 23:06:06.726 [WARN ] [ip.KNXnet/IP Tunneling 10.3.2.6:3671] - connection state response: server could not find active data connection with specified ID (channel 11)
2019-04-15 23:06:16.727 [WARN ] [ip.KNXnet/IP Tunneling 10.3.2.6:3671] - connection state response: server could not find active data connection with specified ID (channel 11)
2019-04-15 23:06:26.727 [WARN ] [ip.KNXnet/IP Tunneling 10.3.2.6:3671] - connection state response: server could not find active data connection with specified ID (channel 11)
2019-04-15 23:06:36.769 [WARN ] [ip.KNXnet/IP Tunneling 10.3.2.6:3671] - received disconnect response status 0x21 (no active data connection with that ID)
2019-04-15 23:06:36.779 [WARN ] [ip.KNXnet/IP Tunneling 10.3.2.6:3671] - close connection - no heartbeat response
2019-04-15 23:06:36.860 [ERROR] [ip.KNXnet/IP Tunneling 10.3.2.6:3671] - establishing connection failed, null

Meine KNX Konfig hatte ich ja schon beschrieben. ReadRetries liegt bei 10 mit Wiederholung alle 10sec. Interessant ist, dass es lediglich 4 Versuche des Verbindungsaufbaus gibt. Ich weiß auch nicht was Kanal 11 ist, verstehe aber, dass das offensichtlich kein Lebenszeichen mehr kommt. Ich muss dazu sagen, dass alle Bewegungsmelder mit Helligkeitssensoren zyklisch Werte senden. Vielleicht guckt ja der Entwickler hier mal rein und kann dann etwas mit den Meldungen anfangen. Die KNX-Verbindung steigt sporadisch aus, aus meiner Erfahrung, ein Fehler der nur schwer zu finden ist.
Ich habe bei meinem Raspi ein LoadAverage von max. 0,13 und eine RamNutzung von 680MB. Das Abschalten von Node Red hat hat mir also 100MB Speicher gebracht und das Loadaverage weiter gesenkt. Der Raspi hat also Luft. Die größten RAM Nutzer sind Openhab und mysqld (MariaDB)
Gruß Andreas