Openhab 3 keine Verbindung nach Internetausfall

[peter-pan]

..eine weitere Möglichkeit wäre das Logging von OH auf das Nötigste zu reduzieren.
Ich habe bei mir das event-Logging in der Karaf-Konsole auf "WARN" reduziert.

Code: Alles auswählen

openhab> log:list
Logger                                             │ Level
───────────────────────────────────────────────────┼──────
ROOT                                               │ WARN
javax.jmdns                                        │ ERROR
javax.mail                                         │ ERROR
openhab.event                                      │ WARN
openhab.event.AddonEvent                           │ ERROR
openhab.event.ChannelDescriptionChangedEvent       │ ERROR
openhab.event.InboxUpdatedEvent                    │ ERROR
openhab.event.ItemAddedEvent                       │ ERROR
openhab.event.ItemChannelLinkAddedEvent            │ ERROR
openhab.event.ItemChannelLinkRemovedEvent          │ ERROR
openhab.event.ItemRemovedEvent                     │ ERROR
openhab.event.ItemStateEvent                       │ ERROR
openhab.event.RuleAddedEvent                       │ ERROR
openhab.event.RuleRemovedEvent                     │ ERROR
openhab.event.RuleStatusInfoEvent                  │ ERROR
openhab.event.StartlevelEvent                      │ ERROR
openhab.event.ThingAddedEvent                      │ ERROR
openhab.event.ThingRemovedEvent                    │ ERROR
openhab.event.ThingStatusInfoEvent                 │ ERROR
openhab.event.ThingUpdatedEvent                    │ ERROR
org.apache.cxf.jaxrs.sse.SseEventSinkImpl          │ ERROR
org.apache.karaf.jaas.modules.audit                │ INFO
org.apache.karaf.kar.internal.KarServiceImpl       │ ERROR
org.apache.karaf.shell.ssh.SshUtils                │ ERROR
org.apache.karaf.shell.support                     │ OFF
org.apache.sshd                                    │ WARN
org.eclipse.lsp4j                                  │ OFF
org.jupnp                                          │ ERROR
org.openhab                                        │ INFO
org.openhab.binding.amazonechocontrol              │ ERROR
org.openhab.binding.avmfritz                       │ ERROR
org.openhab.binding.homematic                      │ ERROR
org.ops4j.pax.url.mvn.internal.AetherBasedResolver │ ERROR
org.ops4j.pax.web.pax-web-runtime                  │ OFF
su.litvak.chromecast.api.v2.Channel                │ ERROR
openhab>

...vielleicht ist das auch eine Möglichkeit.

[andi471]

Aktualisierungen sind eher für Programmierer, ich bin Energietechniker deswegen: Fingers off the running system! - 10 Jahre rauer Betrieb ohne Probleme? Respekt! So soll es sein.

Wie soll ich vorgehen, wenn der Pi im Ausland steht, off ist und ich erst im August hinkomme? Ich habe am Wochenende einen zweiten, redundanten Pi3 B+ mit OH3 aufgesetzt, habe ZRAM aktiviert damit ich etwas vorbereiten kann. Es wäre schön ein Standard OS drunter zu haben. Leider weiss ich weder welches man nehmen kann, noch wie ich es auf den Pi bekomme, noch wie ich danach openhab da drüberkriege weil ich nur das Flashen des OH3-Images auf die SD-Karte kenne. Könnte mir jemand da einen Fingerzeig geben, dann würde ich versuchen es hinzubekommen.
Ich danke euch
Andi
PS: remanente Daten sind gut wenn mans braucht - sonst kann man damit Probleme kriegen

[udo1toni]

Das openHABian Image ist ein Standard OS, und zwar handelt es sich um Raspberry Pi OS lite 32Bit, lediglich ergänzt um die openHABian Scripte (welche Du auch jederzeit manuell auf ein anderes OS Deine Wahl packen kannst, solange es den Paketmanager apt verwendet, also z.B. ein natives Debian oder Ubuntu).
Allerdings ist Raspberry Pi OS ebenfalls von Debian abgeleitet, aber um einige Pakete ergänzt, die für den Betrieb auf dem Pi wichtig sind.
Ubuntu hat einige Probleme mit openHAB - insbesondere wenn es sich um eine Desktop Variante handelt. Die Entwickler empfehlen unbedingt die Verwendung des openHABian Images mit den Standard Werten (also vor allem aktives ZRAM). Bei einer kleinen Installation (alles unter 1000 Items ist klein) sollte das System damit dauerhaft und sicher laufen. Es sei denn (und da wären wir wieder bei meinem Posting oben) jemand zieht einfach den Stecker.
KEIN Betriebssystem mag es, wenn einfach so der Saft abgedreht wird. Und bei Systemen, die nicht im direkten Zugriff sind, ist eine USV beileibe kein Luxus. Der Pi lässt sich sehr preiswert gegen Stromausfälle härten, weil man keinen teuren Wechselrichter benötigt, der noch dazu mit hohen Verlusten einhergeht. Eine kleine spezialisierte USV für den Pi kostet weniger als ein Pi4 mit 2 GByte RAM - der offizielle Preis, nicht das, was momentan noch von den Spekulanten aufgerufen wird.

