Ein Alarm-Dashboard + Tecnoalarm-Tastatur in Home Assistant

Die interessanteste Entscheidung in diesem ganzen Projekt war keine Lovelace-Karte. Es war die Frage, was nicht auf den Bildschirm gehört. Ein Alarm-Dashboard ist per Definition eine Karte davon, wo mein Haus angreifbar ist — jedes offene Fenster, jede Tür, durch die jemand hereinkommen könnte. Baut man das unbedacht, hat man eine Einbruchsanleitung veröffentlicht. Bevor ich also eine einzige Karte ausgerichtet habe, habe ich mir eine Regel gegeben: Das Panel darf in meinem eigenen Netz so detailliert sein, wie ich will, aber alles, worüber ich schreibe, wird umbenannt, abstrahiert und vom echten Grundriss befreit. Diese Spannung — nützliche Operator-Konsole vs. wörtliche Bedrohungskarte — hat jede Entscheidung unten geprägt.

Der ehrliche Teil: Ich habe es gegen Fake-Sensoren gebaut

Hier das Geständnis, das diesen Beitrag erst nützlich macht. Als ich anfing, waren die meisten physischen Tür- und Fensterkontakte noch nicht verkabelt. Statt zu warten — oder für jede Iteration auf eine Leiter zu steigen — habe ich simulierte binary_sensors angelegt, Entity-IDs, die auf _sensor_sim enden, und das ganze Dashboard dagegen gebaut. Ich konnte auf der Couch sitzen, ein Fake-Fenster auf "offen" stellen und zusehen, wie die ganze Pipeline aufleuchtet: Status-Raster, Logbuch-Eintrag, Benachrichtigung, alles.

Das stellte sich als die beste Entscheidung des Aufbaus heraus. UI-Arbeit an einem Sicherheits-Panel ist fummelig — man will den roten Zustand sehen, den scharf-geschalteten Zustand, den alles-zu-Zustand — und die kann man von echter Hardware nicht zuverlässig auf Abruf herbeiführen. Simulierte Sensoren gaben mir einen steuerbaren Prüfstand. Als die echten Kontakte eingebaut wurden, wusste das Dashboard bereits, wie es jeden Zustand rendert, und ein Sim-Entity gegen ein echtes zu tauschen war eine Ein-Zeilen-Änderung. Wenn du irgendeine zustandsgetriebene HA-UI baust: fake zuerst die Eingänge.

Zwei Helfer, auf den Bus gespiegelt

Das Ganze läuft auf nur zwei input_boolean-Helfern. Einer ist der Haupt-Scharf/Unscharf-Schalter; der andere ist ein "Alarm bereit"-Flag, das nur wahr ist, wenn jede überwachte Öffnung geschlossen ist. Beide werden auf den KNX-Bus gespiegelt, und das ist der stille Trick, der die physische Welt und Home Assistant in Einklang bringt. Die Wandtastatur — eine Tecnoalarm-Einheit — spricht KNX. Schaltet jemand an der Tastatur scharf, kippt die Gruppenadresse, und der HA-Helfer folgt; toggle ich den Helfer im Dashboard, folgt der Zustand der Tastatur zurück.

Ich halte diese Brücke bewusst konzeptionell: Tecnoalarm-Tastatur → KNX → HA-Helfer, mehr nicht. Die Erkenntnis, die man mitnehmen sollte, ist das Muster, nicht meine Gruppenadress-Karte. Ein schlichter Boolean als geteilte Wahrheitsquelle zwischen einem dedizierten Panel und dem Smart-Home-Stack ist sauber, debugbar und herstellerunabhängig. Was auch immer den Boolean kippt — Tastatur, Dashboard-Knopf, Automation — der Rest des Systems beobachtet einfach den Boolean.

Das Status-Raster: eine Jinja-Vorlage des Hauses

Das Herzstück ist eine Standard-Markdown-Karte mit einer Jinja-Vorlage pro Sensor. Grüner Punkt heißt geschlossen und sicher; rot heißt offen und würde-auslösen. Keine eigene Integration, keine HACS-Karte — nur Markdown und die Templating-Engine, die HA ohnehin mitbringt. Das Muster ist trivial wiederholbar, eine Zeile pro Öffnung:

{% if is_state('binary_sensor.garage_door_status', 'on') %}🔴{% else %}🟢{% endif %} Garage
{% if is_state('binary_sensor.window_office_status', 'on') %}🔴{% else %}🟢{% endif %} Office

Insgesamt gibt es 12 überwachte Fenster- und Türsensoren — 7 im Erdgeschoss, 5 im Obergeschoss — und ich gruppiere sie sowohl im Raster als auch im Logbuch nach Etage, damit das Panel sich wie das Gebäude liest und nicht wie eine flache Entity-Liste. (Ich zeige hier zwei generische Beispielsensoren; das echte Raster nutzt anonymisierte englische IDs, niemals das Zimmer-für-Zimmer-Inventar.) Das Garagentor ist nur ein weiterer Kontakt in dieser Liste, was wichtiger ist, als es klingt: ein Garagen-Eindringversuch läuft durch genau dieselbe Scharf/Melde/Log-Pipeline wie jedes Fenster.

Der Stolperstein: ein naiver Trigger schlägt Fehlalarm

