Reboots/Fehler - was kann man tun?!

Owned by Gerrit Brehmer
Last updated: 22.02 2020
4 min read



Gerne um eigene Erfahrungen ergänzen/korrigieren. Hier sollen möglichst alle Gründe aufgeführt werden, die zu ungeplanten Restarts führen können, so dass jeder mit solchen Reboots hier eine potentielle Lösung für sein Problem finden kann.

Mögliche Ursachen und potentielle Lösungen

  • Miniserver ist von außen ohne VPN erreichbar

    • Miniserver nur über VPN von außen erreichbar machen

  • SD Karte überlastet / defekt

    • SD-Karten Test  <IP-Miniserver/dev/sys/sdtest> - Klärung der Ergebnisse mit Loxone oder im Forum, neuere Miniserver Versionen schicken bei Problemen mit der SD Karte Pushnachrichten & Mails

    • z.B. Statistiken tw. oder ganz deaktivieren

    • neue SD Karte - am besten Original Loxone SD Karte oder empfohlene aus dem Wiki

  • Anfragen an IPs die es nicht mehr gibt oder die nur noch Fehler zurückgeben oder langsam antworten

  •  

    • Ping Bausteine, HTTP-Verbinder etc. checken

    • Umwandlung in Virtuellen Eingang: Pushen zum Miniserver nur bei Änderung statt Pollen (notfalls über ioBroker, FHEM, node-red, ... als Vermittler)

  • Zu viele Objekte im Loxone Config Projektfile -> Info Anzahl Objekte erkennen

  •  

    • keine festen Grenzen bekannt, alle Werte sind nur Anhaltspunkte

    • Programmierung reduzieren, nicht benötigte Teile entfernen, ...

  • Bug im Miniserver bzw. der Firmware von Loxone

  • Probleme Loxbus, Stromversorgung, …

    • Analyse in Loxone Config

    • Spannung nachmessen, ...

  • Abfrageintervalle von Virtuellen HTTP-Eingängen

    • Die abgefragte Webseite prüfen - ist die sehr groß (Speicherbedarf am Miniserver!) ? Alternativen suchen.

    • Kurz eingestellte Intervalle vergrößern

    • Befehlserkennungen auf das Notwendigste reduzieren (jede einzelne Befehlserkennung sucht im gesamten HTTP-Response nach dem Text)

    • Umwandlung in Virtuellen Eingang: Pushen zum Miniserver nur bei Änderung statt Pollen (notfalls über ioBroker, FHEM, node-red, ... als Vermittler)

  • UDP-Pakete

    • Befehlserkennungen auf das Notwendigste reduzieren (jede einzelne Befehlserkennung sucht im UDP-Eingang nach dem Text)

    • (insbesondere wenn UDP-Befehle aus Templates geladen wurden, sind oft viele Eingänge dabei, die man garnicht braucht)

    • Wenn möglich, in der UDP-Quelle Caching verwenden, damit nur Änderungen per UDP übertragen werden

    • Testweise die UDP-Übermittlung komplett deaktivieren

  • Zu viele Log ausgaben im def.log = zu hohe Schreiblast

    • Logger deaktivieren

  • Virtuelle Ausgänge prüfen

    • Das Speichern der Antwort soll deaktiviert sein (Schreibzugriff auf der SD)

  • PicoC Programme: Dabei gab es von Loxone bereits Memory Leaks in deren Interpreter, diese kann man aber auch selbst ganz leicht im Code produzieren!

    • Testweise alle Pico-C Programme entfernen

  • Merker

    • Alle Merker überprüfen, ob dort eine Verzögerung eingestellt ist

    • Eine Verzögerung von 1 belegt einen Speicherplatz

    • Eine Verzögerung von 100 belegt 100 Speicherplätze

    • Hohe Verzögerung im Merker erhöht den Speicherverbrauch im RAM des Miniservers

  • Gleitender Mittelwert

    • Viele Zyklen erhöhen den RAM-Speicherverbrauch des Miniservers

  • Impulsgeber

    • Durchgehend laufende Impulsgeber mit sehr kleinen Intervallen belasten die CPU des Miniservers stark

  • Verwendung Loxone HTTP/Websocket API prüfen, also Fremdsysteme, die per HTTP Requests in Loxone Befehle ausführen oder Werte pushen

    • Viele Aufrufe von außen belasten den Miniserver

    • Externe Systeme: iobroker, node-red, ...