[andi471]

Liebe Freunde der Automatisiserungstechnik!

leider besteht das Problem noch. Ich danke für eure Anregungen, die ich so umgesetzt habe:
1. Ich habe die Anlage um eine USV erweitert, die den RasPi und die FritzBox versorgt. Der Aufbau ist in der Reihenfolge:
- das 220V-Netz versorgt die USV Yunto Smile 800 VA/480 W,
- die USV versorgt eine WLAN-Steckdose,
- die WLAN-Steckdose versorgt den Raspi3 mit OH3 und die FritzBox.
2. ZRAM nachinstalliert
3. neue Speicherkarte eingebaut
4. die Anregung von peter-pan (Logging auf WARN reduzieren) konnte ich nicht umsetzen, weil ich nicht wusste, wie es geht.

Der RasPi läuft wieder einige Wochen, bis er nicht mehr reagiert. Er ist in diesem Zustand gar nicht zu erreichen. Putty, WebUI, Cloud - alles tot.
Wireguard läuft bei mir nicht, da muss ich noch eine Runde mit AVM drehen.

Aus der Ferne konnte ich nur noch über die WLAN-Steckdose den RasPi und die FritzBox aus- und einschalten. Ich möchte das nicht, aber anders läuft meine Heizungssteuerung nicht mehr an. Jedenfalls läuft der Raspi danach wieder aber nur einige Tage bis er wieder stehen bleibt.
Er lässt sich noch ein paar mal über die WLAN-Steckdose aus- und einschalten, bis er nicht mehr hochläuft.

Mit einer neuen Speicherkarte läuft der Raspi wieder einige Wochen, bis alles wieder von vorne anfängt.

Fällt jemandem ein wieso die Karten so schnell kaputt gehen und was kann man tun um das System gegen Verlust der Versorgungspannung zu härten?

Ich danke euch!

[peter-pan]

4. die Anregung von peter-pan (Logging auf WARN reduzieren) konnte ich nicht umsetzen, weil ich nicht wusste, wie es geht.

Das geht über die Karaf-Konsole.

Wenn du über SSH in deiner Linux-Umgebung bist, kannst du die Karaf-Konsole aufrufen:

Code: Alles auswählen

hab3@oh3ssd:~ $ ssh openhab@localhost -p 8101
Password authentication
Password:

                           _   _     _     ____
   ___   ___   ___   ___  | | | |   / \   | __ )
  / _ \ / _ \ / _ \ / _ \ | |_| |  / _ \  |  _ \
 | (_) | (_) |  __/| | | ||  _  | / ___ \ | |_) )
  \___/|  __/ \___/|_| |_||_| |_|/_/   \_\|____/
       |_|       4.1.1 - Release Build

Use '<tab>' for a list of available commands
and '[cmd] --help' for help on a specific command.
To exit, use '<ctrl-d>' or 'logout'.

openhab> log:set warn openhab.event
openhab>logout

Du gibst als erstes ssh openhab@localhost -p 8101 ein. Das "normale" Passwort ist habopen .
Alternativ geht auch openhab-cli console. Die Meldung kannst du ignorieren.

Anschliessend tippst du log:set warn openhab.event . Damit wird der Log-Level auf WARN gesetzt (von INFO auf WARN).

Danach kannst du dich wieder mit logout aus der Console abmelden.

Bevor du dich aus der Karaf-Console abmeldest kannst du noch mal prüfen, ob der Status auch richtig gesetzt wurde. Das geht mit dem Kommando log:list oder log:list | grep -i openhab.event. Das kannst du natürlich auch schon vor dem Ändern machen. Dann siehst du den Status wie er momentan ist.

Bei deinen anderen Problemen kann ich dir leider nicht helfen. Ich kann dir nur sagen, dass ich bisher noch nie einen Ausfall einer SD-Karte oder einer SSD-Platte hatte. Allerdings habe ich das System mal von einer SD-Karte auf eine Andere und ganz zum Schluss auf eine SSD-Karte kopiert. Diese läuft jetzt auf ein PI4b mit 4 GB.

[peter-pan]

