IntegrationGuard: Welche HACS-Erweiterung wird gepflegt, welche nutzt niemand?

Eine Home-Assistant-Installation sammelt Erweiterungen. Nach zwei Jahren sind es neunzig, und man weiß nicht mehr, welche noch weiterentwickelt werden, welche man nicht mehr benutzt und welche leise kaputt ist. IntegrationGuard beantwortet diese drei Fragen. Es liest denselben öffentlichen Store-Index, den HACS selbst benutzt, ergänzt ihn um die eigenen Dashboards und Config-Einträge und sagt, wo man hinschauen sollte.

Drei Fragen, drei Prüfungen

Wird sie noch gepflegt? Geprüft werden der letzte Commit, das neueste Release, ob das Repository bei GitHub archiviert oder gelöscht ist, ob es aus dem HACS-Store entfernt wurde oder auf der HACS-Sicherheitsliste steht, ob es nur Vorabversionen gibt und ob eine neuere Home-Assistant-Version nötig ist. Dafür gibt es Regeln, die sich einzeln abschalten, umgewichten und mit eigenem Schwellwert versehen lassen. Beim Start waren es 19 Regeln über alle drei Fragen.

Nutzt sie jemand? Eine Karte, die auf keinem Dashboard steht. Eine Integration ohne Config-Eintrag. Ein Theme, das niemand ausgewählt hat. Ein python_script, das niemand aufruft. Dazu Altlasten: Lovelace-Ressourcen, die auf nicht mehr vorhandene Dateien zeigen, und Ordner in custom_components, die HACS nicht kennt.

Funktioniert sie? Config-Einträge, die sich nicht einrichten ließen, Integrationen, die eine erneute Anmeldung verlangen, und Reparaturmeldungen von Home Assistant – live beobachtet und nicht einmal am Tag. Apps (früher Add-ons) werden auf Home Assistant OS und Supervised ähnlich bewertet: ihr Store-Repository, ob der Autor sie als veraltet markiert hat, ob der Supervisor sie noch anbietet und ob sie installiert, aber nie gestartet wurden.

Woher die Daten kommen

1. HACS im laufenden Prozess. Alles, was HACS heruntergeladen hat, auch benutzerdefinierte Repositories, die in keinem Store stehen. Auf einer gewachsenen Installation ist das ein Viertel von allem.
2. Der öffentliche HACS-Store-Index unter data-v2.hacs.xyz, dieselben Daten, die HACS ohnehin abruft. Daher kommen auch die Listen der entfernten und sicherheitsrelevanten Repositories.
3. GitHub, optional und nur für das, was die ersten beiden nicht beantworten: archiviert, Repository weg und Datum des neuesten Releases. Ohne Token erlaubt GitHub 60 Anfragen pro Stunde; bedingte Anfragen, die „nicht geändert“ melden, zählen nicht dazu, sodass nur der erste Lauf langsam ist.
4. Die eigene Installation: Dashboards, Config-Einträge, Reparaturen, Themes, das Konfigurationsverzeichnis.

Alles wird in .storage abgelegt, einschließlich des letzten Ergebnisses. Außer den zwei lesenden Anfragen verlässt nichts den Rechner. Das GitHub-Token ist die einzige optionale Eingabe beim Einrichten, und es braucht keinerlei Berechtigungen: GitHub gewährt jedem Token lesenden Zugriff auf öffentliche Repositories, mehr wird nicht genutzt.

Wie ungenutzte Karten gefunden werden

Der naheliegende Ansatz ist, die Element-Namen aus dem Bundle zu lesen. Das reicht nicht: Mushroom baut seine Kartenliste aus Variablen, ein regulärer Ausdruck findet einen Badge-Namen und verpasst jede Karte. Deshalb läuft die Prüfung in beide Richtungen: die Namen aus dem Bundle und jeder custom:-Typ, den die Dashboards anfordern, als Zeichenfolge im Bundle gesucht. Eine Karte, die ein Dashboard anspricht, muss ihren Namen irgendwo tragen.

Das Urteil „ungenutzt“ ist dabei streng reserviert: Nur ein Plugin, das eine eigene Karte über window.customCards oder ein Geschwister davon ankündigt, kann überhaupt als ungenutzt gelten. Ohne diese Ankündigung lässt sich nicht sagen, was ein Dashboard schreiben müsste, um es zu nutzen, die Antwort lautet dann „nicht feststellbar“. So bleiben card-mod, card-tools, kiosk-mode und custom-sidebar aus den Ergebnissen. Manche Plugins werden gar nicht als Karte angesprochen, sondern über einen eigenen Schlüssel, card-mod etwa durch card_mod: unter einer Karte; auch diese Schlüssel werden aus den Dashboards gelesen. Bei einem Strategy-Dashboard sinkt die Sicherheit um eine Stufe, weil eine Strategy erst beim Rendern entscheidet, was sie zeigt.

