openhabforum.de

immer gerne!

Ich habe noch einen kleinen Nachtrag.

Das einzige, was jetzt noch zu korrigieren ist. Durch das Ändern der IP komme ich mit dem Host-Namen openhabiandevie:8080 nicht mehr auf den Raspberry. Es geht nur mit der IP-Adresse. Aber so schlimm finde ich das jetzt nicht.

Da Problem konnte ich so lösen:
Im Profil werden die letzten Sitzungen angezeigt. Dort habe ich alle Sitzungen bis auf die letzte gelöscht.
Jetzt funktioniert auch wieder der Host-Name.

LG
Gaby

Hallo,
leider kann ich Gabys Erfahrungen bestätigen.
Mein OH3 läuft auf einem RasPi3 B+ im Ausland. Dort habe ich einige WLAN-Geräte über eine LTE-FritzBox mitVodafone-SIM angebunden von denen der RasPi einige Shelly 1PM als Heizungssteuerung steuert.
Nach einem Kommunikationsverlust konnte ich bisher vor Ort den RasPi wieder hinfummeln und die Heizungssteuerung lief wieder ohne dass ich eine Ursache feststellen konnte.
Beim letzten Ausfall am 16.05.2023 war ich live aus Deutschland dabei und konnte folgendes beobachten.
Zuerst zeigte meine OH3-Heizungssteuerung über die MyOpenHab-Cloud keine sinnvollen Werte mehr, das Lebensbit toggelte nicht mehr, die Steuerung war eingefroren.
Keines meiner WLAN-Geräte war mit der jeweiligen App über die FritzBox mehr erreichbar. Nach etwa 5-10 Minuten waren alle Geräte über ihre jeweilige App erreichbar - außer dem RasPi mit der OH3-Heizungssteuerung. Der ist bis heute off und die darauf realisierte Heizungssteuerung läuft seit dem nicht mehr.
Ich steuere alle Shelly 1PM über die Shelly-App, was bei laufender OH3-Steuerung garnicht möglich wäre weil alle Eingaben der Shelly-App sofort von der OH3-Steuerung überschrieben würden. MyOpehHabOrg meldet meinen OH3 als "offline".
Der Neustart des RasPi mit OH3-Heizungssteuerung, der sein Netzteil über eine WLAN-Steckdose bekommt, hat nicht geholfen.
Mehr konnte ich nicht machen, weil ich in Deutschland bin und keinen Zugriff auf den RasPi mehr habe.
Jedenfalls glaube ich nicht, dass es an Vodafone liegt weil sich alle wieder eingewählt haben bis auf das OH3-System. Wem fällt dazu etwas ein?

"Ich habe eine schwarze Kiste und weiß nicht, was drin ist. Wer von Euch weiß es?"

Sorry, aber ein: "Ich habe keinerlei Informationen, außer dass es nicht mehr funktioniert" ist definitiv nicht genug, um irgendetwas sinnvolles dazu zu sagen.

Man weiß ja nicht mal, an welches Stelle die Kommunikation verloren gegangen ist.

Typische Fehler wären:

• zeitweiser Verlust der Verbindung, weil der Internetzugang abgebrochen ist -> Gerät muss nach Wiederverbinden auch wieder erreichbar sein.
• Stromausfall -> Nach Wiederkehr der Stromversorgung sollte das Gerät wieder online gehen und erreichbar sein
• Defektes Dateisystem -> Gerät kann nicht mehr booten
• Hardware Defekt

Deshalb sollte ein Remote System unter allen Umständen so ausgelegt sein, dass der dritte Fall niemals eintreten kann. Fall vier kann nicht verhindert werden, denn Computer können auch "einfach so" kaputt gehen, allerdings kann man zumindest das Risiko minimieren.