Was kann man noch tun

  • def.log nach Fehlermeldungen zum besagten Zeitpunkt des Reboots anschauen

    • http://<miniserver_ip>/dev/fsget/log/def.log

  • Systemnachrichten aktivieren, damit man Reboot direkt mitbekommt

  • Bei Loxone anfragen, ob deren Crashlog-Service etwas mitbekommen hat (dafür muss die Crashlog Funktion aktiviert sein -> Screenshot wo Einstellung)

  • SD-Karte austauschen

  • Loxforum nach aktuellen Fehlermeldungen von anderen Usern durchsuchen

Eigene, externe Scripte

  • Die Antworten von http-Requests so kurz wie möglich halten

  • UDP-Übertragungen nur mit echten Daten (keine unnützen Daten/Texte usw. mitschicken)

  • Daten per UDP zusammenfassen, statt vieler einzelner Requests

  • Nur geänderte Daten übermitteln (selbst irgendwo cachen)

Miniserver in Verbindung mit einem LoxBerry

  • Die Menge an Daten, die an den Miniserver übertragen, oder vom Miniserver abgeholt werden, ist vom jeweiligen Plugin abhängig.

  • Wenn das Plugin wahlweise eine Übertragung zum Miniserver per HTTP oder UDP erlaubt, wähle nur einen dieser Übertragungswege aus. Beide Varianten gleichzeitig verdoppeln die Last am Miniserver.

  • Die Übertragung per HTTP vom Plugin zu Miniserver ist ressourcenschonender als per UDP, da bei HTTP die Daten direkt gesetzt werden, und dadurch die Befehlserkennungen am Miniserver wegfallen. Das gilt nur, wenn das Plugin Werte direkt im Baustein setzen kann! Wird ein Virtueller HTTP Eingang benutzt, ist die Last am Miniserver gleich hoch wie bei einem UDP-Eingang.

  • Wenn ein Plugin eine Webseite/JSON oder dergleichen anbietet, um dies am Miniserver per Virtuellem HTTP-Eingang abzurufen, dann das Intervall auf den größtmöglichen Wert stellen, der für deinen Anwendungsfall sinnvoll ist.

  • Wenn das Plugin ein Übertragungsintervall anbietet, verwende den größten Zeitabstand, der für deinen Anwendungsfall möglich ist. Beispielsweise macht es keinen Sinn, die Feuchtigkeit des Pflanzensensors alle fünf Sekunden zu übertragen.

  • LoxBerry verwendet eine eigene, cachende Library zum Übertragen von Daten per HTTP und UDP an den Miniserver. Damit werden ausschließlich Wertänderungen übertragen. Die Library erkennt auch Miniserver-Neustarts, um automatisch alle Daten neu zu übertragen. Jedoch liegt es beim Plugin-Entwickler, diese Library einzusetzen. Du solltest jedenfalls alle Plugins auf den aktuellen Stand bringen.

  • Das LoxBerry-Grundsystem selbst führt nur bei Interaktion durch dich Anfragen gegen den Miniserver aus (z.B. bei der Authentifizierungsprüfung beim Einrichten der Miniserver). Alle Funktionen und bereitstehenden Libraries von LoxBerry sind darauf entwickelt, möglichst wenig Netzwerkverkehr am Miniserver zu erzeugen.

  • In der Situation, dass du Miniserverausfälle hast: Schalte deinen LoxBerry für eine aussagekräftige Zeit lang aus, um zu erkennen, ob der LoxBerry mit deinem Problem zu tun hat. Bestätigt sich das, prüfe - wie oben angegeben - die Einstellungen durch. Du kannst im loxforum auch einen Thread erstellen, um deine Probleme zu schildern. Nenne auf jeden Fall alle installierten Plugins.

Wie kann man vorsorgen

  • Einzelne Tipps:

    • Regelmäßig Backups erstellen

    • SD-Karte als Ersatz bereithalten

    • def.log immer mal wieder anschauen (sehr einfach aus dem LoxBerry "Miniserver"-Widget möglich)

  • Umfangreiche Sammlung auf separater Wiki-Seite: Betriebssicherheit



Die Größenordnungen ("viel" oder "wenig") immer in Anbetracht der eingesetzten Hardware sehen. Ein Raspberry Pi 1 hat etwa 10x mehr Leistung als ein Miniserver - die Miniserver-Hardware ist am technischen Stand von vor über 10 Jahren. Der alte Herr schlägt sich gut, ist aber nunmal nicht mehr der Jüngste.