sphings-dev.de

IntegrationGuard 0.1.7 bis 0.1.9: Eine Benachrichtigung pro Problem – und keine Flut

Die Version 0.1.7 von IntegrationGuard hat die Benachrichtigungen in Home Assistant umgebaut, brachte aber zwei Nebenwirkungen mit, die 0.1.8 und 0.1.9 beheben.

Zwei Fehler in 0.1.7

Eine Laufzeitmeldung nannte das falsche Gerät. Der Name stammte aus dem ersten Config-Eintrag der Integration, Zustand und Grund aus dem Eintrag, der tatsächlich kaputt war. Bei tuya-local wurde so eine funktionierende Deckenlampe beschuldigt, weil ein anderes Gerät offline war. Name, Zustand und Grund kommen jetzt aus demselben Eintrag.

Jeder Neustart erzeugte Fehlalarme. Der Laufzeit-Monitor bewertete die Config-Einträge, während Home Assistant noch startete und die meisten schlicht noch nicht eingerichtet waren. Für Integrationen, die eine Sekunde später in Ordnung waren, ging „nicht geladen“ hinaus. Jetzt wartet der Monitor, bis Home Assistant gestartet ist; „nicht geladen“ bekommt dieselbe Karenzzeit wie „versucht es erneut“, und ein Eintrag, der gerade eingerichtet oder neu geladen wird, behält sein letztes Urteil, statt kurz als repariert zu erscheinen.

Der Umbau: ein Problem, eine Meldung

Bisher gab es in Home Assistant eine Benachrichtigung pro Schweregrad, und jedes neue Problem ersetzte das vorherige. Jetzt hat jedes Repository und jede Integration eine eigene. Verschwindet das Problem, wird die Benachrichtigung entfernt, statt durch eine weitere beantwortet zu werden; sind weniger Einträge einer Integration betroffen, wird sie leise aktualisiert. Eine weggeklickte Benachrichtigung bleibt weg.

Push-Kanäle können eine Nachricht nicht zurücknehmen und bekommen deshalb weiterhin „wieder in Ordnung“, wenn das eingeschaltet ist – jetzt auch für Integrationen, aber nur für Probleme, von denen sie tatsächlich erfahren haben. Benachrichtigungen überleben keinen Neustart von Home Assistant, daher werden die noch gültigen danach wiederhergestellt, ohne etwas zu senden.

Mehrere defekte Einträge derselben Integration sind außerdem eine einzige Meldung. Statt einen Eintrag zu nennen, steht dort, wie viele betroffen sind, mit Grund je Eintrag:

IntegrationGuard: Tuya Local
2 entries keep retrying:
Garden socket: device offline
Hall light: device offline

Eine neue Nachricht geht hinaus, wenn ein weiterer Eintrag dazukommt, nicht wenn einer sich erholt. Panel, Karte und Verlauf zeigen die Integration mit der Anzahl betroffener Einträge. Die Karenzzeit zählt jetzt pro Eintrag, sodass ein gerade ausgefallenes Gerät auch dann wartet, wenn ein anderes seit Stunden hängt.

Zudem wird jetzt jede Integration standardmäßig überwacht, nicht nur die aus HACS. Ein TP-Link-Stecker oder ein Android TV, der ständig neu versucht, ist ebenso wissenswert; ignorierte Erkennungen, die das bisher laut machten, sind seit 0.1.2 ausgenommen. Das ändert nur den Standard für neue Installationen. Zum Einschalten: Panel → Einstellungen → Laufzeit → „Alle Integrationen, nicht nur die aus HACS“.

0.1.8: Das war zu viel

Auf einer Installation mit 54 Befunden bedeutete 0.1.7 unmittelbar nach dem Update 54 Benachrichtigungen. In 0.1.8 teilen sich Repositories wieder eine Benachrichtigung pro Schweregrad, die sie auflistet – „IntegrationGuard: 12 findings“ statt zwölf einzelner. Sie wird aktuell gehalten: Sie schrumpft leise, wenn Repositories repariert sind, verschwindet, wenn nichts mehr übrig ist, und öffnet sich nur wieder, wenn etwas Neues darin angekündigt wird. Integrationen behalten je eine Benachrichtigung, denn es gibt wenige und sie sind dringlicher.

Zwei weitere Korrekturen: Ein bereits gemeldetes Laufzeitproblem konnte wie behoben aussehen. Ein Eintrag, der schon gemeldet war, fiel in die Karenzzeit zurück, wenn seine Uhr neu startete oder die Karenzzeit verlängert wurde; er zählte dann als funktionierend und wurde nach Ablauf ein zweites Mal gemeldet. Jetzt gilt die Karenzzeit nur für frische Probleme. Außerdem wurden von Hand abgeschaltete Config-Einträge als „wartend“ aufgelistet, als säßen sie ihre Karenzzeit ab. Abschalten ist eine Entscheidung, kein Problem, sie erscheinen nicht mehr.

Und eine Änderung des Standards: Info zeigt auf neuen Installationen keine Benachrichtigung in Home Assistant. „Einen Blick wert“ ist keine Benachrichtigung wert – auf einer typischen Installation sind das Dutzende Repositories, und Panel und Sensoren listen sie ohnehin. Bestehende Installationen behalten ihre Einstellung; zum Ändern im Panel unter Regeln → Schweregrade „Benachrichtigung in Home Assistant“ für Info abschalten.

0.1.9: Entfernte Meldungen bleiben entfernt

Mit einer Integration, die Benachrichtigungen über Neustarts hinweg behält, wie Restore Persistent Notification, kamen die von IntegrationGuard entfernten Meldungen nach dem nächsten Neustart zurück. Solche Integrationen bemerken nur Änderungen über den Dienst persistent_notification, und IntegrationGuard rief die Funktionen dahinter auf. Auf einer Installation standen die 0.1.7-Meldungen für jedes einzelne Repository nach dem Update auf 0.1.8 weiterhin da – 65 insgesamt.

Benachrichtigungen werden jetzt über den Dienst angelegt und entfernt, und nur dann entfernt, wenn sie tatsächlich offen sind, damit ein Scan solche Integrationen nicht grundlos zum Speichern bringt. Was ältere Versionen hinterlassen haben, wird aufgeräumt: Sobald Home Assistant gestartet ist, übernimmt IntegrationGuard die zurückgebrachten Benachrichtigungen und bringt sie auf den neuesten Stand. Es entfernt die von 0.1.6 (eine pro Schweregrad) und 0.1.7 (eine pro Repository) angelegten, die in dieser Form nicht mehr existieren, sowie die zu Integrationen, die wieder funktionieren. Nach Update und Neustart bleiben nur die Benachrichtigungen, die noch zutreffen.

Tags

Zum Projekt

Unterstützen

Diese Tools entstehen in meiner Freizeit und bleiben kostenlos, offen und cloud-frei. Wenn dir eins davon einen Nachmittag gespart hat, freue ich mich über einen Kaffee oder ein Stück Pizza.

Kaffee oder Pizza

Weitere Beiträge