Modifikationen
Was ich am Gateway geändert habe — und warum jede Änderung einen Vorfall als Ursache hat.
Ab Werk ist ein Gateway stumm: Es funkt, und man erfährt davon nichts. Läuft es noch? Kommen Pakete an? Wie warm ist es im Gehäuse? Alles, was hier dazugekommen ist, beantwortet eine dieser Fragen — und jede Änderung hat einen Vorfall als Ursache, keinen Wunschzettel.
Das Gateway spricht MQTT
Die grösste Erweiterung: Ein eigenes Überwachungsprogramm läuft neben dem Packet Forwarder und veröffentlicht laufend, was es sieht — auf meinen eigenen Broker, nicht in eine fremde Cloud.
Was dort ankommt, in vier Gruppen:
- Zustand — online, Internet erreichbar, Forwarder läuft, Herzschlag, Gehäusetemperatur, Luftfeuchte und Luftdruck
- System — CPU-Temperatur, Last, Arbeitsspeicher, Auslagerung und Füllstand der SD-Karte, letzteres als Frühwarnung
- Verkehr — Nachrichtenzähler, Zeitpunkt der letzten Nachricht, Laufzeit und Neustarts des Forwarders
- Statistik — eindeutige Geräte je Stunde und Tag, aufgeschlüsselt nach Netz und nach Spreizfaktor
Die Home-Assistant-Anmeldung ist nebenbei entstanden. Das Gateway meldet sich dort von selbst an, statt dass man jeden Wert von Hand einträgt — das funktioniert, ich benutze es aber gar nicht: Meine Visualisierung läuft über EisBär, und der liest die Topics direkt. Der Teil fiel ab, weil die Werte ohnehin sauber benannt und beschrieben sein mussten. Wer Home Assistant einsetzt, bekommt ihn geschenkt.
Ein „Letzter Wille" für den Ausfall
Der wichtigste Zusatz ist der unauffälligste. Ein Gerät, das abstürzt, kann nicht mehr melden, dass es abgestürzt ist — genau dann bräuchte man die Meldung aber.
MQTT kennt dafür das Last Will and Testament: Man hinterlegt beim Verbinden eine Nachricht, die der Broker verschickt, wenn die Verbindung abreisst. Nicht das Gateway meldet seinen Tod, sondern der Broker meldet ihn stellvertretend. Ohne das bleibt der letzte Wert für immer auf „online" stehen, und die Anzeige sieht bestens aus, während das Gerät kalt ist.
Zähler, die einen Stillstand sichtbar machen
Ein Gateway, das nichts empfängt, sieht aus wie ein Gateway, das gerade nichts zu tun hat. Deshalb laufen Zähler mit: Sekunden seit der letzten Nachricht, Laufzeit des Forwarders, Anzahl seiner Neustarts. Erst diese Zahlen unterscheiden „ruhig" von „tot".
Neustart mit Bremse
Stürzt der Forwarder ab, startet er neu — aber nicht sofort und nicht endlos schnell. Die Wartezeit wächst von fünf Sekunden auf fünf Minuten. Ein Dienst, der sich sekündlich neu startet, erzeugt vor allem Protokoll und verdeckt die Ursache.
Dazu ein Wächter, der den Forwarder neu startet, wenn sich die öffentliche Adresse wirklich geändert hat — nicht bei jedem Zucken der Namensauflösung.
Anzeige und Leuchten
Auf dem OLED stehen Adresse, Zustand und Zähler. Die vier LEDs zeigen dasselbe im Vorbeigehen. Das klingt nach Spielerei, ist aber der schnellste Weg zur Antwort auf „läuft es noch?" — schneller als jede Anmeldung.
Und was dabei schiefging
Die ehrlichere Hälfte des Berichts. Eine Auswahl:
- Ein Fehler-Topic ohne Gerätekennung — die Meldungen landeten an einer Stelle, an der niemand hinsah.
- Ein kurzer Aussetzer des Temperaturfühlers flutete das Protokoll mit identischen Meldungen. Jetzt wird nur noch der Wechsel des Zustands gemeldet, nicht jeder Messversuch.
- Die Wiederverbindung zum Broker rief eine Methode mit falscher Schreibweise auf — Python merkt das erst beim Ausführen, und zwar genau dann, wenn die Verbindung abgerissen ist. Also im ungünstigsten Moment.
- SIGTERM war nicht behandelt. Ein sauber beendetes Programm hinterliess denselben Eindruck wie ein abgestürztes.
- Und schliesslich starb der Raspberry Pi selbst — nicht die SD-Karte, nicht die Software. Die Ursache war eine Firmware-Schnittstelle, die auf Anfragen nicht mehr antwortete, ausgelöst vom Taktwechsel des Prozessors. Seitdem läuft der Takt fest, und die Abfrage, die sich damals aufhängte, liegt in einem eigenen Ausführungsstrang — sie kann jetzt höchstens sich selbst blockieren, nicht mehr die ganze Überwachung.