Punkt 1: Unbedingt eine USV für den Raspi verbauen, z.B. ein HAT Modul, bestenfalls mit Akku, es gibt aber auch Modelle mit zwei oder drei Mignon Batterien, da muss man halt regelmäßig die Zellen tauschen.
Die USV sorgt nur dafür, dass der Pi bei Stromausfall noch genug Zeit hat, um geordnet herunterzufahren, es geht nicht um den dauerhaften Betrieb! Entsprechend ist so ein HAT Modul auch nicht sonderlich teuer. Dazu gehört gewöhnlich eine RTC und ein paar kleine Programme, die als Watchdog den Stromausfall detektieren und damit den Shutdown auslösen. Es gibt auch Modelle, die den Pi automatisch wieder starten, wenn der Strom wieder da ist.
Punkt 2: Trennung von Betriebssystem und Nutzdaten auf zwei Datenträger.
Man baut eine (Micro-)SD-Karte für den Bootvorgang und das Betriebssystem ein, diese wird über raspconfig gegen beschreiben geschützt.
Die Nutzdaten landen auf einem weiteren Datenträger (USB-Stick oder evtl. eine kleine USB-SSD)
Der Punkt dabei: ein Datenträger, der niemals beschrieben wird, wird selbst nach einem harten Crash kein defektes Dateisystem haben.
Punkt 3: Nach Möglichkeit zwei unabhängige Wege schaffen, um sich mit dem Pi zu verbinden (LAN + WLAN, zwei unterschiedliche IP-Adressen!)
Punkt 4: Nach Möglichkeit IP-Adressen fix vergeben, so kann vermieden werden, dass der Pi eine andere IP-Adresse zugewiesen bekommt
Punkt 5: Nach Möglichkeit mehrere Wege, um sich remote mit dem LAN/WLAN zu verbinden (z.B. Wireguard zusätzlich zu einem anderen VPN).

Der letzte Punkt ist natürlich nur begrenzt umsetzbar, es bleibt normalerweise der Router als Single Point of Failure, es sei denn, man hätte zusätzlich zu einer Kabelverbindung noch einen 4G-Router, der unabhängig vom Hauptrouter läuft und automatisch bei Ausfall eine Verbindung zum Internet aufbauen kann. Aber z.B. ein zweiter Pi kann als Wireguard Server dienen - für den gelten natürlich die gleichen Bedingungen, und er sollte zwingend eine eigene USV haben...

Hallo Udo,

eine Heizungssteuerung mit zwei Krücken zu unterstützen, sie an eine Herz-Lungen-Maschine anzuschließen und einen Magnet-Resonanz-Apparat mit Herzschrittmacher aufzubauen scheint mir übertrieben zu sein. Ich probier es jetzt mal mit Home Assistant oder anderen Systemen.

Denn wenn alle anderen WLAN- Teilnehmer sich nach einem Kommunikationsverlust wieder im lokalen WLAN anmelden und aus dem Internet erreichbar sind, wieso sollte man dies von einem Pi3 mit OH3 nicht auch erwarten können?
Ich finde OH3 wirklich nicht schlecht. Und ich habs ja immer ans Laufen gebracht. Aber den von Dir beschriebenen Aufwand bin ich für eine Heizungssteuerung nicht bereit zu investieren und steige lieber auf etwas anderes um.

Viele Grüsse
Andi

Du kannst machen was Du willst, ich kann Dir aber eines zu 100 % versichern: Das ist kein Problem von openHAB

Du kannst jedes System zum Absturz bringen und ohne entsprechende Vorkehrungen (siehe oben) wird früher oder später auch jedes System in einen Zustand kommen, aus dem es nicht mehr ohne fremde Hilfe aufwacht.
Die Mittel dazu habe ich oben erläutert - und das hat beileibe nichts mit einer Herz-Lungen-Maschine zu tun.
Wenn es so unwichtig ist, brauchst Du es eigentlich gar nicht
Fahr hin und schau, warum der Pi nicht erreichbar ist (oder alternativ ist evtl. jemand vor Ort, der den Pi abnabeln und zu Dir schicken kann).