Panel, Karte, Entitäten, Benachrichtigungen

Das Panel hat acht Ansichten, die Lovelace-Karte registriert sich selbst (im YAML-Modus braucht es den Eintrag /integrationguard-frontend/integrationguard-card.js). Entitäten sind neun Sensoren – darunter sensor.integrationguard_score mit dem mittleren Gesundheitswert, in dessen Attributen das schlechteste Repository steht, das ein Mittelwert sonst verbergen würde –, ein Binärsensor integrationguard_critical und ein Schalter, der den Zeitplan pausiert. Entitäts-IDs folgen der Oberflächensprache: Eine deutsche Installation bekommt sensor.integrationguard_gesundheitswert. Benachrichtigt wird über SMTP, Telegram, Pushover, ntfy oder jeden Home-Assistant-Dienst, mit Schweregraden und Ruhezeiten. Elf Sprachen sind dabei; neun davon sind nicht von Muttersprachlern geprüft.

Korrekturen aus dem ersten Echtlauf

Die erste Version lief gegen eine echte Installation mit 122 Repositories und 31 Apps. Das brachte schnell Nachbesserungen:

• 0.1.1: Apps galten als ungenutzt, wenn sie nur gestoppt waren – 11 von 31, darunter Tailscale, Cloudflared, der Dateieditor und das SSH-Terminal, also alles, was man bei Bedarf startet. Der Supervisor verrät nicht, ob eine App je lief; deshalb wird keine App mehr als ungenutzt gemeldet. Außerdem meldete jeder Scan einen HTTP-404 vom HACS-Index, weil Apps dort keine Kategorie haben.
• 0.1.2: Integrationen mit ignorierter Erkennung wurden als „nicht geladen“ gemeldet. Wer bei einem entdeckten Gerät „Ignorieren“ wählt, behält einen Config-Eintrag, der nie eingerichtet wird. Bei powercalc waren 79 von 108 Einträgen und bei Battery Notes 13 von 14 solche Ignorierungen. Sie bleiben jetzt aus der Laufzeit- und der Nutzungsprüfung draußen.
• 0.1.3: card-mod und card-tools galten als ungenutzt – genau der Fall, den die Erkennung vermeiden soll. Die zweite Hälfte der Regel war eine Vermutung, die die Integration eigentlich nicht anstellen wollte; sie entfiel. Außerdem führte ein Klick auf ein Repository in der Übersicht ins Leere. Er wechselt jetzt in die Repository-Ansicht.
• 0.1.4: Die schlüsselbasierte Erkennung aus 0.1.3 lief nie, weil die Zeile fehlte, die die Schlüssel einsammelt. Die Änderung war auf ein Muster angewandt worden, das nicht mehr passte, und scheiterte ohne Fehler. Jetzt prüft ein Test auch das Einsammeln selbst.
• 0.1.5: Das Scan-Ergebnis überstand keinen Neustart; alle Sensoren standen auf unknown, bis fünf Minuten später der nächste Scan lief. Es wird jetzt gespeichert und beim Start wiederhergestellt.
• 0.1.6: Integrationen ohne eigene Entitäten wurden als ungenutzt gemeldet, bei der Fundstelle Switch Manager, Advanced Snapshot & Video und Unifi Device Info. Alle drei waren falsch. Der Maßstab ist jetzt: Ein aktivierter Config-Eintrag bedeutet „genutzt“; Entitäts- und Gerätezahlen werden noch angezeigt, entscheiden aber nichts.

Installation und Grenzen

In HACS unter „Benutzerdefinierte Repositories“ https://github.com/sphings79/integrationguard-home-assistant mit dem Typ „Integration“ hinzufügen, herunterladen, neu starten und unter Geräte & Dienste einrichten. Voraussetzung ist Home Assistant 2026.1.0 oder neuer. Apps gibt es nur unter Home Assistant OS oder Supervised; bei Container und Core bleibt diese Kategorie leer.

Absichtlich nicht dabei: Updates (das ist Sache von HACS), Deinstallation (IntegrationGuard zeigt nur) und Entitätsüberwachung. Ob ein Gerät antwortet, ist eine andere Frage, dafür gibt es StateGuard. Ein Urteil „verwaist“ oder „ungenutzt“ ist ein Hinweis, keine Tatsache; vor dem Entfernen prüfen. Die Integration ist inoffiziell und steht nicht in Verbindung mit dem Home-Assistant-Projekt, Nabu Casa, HACS oder GitHub.