OH 2.3/ KNX2 - IP Gateway geht immer offline

[udo1toni]

Wie gesagt, was soll und was ist können durchaus zwei verschieden Paar Schuhe sein, das müsste halt geklärt werden...

[Höhlenbär]

Hallo, gibt es denn schon Erkenntnisse ? Bei mir werden die Verbindungsabbrüche häufiger warum kann ich jedoch nicht sagen von 1 mal alle 2 Wochen zu 2 mal am Tag.
Allerdings immer die gleichen Symptome und Logs.

Aus der Not heraus habe ich mal die KNX Schittstelle neu gestartet, da bekam ich im Log nur

sending connection state request, attempt 1

angezeigt und Zyklisch dann immer hochgezählt.

allerdings stehen dann die Vorher hier beschriebenen Logs nicht im Log drin.
Auch wird die Verbindung dann wieder korrekt aufgebaut.

[Talki]

Mein OpenHAB ist jetzt drei Tage ohne Probleme am Raspberry gelaufen. Letzter Abbruch 2018-12-06; heute Nacht war es wieder so weit:

events.log (nur knx:ip:knx-ip-gateway)
2018-12-06 07:35:22.774 [hingStatusInfoChangedEvent] - 'knx:ip:knx-ip-gateway' changed from ONLINE to OFFLINE (COMMUNICATION_ERROR): server request
2018-12-06 07:35:22.870 [hingStatusInfoChangedEvent] - 'knx:ip:knx-ip-gateway' changed from OFFLINE (COMMUNICATION_ERROR): server request to OFFLINE (COMMUNICATION_ERROR)
2018-12-06 07:35:25.664 [hingStatusInfoChangedEvent] - 'knx:ip:knx-ip-gateway' changed from OFFLINE (COMMUNICATION_ERROR) to ONLINE
2018-12-06 07:35:33.237 [hingStatusInfoChangedEvent] - 'knx:ip:knx-ip-gateway' changed from ONLINE to OFFLINE (COMMUNICATION_ERROR): maximum send attempts
2018-12-06 07:35:33.347 [hingStatusInfoChangedEvent] - 'knx:ip:knx-ip-gateway' changed from OFFLINE (COMMUNICATION_ERROR): maximum send attempts to OFFLINE (COMMUNICATION_ERROR)
2018-12-06 07:35:34.283 [hingStatusInfoChangedEvent] - 'knx:ip:knx-ip-gateway' changed from OFFLINE (COMMUNICATION_ERROR) to ONLINE
2018-12-06 07:35:38.819 [hingStatusInfoChangedEvent] - 'knx:ip:knx-ip-gateway' changed from ONLINE to OFFLINE (COMMUNICATION_ERROR): maximum send attempts
2018-12-06 07:35:40.229 [hingStatusInfoChangedEvent] - 'knx:ip:knx-ip-gateway' changed from OFFLINE (COMMUNICATION_ERROR): maximum send attempts to ONLINE
2018-12-06 07:36:29.454 [hingStatusInfoChangedEvent] - 'knx:ip:knx-ip-gateway' changed from ONLINE to OFFLINE (COMMUNICATION_ERROR): server request
2018-12-06 07:36:29.502 [hingStatusInfoChangedEvent] - 'knx:ip:knx-ip-gateway' changed from OFFLINE (COMMUNICATION_ERROR): server request to ONLINE

events.log: (nur knx:ip:knx-ip-gateway)
2018-12-09 02:27:53.632 [hingStatusInfoChangedEvent] - 'knx:ip:knx-ip-gateway' changed from ONLINE to OFFLINE (COMMUNICATION_ERROR): server request
2018-12-09 02:27:53.732 [hingStatusInfoChangedEvent] - 'knx:ip:knx-ip-gateway' changed from OFFLINE (COMMUNICATION_ERROR): server request to OFFLINE (COMMUNICATION_ERROR)
2018-12-09 02:27:53.765 [hingStatusInfoChangedEvent] - 'knx:ip:knx-ip-gateway' changed from OFFLINE (COMMUNICATION_ERROR) to ONLINE
2018-12-09 04:45:05.348 [hingStatusInfoChangedEvent] - 'knx:ip:knx-ip-gateway' changed from ONLINE to OFFLINE (COMMUNICATION_ERROR)

Hat dieses Problem schon jemand an die Entwickler des Bindings weitergeleitet? Wenn ja, gibt es eine Reaktion?
Liebe Grüße aus Wien
Peter

[Höhlenbär]

Guten Morgen,