Mir ist gerade noch etwas eingefallen. Könnte es sein, dass der RasPi ab und zu mal durch magnetische Felder gestört werden könnte ?

Das war bei mir auch schon ein mal der Fall. Da waren Sanitäter mit Funkgeräten bei mir im Haus. Danach war der RasPi nicht mehr direkt zu erreichen. Nur durch einen Neustart.

[andi471]

Hallo peter-pan,
ich konnte die Eingaben machen, bin aber am Passwort gescheitert. Keines meiner Passworte wurde angenommen. Lag das vielleicht daran, dass bei mir OH3 läuft? In Deinem Screenshot sehe ich OH4.1.1
Magnetische Felder habe ich keine. Es geht keine größere Stromleitung am RaspPi vorbei. Aber den Fehler habe ich endlich gefunden. Im Log stand var/lib/openhab/rrd4j/leistungShelly1PM.rdd`: null. Dazu habe ich von toni1udo einen Beitrag gefunden mit der Empfehlung das System neu aufzusetzten.
Leider ist es mir nicht gelungen. Ich habe unter https://v34.openhab.org/download/ die old stable version 3.4.4 mit openhabian-raspios32-oldstable-202403151226-crc9a2a57a4.img heruntergeladen. Nach der Installation meldet sich mein RasPi aber mit OH4.1.1.
Wo kann ich mitteilen, dass das falsche Image abgelegt ist ? (verzweifel)
Viele Grüße
Andi
PS: OH4 möchte ich nicht verwenden, weil ich da zu viel in Blockly ändern soll und bei der Migration meine ganzen Items rausgeflogen sind.

[udo1toni]

Ein bisschen Erklärungen...

Egal welches Image von openHABian Du verwendest, Es wird beim initialen Start immer folgende Reihenfolge eingehalten:

1. Das Image wird expandiert (die zweite Partition wird auf den Rest der (Micro-)SD-Karte erweitert)
2. Es folgt ein Reboot
3. openhabian-config startet und führt ein Self-Update aus
4. Nach dem Self-Update werden die Voraussetzungen für die aktuelle stable Version von openHAB eingerichtet (incl. den diversen Paketen, die openHABian drum herum)
5. Anschließend wird die stable Version von openHAB installiert, unter Berücksichtigung der gesetzten Parameter in openhabian.conf
6. Abschließend wird ein Restore ausgeführt, sollte sich in der ersten Partition eine passende Datei mit dem Backup einer alten Installation befinden

Es spielt also keine Rolle, welches Image Du verwendest, openHABian wird sich immer aktualisieren. Es gibt einen Parameter in der openhabian.conf, über Die Du bestimmen kannst, welchen Branch des openHABian Repository openhabian-config als Grundlage verwenden soll. Angeblich sollte man darüber auch dafür sorgen können, dass direkt openHAB2.5.12 bzw. openHAB3.4.5 ausgerollt wird, das habe ich aber bisher noch nie so hinbekommen

Du kannst aber nach dem initialen Setup ohne Probleme openhabian-config ausführen und dort über das Menüsystem auf die letzte openHAB3-Version wechseln.
Ich empfehle dringend, immer das aktuelle Image zu verwenden, hierbei geht es vor allem um das darunter laufende OS, welches Stand heute Raspberry Pi OS lite (bookworm) sein sollte.
Die letzte openHAB3-Version läuft ohne Probleme mit Java 17, was openhabian-config eh schon eingerichtet hat

Es ist natürlich nicht sinnvoll, das Restore automatisch auszuführen, wenn Du anschließend auf openHAB3 downgradest.

Was den Umstieg auf openHAB4 betrifft:
Du musst in Blockly gar nichts ändern, wenn Du das nicht willst (ist halt eine Sackgasse...), Du musst lediglich Java Script Scripting (Nashorn) installieren, das ist die alte JavaScript Engine.
Blockly kann auch unter openHAB4 mit der alten Engine arbeiten, nur verlierst Du damit natürlich viele neue Features.
Wenn die Items bei der Migration rausgeflogen sind, hast Du beim Upgrade was falsch gemacht das ist kein grundsätzliches Problem.

[peter-pan]

...Udo hat ja dir ja schon alles super erklärt. Aber der guten Ordnung halber noch:
Das Passort für die Karaf-Konsole ist normalerweise "habopen", wenn du das nicht aktiv geändert hast. Bitte nicht mit deinem "normalen" Login-Passwort verwechseln.

welches Stand heute Raspberry Pi OS lite (bookworm) sein sollte.

Das kann ich bestätigen, ich habe erst ein Testsystem "from scratch" mit der neuen openhabian-Version auf einem Pi4 gemacht.