Jede überwachte Öffnung bekommt ihre eigene Automation — einen State-Trigger von off auf on — statt einer großen Vorlage. Pro-Sensor-Automationen bedeuten pro-Sensor-Logmeldungen und -Benachrichtigungen, und das ist das zusätzliche YAML wert. Meine erste Version löste den Alarm in dem Moment aus, in dem ein Kontakt offen meldete. Das war ein Fehler. Kontakte zappeln. Ein kurzes Flattern, ein sich setzender Sensor, ein Luftzug — und plötzlich ist das Haus erleuchtet und um 3 Uhr nachts brummen die Handys grundlos.

Die Lösung ist eine for:-Dauer am Trigger: nur auslösen, wenn der Kontakt offen bleibt. Fang mit einem kurzen, einstellbaren Wert an, während du das Verhalten beobachtest — fünf Sekunden lesen sich auf dem Papier gut:

triggers:
  - trigger: state
    entity_id: binary_sensor.garage_door_status
    from: "off"
    to: "on"
    for:
      seconds: 5

Nachdem ich mit echten Fehlalarmen gelebt hatte, kletterte mein tatsächlicher Wert auf 30 Sekunden Prüf-und-Nachprüf-Zeit, bevor der Alarm sich festlegt. Das ist der einstellbare Knopf bei der Arbeit — lang genug, um Glitches zu schlucken, kurz genug, dass ein echtes Eindringen mich anpiept, lange bevor sich jemand eingerichtet hat. Behandle die 5-Sekunden als Startpunkt, nicht als Evangelium; die richtige Zahl ist das, was das Rauschniveau deiner Hardware verlangt.

Doppeltes Logging, damit Ereignisse einen Blick überleben

Wenn der Alarm sich festlegt, fächert er sich über mehrere Kanäle auf: kritische Push-Benachrichtigungen an die Haushalts-Handys, eine hörbare Sirene und Lichter, die in den Verkehrsbereichen anspringen — Küche, Treppenhaus, Flure — damit ein Einbruch sichtbar gesehen wird statt lautlos. Die genaue Sirenen-Entity und die Lichtkreise lasse ich hier bewusst weg; beschreibe die Reaktion, gib nicht die Verkabelung heraus.

Was ich jedem empfehlen würde, ist das Logging. Jeder Trigger schreibt beides: einen logbook.log-Eintrag ("Alarm Event" genannt, mit dem Sensor und einer Verifizierungsnotiz) und eine persistent_notification, die im Glocken-Menü sitzt, bis ich sie wegwische. Das eine ist die Zeitleiste; das andere ist das klebrige "hey, schau dir das an", das einen flüchtigen Blick aufs Handy überlebt. Das Dashboard zeigt das direkt: eine 24-Stunden-Logbuch-Karte, gefiltert auf genau die Alarmsensoren, plus ein 8-Stunden-History-Graph der aktivsten Kontakte, um Muster zu erkennen. Doppeltes Logging heißt, ein Ereignis kann nicht leise wegscrollen.

Schnellaktionen, ein Mobile-Rahmen und wo das sitzt

Drei Knöpfe erledigen den Alltag: Scharf, Unscharf und ein Sprung-zum-Logbuch. Scharf und Unscharf rufen input_boolean.turn_on / turn_off auf demselben Helfer auf, den die KNX-Tastatur kippt, und der Logbuch-Knopf ist eine schlichte Navigate-Aktion. Weil alles über diesen einen Boolean läuft, sind das Dashboard-Unscharf und das physische Tastatur-Unscharf buchstäblich derselbe Vorgang.

Das ganze Panel ist Mobile-First gebaut — touch-große Knöpfe (Icon-Höhe um die 40px), ein scrollbares Logbuch, eine einklappbare Statusliste — damit es als Handy-Wandpanel an der Tür funktioniert. Die komplette Konfiguration liegt in den üblichen HA-Dateien: Automationen, eine input_booleans-Datei und eine knx-Datei, die die Helfer auf Gruppenadressen abbildet, alles unter git, damit ich genau sehe, was sich wann geändert hat.

Hier der Trade-off in klaren Worten, denn ich glaube, viele verstehen ihn falsch herum. Ein Home-Assistant-Dashboard ist eine fantastische Operator-Konsole — Hauszustand auf einen Blick, eine durchsuchbare Historie, Ein-Tipp-Scharf/Unscharf, eine Licht-und-Sirenen-Choreografie, die man von einer eigenständigen Box nie bekäme. Was es nicht ist, ist eine einzige Wahrheitsquelle für Sicherheit. Es hängt an einem Server, einem Netzwerk und Software, an der ich aktiv bastle; ein dediziertes Alarm-Panel ist eigens dafür gebaut, weiterzulaufen, wenn all das umfällt.

Die HA-Schicht ergänzt also das dedizierte System, sie ersetzt es nicht. Auf das Tecnoalarm-Panel würde ich das Haus verwetten; das Dashboard ist das, was mir das Haus im Alltag lesbar macht. Es öffentlich zu bauen hieß nur, ehrlich zu dieser Grenze zu sein — und diszipliniert dabei, auf welche Seite davon die Details gehören. Wenn du das Fundament willst, auf dem das hier steht, behandeln die früheren Teile dieser Serie Home Assistant in Docker zu betreiben und den breiteren Stack zum Reden zu bringen.