heute gab es den nächsten Ausfall, habe dann mal die Schnittstelle abgetrennt und geschaut ob es nach dem Reset der Schnittstelle eine Veränderung gibt.
Das Binding hat nicht mitbekommen das das die Schnittstelle nicht mehr verfügbar war. Ich denke das es ein "internes" Problem im Binding ist. Und keines auf der Netzwerkebene.

[Tom0101]

Gibt es hier mittlerweile Neuigkeiten?

Die Logs im Thread könnten von mir sein, ich habe neu mit OpenHab angefangen 2.3.0 und habe auch diese Abbrüche in der KNX Kommunikation.

[udo1toni]

openHAB 2.4 wäre schon eine bessere Wahl, wobei auch OH2.4 keine Korrekturen mehr erhält (es sei denn, es wird ein kritischer Bug gefunden).
OH2.5M1 wäre auch eine vernünftige Option, wenn man nicht experimentieren will.
OH2.5 (unstable aka nightly) wäre ebenfalls ok, wobei man hier täglich mit Überraschungen rechnen muss, allerdings sollte die Version von heute eigentlich ok sein.

Ich habe bei mir vereinzelt auch schon Verbindungsabbrüche gesehen. Da mein openHAB in einer VM läuft, habe ich kurzerhand den Speicher von 1GByte auf 1,5GByte erweitert, seitdem läuft openHAB wesentlich stabiler. Diese Option gibt es beim Raspberry natürlich nicht

[4media]

Guten Morgen,

heute gab es den nächsten Ausfall, habe dann mal die Schnittstelle abgetrennt und geschaut ob es nach dem Reset der Schnittstelle eine Veränderung gibt.
Das Binding hat nicht mitbekommen das das die Schnittstelle nicht mehr verfügbar war. Ich denke das es ein "internes" Problem im Binding ist. Und keines auf der Netzwerkebene.

So lange keine Telegramme gesendet werden?! Also ROUTING bekommt das nicht mit. TUNNELING müsste man prüfen.

Das Problem ist nur, dass es bei Dir wohl eine relativ einzigartige Konstellation gibt. Ich kann bisher, in keiner der vielen Installationen die ich betreue Deine Beobachtung bestätigen. Die Ursache für Deine Abbrüche liegt aber trotzdem tiefer in einem anderen Bereich, auch wenn die Neuverbindung tatsächlich noch nicht perfekt ist.

[4media]

openHAB 2.4 wäre schon eine bessere Wahl, wobei auch OH2.4 keine Korrekturen mehr erhält (es sei denn, es wird ein kritischer Bug gefunden).
OH2.5M1 wäre auch eine vernünftige Option, wenn man nicht experimentieren will.
OH2.5 (unstable aka nightly) wäre ebenfalls ok, wobei man hier täglich mit Überraschungen rechnen muss, allerdings sollte die Version von heute eigentlich ok sein.

Ich habe bei mir vereinzelt auch schon Verbindungsabbrüche gesehen. Da mein openHAB in einer VM läuft, habe ich kurzerhand den Speicher von 1GByte auf 1,5GByte erweitert, seitdem läuft openHAB wesentlich stabiler. Diese Option gibt es beim Raspberry natürlich nicht

Sei mir nicht böse, 1 GB? 1GB braucht openHAB schon im fast Ruhezustand! Und stabiler? Ich würde das Teil zum teufel jagen wenn es nicht stabil laufen würde! ;-)

[udo1toni]

Sei mir nicht böse, 1 GB? 1GB braucht openHAB schon im fast Ruhezustand! Und stabiler? Ich würde das Teil zum teufel jagen wenn es nicht stabil laufen würde! ;-)

Das ist eine Testmaschine. Der Speicher ist bewusst knapp gehalten, eben um zu sehen, ob es dadurch negative Effekte gibt. Mein aktives System ist OH1.8 und läuft hervorragend mit 1GByte, über Monate. Bei OH2.5 ist 1GByte durchaus ok, wenn nur wenige Addons installiert und nur wenige Channel pro Addon eingerichtet sind.

[4media]

Das ist eine Testmaschine. Der Speicher ist bewusst knapp gehalten, eben um zu sehen, ob es dadurch negative Effekte gibt. Mein aktives System ist OH1.8 und läuft hervorragend mit 1GByte, über Monate. Bei OH2.5 ist 1GByte durchaus ok, wenn nur wenige Addons installiert und nur wenige Channel pro Addon eingerichtet sind.

