Nachdem mein Beitrag zum Thema automatische Lichtsteuerung ganz interessantes Echo erzeugt hatte, setze ich mich mal an ein weiteres Thema, das mich sehr interessiert und dessen Bedeutung für mich über die Jahre stark zugenommen hat. Es geht auch wieder um (leidvolle) Lernerfahrungen - denn lernen tun wir ja häufig insbesondere aus Fehlern.
Fire & Forget
Als ich mit Home Automation anfing war meine sämtliche Aktorik fire and forget. So nennen wir es in der Software salopp, wenn wir irgendeinen Befehl irgendwohin absenden und einfach darauf vertrauen, dass schon alles gut gehen wird. Ich sendete (damals per ELV FS10) halt so meine Schaltbefehle an die Lampen raus, irgendwann periodisch als mir auffiel, dass die Kommandos manchmal nicht ankommen. Das war sozusagen schon eine Stufe über dem klassischen fire and forget, praktisch ein agnostisches Dauerfeuer. Klappte ganz okay.
Auch auf der Sensorseite vertraute ich blind und ohne großartige Überprüfung auf die ermittelten Werte. Ich tat allerdings auch nicht viel mehr, als diese irgendwo anzuzeigen. Die Heizungsanalge zu steuern hatte ich mich damals noch nicht getraut und das war wohl auch besser so.
Über die Jahre wuchs die Komplexität meines Systems mit dem Anspruch, nicht bloß simpelste Logik vorzusehen, die nur funktioniert solange jedes Glied in der Kette intakt ist und das richtige tut. Zu oft kam ich in die Situation, dass irgendwo irgendein Teil versagte, aber ich es erst mitbekam, als es richtig störende Folgen hatte. Klassiker war meine Heizungssteuerung. Zuerst nutzte ich zur Gewinnung der Außentemperatur eine externe API. Dass diese seit mehr als einem Monat keine aktuellen Daten mehr hatte, fiel mir erst auf als es draußen kälter wurde und die Heizung aber nicht richtig warm wurde. Später hatte ich einen Temperaturfühler von EQ3 (HomeMatic oder noch HMS) im Einsatz, aber plötzlich schaltete sich mitten im Winter die Heizung ab - es war Wasser in den Fühler eingedrungen und er meldete eine Außentemperatur von 80°C.
Aus diesen Erfahrungen und der anschließenden, mitunter auch recht zermürbenden Fehlersuche bin ich relativ pingelig geworden, was die Überwachung des korrekten Funktionierens so ziemlich jedes Gerätes in meinem System betrifft. Noch immer ist es bei neuen Geräten oft so, dass ich sie voller Euphorie einbinden will, aber das Abfragen von Störungen (es ist doch nagelneu, was soll schon schiefgehen?) eher nervige Pflicht ist. Trotzdem lohnt es sich, immer einen Blick darauf zu haben, was alles schief laufen könnte. Wir kennen ja Murphy’s Gesetz…
Bei der Hardware fängt es an
Grundsätzlich ist von Vorteil, wenn die eingesetzte Hardware bereits Diagnosefunktionen bzw. Kanäle zur Störungsmeldung besitzt. Ein Gerät, das so freundlich ist uns selbst mitzuteilen wenn es nicht mehr korrekt funktioniert ist großartig, denn dieser Fall erspart uns viel educated guessing anhand von Sensordaten (dazu später mehr). Ideal sind Geräte wie die von HomeMatic, die spezielle Datenpunkte haben, um Störungen unterscheidbar zu melden. Auch meine Heizungsanlage kann relativ detailliert berichten, wenn etwas schief läuft. Andere Bausteine, etwa das Funkinterface zu den CO- und Hitzemeldern, haben einfach nur einen Ausgang „Sammelstörung“ und wenn diese Meldung vorliegt, ist trotzdem einiges an Herumprobieren nötig, um Fehlerort und -ursache zu finden. Aber generell ist es (wie auch bei unseren Mitmenschen) erfreulich, wenn das Gerät mit uns spricht - auch und gerade über Probleme.
Die Verarbeitung von Störungsmeldungen aller verbundenen Geräte ist Pflicht und das mache ich bei wirklich jedem Gerät, das solche Features bietet. Andere Geräte meide ich nach Möglichkeit ganz.
Tote reden nicht
Nicht in jedem Fehlerfall kann uns ein Gerät freundlich über Störungen informieren. Mitunter ist die Störung so gravierend, dass selbst der Teil des Gerätes, der Störungsmeldungen verschicken oder verarbeiten soll, defekt ist. Oder es ist einfach das Kabel defekt, die Spannungsversorgung ausgefallen, oder es gibt einen sonstigen Schaden an der Kommunikationsinfrastruktur.
Daher ist es neben allen anderen Prüfungen und Fehlerbehandlungen immer notwendig, sog. Watchdogs zu installieren, also Mechanismen, die ein Ausbleiben von Statusmeldungen, Sensormesswerten oder ähnlichen „Lebenszeichen“ des Gerätes detektieren.
Watchdogs setze ich bei jedem Gerät ein, das mir regelmäßige „Lebenszeichen“ sendet.
Plausiblitätsprüfung
Bei Geräten, die mit hohen Sicherheitsanforderungen konstruiert wurden (etwa einer Heizung) ist davon auszugehen, dass diese selbsttätig die Funktion ihrer Sensoren und in einigen Fällen auch die Plausiblität der gemeldeten Daten überprüfen. Wenn wir allerdings selbst Sensoren benutzen, um damit etwas zu steuern, dann sollten auch wir uns die Mühe machen, einige Prüfungen anzustellen, bevor wir gemeldeten Daten einfach blind vertrauen. Es ist, wenn schon nicht gefährlich, doch zumindest lästig, wenn wir fehlerhafte Sensordaten erst anhand von merkwürdigen Folgeproblemen bemerken.
Die einfachste Plausiblitätsprüfung sind Ober- und Untergrenzen. Da wir nicht in Sibirien leben ist eine gemeldete Außentemperatur von -25°C vermutlich nicht korrekt, hier im Norden war das Kälteste was ich jemals gemessen hatte -12°C. Und im Sommer sollte es auch nicht 80°C werden, jedenfalls nicht auf einem (noch?) bewohnbaren Planeten wie der Erde. Anhand sinnvoller Grenzwerte kann man also schon Probleme erkennen.
Außerdem wird ein gemessener Wert gewissen Schwankungen unterliegen. Bekommen wir von einer Datenquelle (egal ob eigener Sonsor oder fremde API) stets den exakt gleichen Messwert über längere Zeit, dann ist dies ein Hinweis darauf, dass etwas nicht stimmt.
Wer es ganz genau nimmt, kann noch nach auffälligen Sprüngen von Messwerten suchen, die auf Probleme hinweisen können - das ist allerdings dann nicht mehr ganz trivial und birgt auch ein hohes Risiko für Fehlalarme. Ich mache hiervon keinen Gebrauch und setze bei steuerungskritischen Werten lieber auf Redundanz
Plausiblitätsprüfung mache ich bei allen Messwerten, die ich für Steuerungsaufgaben nutze oder an prominenter Stelle anzeige.
Doppelt und Dreifach
In der Luftfahrt und bei KFZ sind einige Sensordaten so kritisch, dass es nicht ausreicht, einfach nur Fehler zu detektieren und zu melden - würden die Sensoren einfach ersatzlos ausfallen, so würden plötzlich wichtige Steuerungen versagen und es könnte zu gefährlichen Situationen kommen. Das System soll möglich auch bei Ausfall einzelner Sensoren weiter funktionieren (natürlich sollte die Störung immer trotzdem gemeldet und alsbald behoben werden).
Darum sind in den genannten Bereichen viele Sensoren mehrfach vorhanden. Dies bietet neben der Ausfallsicherheit auch die Möglichkeit, die Sensorwerte zu vergleichen, und damit einen weiteren Plausiblitätscheck vorzunehmen.
Angenommen, ich habe drei oder mehr Datenquellen für die aktuelle Außentemperatur. Melden diese dann 23°C, 22.7°C und 12°C, so deutet dies daraufhin, dass letzterer Wert vermutlich fehlerhaft ist, da die anderen beiden Werte relativ nah beieinander liegen. Voraussetzung für so eine Überprüfung ist natürlich, dass die Datenquellen ausreichend unterschiedlich funktionieren (also nicht bspw den HomeMatic-Doppel-Temperatursensor benutzen, um zwei Temperaturwerte zu bekommen, denn im Fehlerfall könnten diese ja beide vom selben Fehler betroffen sein).
Redundanz benutze ich bei kritischen Messwerten in Steuerskripten, soweit es technisch mit vertretbarem Aufwand möglich ist.
Bitte melde dich!
Wenn ich nun also mit viel Fleiß alle denkbaren Probleme, Fehler und Störungen überwache, was tue ich mit diesen Informationen? Es nutzt ja nicht viel, wenn ich diese Dinge irgendwo in ein Log schreibe, aber dann nie in dieses Log hinein sehe. Oder wenn die Werte zwischen uninteressanten Statusmeldungen einfach untergehen.
Ich habe bei meinem System eine tägliche Benachrichtigung per Email, in der alle Meldungen, kritische und eher unkritische zusammengefasst sind. Das ist sehr nützlich und ich lese diese auch wirklich jeden Tag (auch wenn manche Batteriemeldung auch mal ein, zwei Tage lang unbearbeitet bleibt).
Zusätzlich gibt es bestimmte Störungen, über die ich mich sofort informieren lasse. Beispielsweise will ich sofort (und nicht erst am nächsten Morgen mit dem täglichen Report) mitbekommen, wenn die Heizung ausfällt, oder sonstige wichtige Komponenten wie die Verbindung zum LCN oder zu HomeMatic. Ähnlich verhält es sich natürlich mit Alarmmeldungen, aber das ist nochmal ein anderes Thema.
Konsequenz und Selbstheilung
Bei gewissen Problemen ist es logisch, dass man als Konsequenz bestimmte Aktionen auslösen möchte. Besitzt man beispielsweise ein elektrisches Ventil, um die Wasserzufuhr zu unterbrechen, so möchte man bei Hinweisen auf austretendes Wasser dieses vermutlich schließen.
In einigen seltenen Fällen ist es auch bei „Softwareproblemen“ möglich und sinnvoll, automatisch Skripte zur Behebung des Problems auszuführen. Früher hatte ich sogar mal Skripte, die automatisch IPS oder den Rechner neu starten. Das funktionierte aber selten gut und habe ich so nicht mehr in Betrieb.
Was ich aktuell noch in Betrieb habe ist ein Skript zum automatischen Beheben von Verbindungsproblemen über Netzwerk-USB-Hubs. Nicht weil das besonders elegant wäre, sondern weil es leider nötig ist, aber immerhin klappt es, das zu automatisieren. Auch bei den Ebusd-MQTT-Devices für die Heizung habe ich Skripte, die bei Instanzfehlern automatisch diese reinitialisieren.
Solche Methoden sind aber stets als Workarounds zu betrachten, denn sie beheben ja nicht die eigentliche Ursache des Problems, sondern mildern lediglich die Folgen ab.
Profil zeigen
Neben der oben beschriebenen Meldung per „Wartungs-Übersichts-Seite“/Email bin ich dazu übergegangen, bei Problemen, die ein bestimmtes Gerät betreffen, dies auch in der Bedienoberfläche des Gerätes anzuzeigen. Also beispielsweise möchte ich, wenn ein LCN-Busmodul nicht erreichbar ist, gerne beim Bedienfeld für die betroffenen Leuchten, dass dort statt dem üblichen Slider ein Fehlerstatus angezeigt wird. Ähnlich ist es bei den Raumthermostaten - wenn ein HomeMatic-Raumthermostat UNREACH ist, dann will ich dort eine Meldung im WebFront anstatt der üblichen Bedienelemente. Bei Sensoren wiederum will ich eben auch eine Warnung anzeigen, wenn etwas nicht stimmt und zwar an der gleichen Stelle, wo ich sonst den Messwert sehe.
Ich löse dies über Skripte, die dynamisch das Variablenprofil der entsprechenden Variable (Sensorwert oder auch Dimmstufe / Stellwert / Modus) durch ein spezielles „Fehlerprofil“ austauschen können. Letzteres besteht einfach nur aus einer einzigen Association in rot mit einer Warnmeldung als Text. Dadurch erreiche ich einen sehr übersichtlichen und eindeutigen Look im WebFront und habe nicht das Problem dass bei Ausfällen einfach irgendwelche Steuerelemente angezeigt werden, aber nicht mehr reagieren. Ich sehe dort, wo ich normalerweise etwas bedienen würde, dass es nicht funktioniert.
Diese Methode hat sich sehr bewährt und ich wende sie nach und nach auf sämtliche Bedienlemente an, auch wenn das ein nicht unerheblicher Aufwand ist. Aber es wirkt auf mich alles viel „solider“ seitdem ich davon ausgehen kann, dass ein normal aussehendes Bedienelement im WebFront bereits darauf hindeutet, dass das entsprechende Gerät intakt und erreichbar ist.
Fazit
Ich hoffe, dieser Beitrag ist auch ohne konkreten Code nützlich für manche von euch, und sei es nur als Anstoß, eure eigenen Erfahrungen und Gedanken zum Thema mitzuteilen. Es gibt noch Aspekte die ich gar nicht beleuchte, etwa dass man bei Fehlermeldungen in komplexen Systemen manchmal bestimmte Zusammenhänge beachten und danach priorisieren sollte, was man meldet (Beispiel: Ein Switch fällt aus - hier möchte ich vor allen Dingen erkennen können, dass der Switch nicht erreichbar ist, statt mit tausenden Meldungen über Folgeprobleme zugemüllt zu werden). Aber der Post ist ja schon recht lang geworden. :rolleyes: