Openhab nicht mehr erreichbar

[Fabi91]

Hallo zusammen,

ich hoffe ihr könnt mir helfen. Ich versuche seit 2 Wochen mein Openhab wieder zum Laufen zu bekommen. Leider ohne Erfolg.
Wir haben einen neuen Stromzähler erhalten vom Netzbetreiber. ich habe leider vergessen meinen Rapsberry PI4 mit Openhab 3.4.4 vorher runterzufahren.
Am nächsten Tag ist mir aufgefallen, dass keine Rules mehr ausgeführt werden und ich keinen Zugriff mehr auf meine sitemap per Openhab App habe "Fehler SSL Handshake fehlgeschlagen"
Also habe ich mich sogleich an die Arbeit gemacht das System neu aufzusetzen.

1. Flash mit Etcher „openhabian-raspios32-latest-202411011229-crc522c3678.img“
2. Openhabian.conf geöffnet und „clonebranch=openHAB3“ abgeändert.
(Ich brauche zwingend OH3 weil mein Busch Jäger free@home binding für meinen alten Accesspoint 1 nur für OH3 verfügbar ist)
3. 1 Stunde gewartet --> Openhab3.4.5 wurde installiert
4. Benutzer über Weboberfläche erstellt.
5. Über Putty --> sudo openhabian-config --> Menu 10 Apply improvments --> Menu 14 Fix permissions
6. Mein Backup (Im Mai über openhabian-config erstellt) in das Backup Verzeichnis kopiert ---> sudo systemctl stop openhab ---> sudo
$OPENHAB_RUNTIME/bin/restore $OPENHAB_BACKUPS/openhab-backup-<DATUM>.zip ausgeführt

Danach hat sogleich wieder alles funktioniert und ich war zufrieden. Leider nur für ein paar Stunden dann wieder das gleiche Problem.
Seitdem habe ich jeden Tag versucht den Fehler einzugrenzen.
1. Neue SD Karte --> gleiches Problem
2. Image auf einem anderen Raspberry PI2B installiert , andere SD Karte, anderes Netzteil --> gleiches Problem
--> Auf diesem Setup läuft normal die Autoladesoftware "EVCC" ohne Probleme.
3. Image installiert ohne das Backup einzuspielen (Nur Schritt 1 bis 4) und einen Shelly angelegt zum testen. --> Gleiches Problem nach etwa
einem halben Tag aufgetreten. Vorher habe ich etwa stündlich gecheckt ob Openhab über den Browser erreichbar ist.
--> Somit kann ich einen Mismatch zwischen der Openhab 3.4.5 Installation und meinem Openhab 3.4.4 Backup auch ausschließen

Ich kann es mir nur so erklären.
Beim Stromausfall wurden Daten beschädigt deswegen damals die Probleme.
Die jetzigen Probleme mit einer frischen Installation kann ich mir nur doch einen Ablauffehler bei der Installation erklären.
Was mache ich falsch ?
Ich habe zwei Bilder angehängt. Der LogViewer und SSH sind noch erreichbar. Mir sagen nur die ganzen Fehler und Warnungen nichts.
Ich hoffe ihr könnt mir helfen.

[udo1toni]

Besser wäre es als Text gewesen (In PuTTY einfach den gesamten Text markieren, der ist in dem Moment direkt in der Zwischenablage). Die log Meldungen kannst Du auch direkt aus deer Datei auslesen (/var/log/openhab/openhab.log)