openHAB hier die Schuld zu geben - und das ohne den geringsten Schimmer zu haben, was eigentlich passiert ist - ist nicht sehr nett.

Es war nicht böse gemeint. Aber wenn der Pi "nur" ein Stück Hardware ist woran sollte es denn liegen, wenn nicht an der Software?
Jedenfalls habe ich ein Problem und nicht das Know-How es zu lösen/analysieren - ich bin Anwender, kein Entwickler.
Das einzige was mir einfällt ist ein redundantes Zweit-System mit anderer Software aufzubauen.
Gruß
Andi

Das Problem ist nicht openhab sondern die SD Karte. Um das Risiko zu minimieren müsste wie udo1toni schrieb mindestens eine USV benutzt werden um korrupte Dateien zu vermeiden. Besser wäre auch noch eine SSD zu benutzen. Damit wären 90% aller Fehlermöglichkeiten beseitigt.

Ich danke euch, aber das ist mir technisch zu aufwendig. Ich habe beim Programmieren extra auf jede Haltung von remanenten Daten verzichtet um keine Schreibzugriffe auf die SD-Karte zu haben und um sie möglichst als reinen Ladespeicher für das Booten des Pi zu nutzen. Jetzt gewinne ich den Eindruck das Schreiben auf die Karte lässt sich garnicht verhindern weil es System-Immanent ist (und ist es bei anderen Systemen wohl auch). Und eine SSD ist, nach dem was ich verstehe, für große Datenmengen die schnell geladen werden sollen, Videos un so n Zeug. Habe ich alles nicht. Ich habe nur ein paar If-Then-Else-Abfragen mit Blockly in vielleicht 10 Scripts ohne sonst irgendwas um das System robust zu gestalten und bin beeindruckt wie einfach man eine gute Steuerung realisieren kann ohne den geringsten Schimmer von der Technik zu haben.

Wisst ihr ob und wie man die Schreibzugriffe auf die SD-Karte sperren kann? Für meine Anwendung halte ich es nicht für notwendig bei einem Verlust der Versorgungsspannung oder Internet-Kommunikation Daten rückzuschreiben. Nur das Booten/Lesen von der SD-Karte soll bei Spannungswiederkehr unverändert funktionieren.
Ich danke euch
Andi

Du kannst mit dem openHABian Image einfach ZRAM nutzen, das verlagert die meisten Schreibzugriffe ins RAM.
Wenn Du ein Standard Raspberry Pi OS als Unterbau nutzt (ohne openHABian, bzw. dieses erst nachinstallierst) kannst Du auch in raspi-config die Karte gegen Schreibzugriffe sperren. Du musst allerdings bei Updates auch daran denken, diese Schreibsperre zu lösen.
Bei jedem Umschaltvorgang muss der Pi neu booten, also: Raspberry aufsetzen, Software einrichten, konfigurieren... - Raspiconfig, Karte RO setzen - booten - System RO laufen lassen - raspi-config, Karte RW setzen - booten - Update, Konfig ändern, whatever - raspi-config, Karte RO setzen - booten ...

Mache ich bei einem Client, der im Garten untergebracht ist und sich um Streaming und Licht vor Ort kümmert. Das Teil läuft seit 10 Jahren ohne Probleme, und da ich der einzige bin, der das Gerät ordnungsgemäß herunterfahren kann, wird der häufiger unsachgemäß vom Netz getrennt (deshalb auch dieser Aufbau).

raspi-config ist im openHABian Image deaktiviert, weil es ein paar Kompatibilitätsprobleme gibt, um die sich niemand kümmern mag. ZRAM sollte man nicht in Kombination nutzen, denn raspi-config richtet ebenfalls ein Overlay Dateisystem ein, so dass es für normale Software so aussieht, als könne ganz normal geschrieben werden - ZRAM geht ähnlich vor.

openHAB komplett ohne Persistence? Bissi schade...