Ja schon, aber in dem Moment, in dem man zufällig mehrere Dinge gleichzeitig machen möchte, oder wenn ein Binding gleichzeitig mit einem anderen etwas zu viel RAM erfordert, muss die java Garbage collection heftigst zu arbeiten beginnen. Gerade in VMs kann man ja dynamisch RAM zuweisen lassen, da muss man nicht knausern auf produktiven Systemen.

[4media]

Guten Morgen,

heute gab es den nächsten Ausfall, habe dann mal die Schnittstelle abgetrennt und geschaut ob es nach dem Reset der Schnittstelle eine Veränderung gibt.
Das Binding hat nicht mitbekommen das das die Schnittstelle nicht mehr verfügbar war. Ich denke das es ein "internes" Problem im Binding ist. Und keines auf der Netzwerkebene.

Hallo Höhlenbär, kannst Du evtl. mal versuchen herauszufinden, ob sich der RAM Verbrauch von openHAB kontinuierlich nach oben bewegt? Ist nur eine sehr Waage Idee?!
Am besten wäre es ab und an die Werte zu sammeln/aufzuzeichnen? Also nicht massenhaft, nur einmal pro Tag oder so. Dann kann man mal vor und nach einem Verbindungsabbruch vergleichen. Wenn dann ein signifikanter Unterschied da wäre, hätte ich evtl. eine Idee.

#
# JAVA RAM VERBRAUCH AUSGEBEN:
# java -XX:+PrintFlagsFinal -version | grep HeapSize
#
# openHAB Speichereintellungen:
# /etc/default/openhab2:
# EXTRA_JAVA_OPTS="-Xms400m -Xmx512m"

[4media]

Zitat von udo1toni Beitrag anzeigen
Das sollte definitiv nicht so sein, openHAB sollte den Reconnect so lange erneut versuchen, bis die Verbindung wieder steht. Kann ja sein, dass der knx-Bus mal für ein paar Minuten gestört ist. Auch der Name des Parameters autoReconnectPeriod legt nahe, dass hier ein periodischer Verbindungsversuch gemeint ist.

Wenn dem so ist, sollte dann nicht im Log die gleiche Sequenz zyklisch zu sehen sein ?

Sehe ich auch so!

Ich kann derzeit allerdings leider keine Zeitaufwendigen Tests machen... bin so was von voll. :-(

[Höhlenbär]

Hallo

ja den Ramverbrauch schreibe ich mal mit. Mittlerweile läuft ein 2 Rasperry parallel interessanter weise hängen sich auch beide parallel auf ich denke das irgend ein Prozess den Raspi überfordert. Bin grade auf der Suche nach einem günstigen Nuc oder etwas ähnlichem.
Kann ich den Speicherverbrauch ev auch in OH einbinden und in eine SQL Datenbank schreiben ?

HeapSize
    uintx ErgoHeapSizeLimit                         = 0                                   {product}
    uintx HeapSizePerGCThread                       = 67108864                            {product}
    uintx InitialHeapSize                          := 16777216                            {product}
    uintx LargePageHeapSizeThreshold                = 134217728                           {product}
    uintx MaxHeapSize                              := 257949696

[4media]

Cool, ein Stückchen weiter. Wenn 2 Rasperry parallel hängen, kann dies zweierlei bedeuten:
1. Beide hängen sich auf weil sie beide etwas empfangen was beide gleichzeitig nicht verarbeiten können. (Beobachte doch mal was da so vom Bus gelogged wird vor dem Verbindungsabbruch)
2. Es gibt einen Netzwerkfehler und logischerweise sind beide betroffen und die Verbindung bricht ab.

Was jetzt das KNX2 Binding betrifft. Der Abbruch sollte dem Binding natürlich egal sein und unverzüglich der Wiederaufbau versucht werden. Dass sehe ich momentan noch als nicht in allen Fällen gewährleistet. Ursache kann calimero oder das KNX2 Binding sein - ist noch nicht raus. Wenn das KNX2 Binding nichts mitbekommt, müssen wir in calimero auf die suche gehen.

Zum debuggen von calimero an der openHAB console eingeben:
log:set TRACE calimero

Wir finden den Hund schon noch... grrrr

Der Raspi ist gut, also der aktuelle. Nutze ich oft habe meist einen mit openHAB am laufen. Gebe aber zu ich nutze im eigenen Haus einen Proxmox Hypervisor auf dem viele virtuelle Maschinen laufen. Als Betriebssystem Aufsatz für openHAB nutze ich nur noch openHABian.

[Höhlenbär]

Wie hast Du openhabian in die VM bekommen ?