Die bessere Option zum Aufsetzen wäre vermutlich, RaspberryPi Imager zu verwenden. Das openHAB Image kann direkt im Menü des Imagers ausgewählt werden (es ist lediglich etwas versteckt... OS wählen -> Other specific-purpose OS -> Home assistants and automation -> openHAB -> Je nach Pi die 32-Bit oder 64-Bit Variante von openHABian wählen.
Das, was ich aus den Bildern der Logs zu erkennen glaube, deutet für mich auf ein Speicherleck hin. Mir fällt aber momentan nichts ein, was Du falsch machen kannst, um (ohne eine spezielle Konfiguration vorgenommen zu haben) einen solchen Effekt zu erzielen. Die Version 3.4.5 hatte jedenfalls kein gundsätzliches solches Problem...

[Fabi91]

Danke für die Tipps ,

ich habe die letzten Tage nochmal etliches ausprobiert.
Da der empfohlene RaspberryPi Imager für PI4 die 64bit Variante empfohlen hat, dachte ich zuerst das dies mein Fehler war wsl,
-> da das Image welches ich mit Etcher verwendet habe das 32bit war.

1.64bit Image mit RaspberryPi Imager auf eine nagelneue SD Karte geflasht
2.Clonebranch = Openhab3 im openhab.conf
3.Frische OH 3.4.5 Installation 3 Tage laufen lassen
---> Keinerlei Probleme, keine Warnungen im logViewer, per Browser immer erreichbar
---> Mit der Etcher 32bit installation gabs damals hier schon Probleme
4. Mein OH 3.4.4 Backup von Mai 2024 wiederhergestellt + InfluxGrafana
--> Beschriebene Problematik ist wieder da nach etwa einem halben Tag
5. Nochmal neu installiert alles, diesmal auf OH3.4.4 downgegraded mit diesen Befehlen
sudo apt remove openhab
sudo apt install openhab=3.4.4-1
6. Mein OH 3.4.4 Backup von Mai 2024 wiederhergestellt. + InfluxGrafana
--> Gestern Abend keinerlei Auffäligkeiten im Logviewer soweit ich das beurteilen kann. (Log ist angehängt)
--> Heute früh OH wieder nicht erreichbar. (Log ist angehängt und Status in Putty)
Laut Log werden die Items aber eingelesen aber es taucht regelmässig dieser Fehler auf:

==> /var/log/openhab/openhab.log <==
2024-11-29 04:41:00.311 [WARN ] [ab.core.internal.events.EventHandler] - Dispatching event to subscriber 'org.openhab.core.internal.items.ItemUpdater@3d41601a' takes more than 5000ms.
==> /var/log/openhab/events.log <==

Langsam gehen mir die Ideen aus
Zum Glück habe ich nur die Things per GUI angelernt und ansonsten alles Textbasierend erstellt.
Da die Basisinstallation ja zumindestens 3 Tage lauffähig war würde ich jetzt abwechselnd einzelne Geräte anlernen und dazwischen paar Tage warten. Vll kann ich es so besser eingrenzen.

[Fabi91]

Hallo zusammen,

ich habe mein Problem jetzt selbst gefunden mithilfe von diesem Beitrag:
https://community.openhab.org/t/oh4-run ... 148699/118

Der Stromausfall durch den Zählertausch war gar nicht das Problem.
Ich habe zwei Tage davor einen Shelly pro 3em (PV Anlage) ins Heimnetz gebracht
Erstmal nur damit ich die Daten in der Shelly Cloud habe. Er wurde nicht als Thing hinzugefügt im Openhab,
deswegen habe ich hier keinerlei Zusammenhang gesehen.

Scheinbar gibt es hier ein Problem mit der Discovery Funktion vom Shelly Binding.
Dieses sieht den Shelly pro 3em im Heimnetz und fühlt den RAM des PI4 bis dieser voll ist.
--> Crasht nach etwa einem halben Tag.

Seitdem am Shelly pro 3em das LAN ausgesteckt habe ist Ruhe.
Mein Plan ist jetzt das Shelly Binding zu deinstallieren und alle Geräte per MQTT anzulernen.
Ich hoffe das klappt.

[udo1toni]

Oh, das ist eine wichtige Erkenntnis. Kannst Du die in Richtung Entwickler (Shelly Binding) weiterleiten? Ganz unabhängig von Autodiscovery darf ein Binding keine Speicherlecks haben...