Wichtigste Erkenntnisse
- Jeder Sensortyp hat allein verwendet seine eigene Fehlerquelle — Sensorfusion hebt diese auf, indem sie Übereinstimmung verlangt
- Umgesetzt mit Standard-Home-Assistant-Automatisierungsbedingungen (Multi-Condition-Trigger oder Template-Sensoren), keine spezielle Hardware
- Häufiges Muster: Radar + PIR-Bewegung für Anwesenheit, Kontakt + Kamera für Sicherheitsereignisse
- Bei mehreren unvollkommenen Signalen gewichtet der Bayes’sche Binärsensor von Home Assistant jedes nach Zuverlässigkeit, statt feste UND/ODER-Regeln zu nutzen
- Der Trade-off ist zusätzliche Automatisierungskomplexität und etwas mehr Einrichtungszeit für spürbar weniger Fehlauslösungen
- Siehe den Leitfaden zur Radar-Anwesenheitserkennung für den Sensortyp, der am häufigsten mit Bewegungserkennung fusioniert wird
Warum ein Sensor nicht ausreicht
Jeder Sensortyp hat einen spezifischen blinden Fleck: PIR-Bewegungssensoren übersehen still sitzende Personen, Radar kann gelegentlich bei Gerätevibrationen einen False Positive erzeugen, Kontaktsensoren identifizieren nicht, wer sie ausgelöst hat, und Kameras werfen Datenschutzfragen auf, die kamerafreie Sensoren vermeiden.
- Eine reine PIR-Anwesenheitsautomatisierung schaltet das Licht bei jemandem aus, der still sitzt — ein bekanntes Ärgernis bei reinen PIR-Automatisierungen im Smart Home.
- Eine reine Radar-Automatisierung kann je nach Empfindlichkeitseinstellung gelegentlich einen False Positive durch einen Ventilator, HVAC-Vibrationen oder ein Haustier registrieren.
- Sich auf einen einzelnen Sensor zu verlassen bedeutet, dessen spezifische Fehlerquelle in jeder darauf aufgebauten Automatisierung zu übernehmen.
Eine Fusions-Automatisierung erstellen
In Home Assistant wird Sensorfusion typischerweise als Template-Binärsensor umgesetzt, der die Zustände von zwei oder mehr Quellsensoren mit UND/ODER-Logik kombiniert, den nachgelagerte Automatisierungen dann als einen einzigen, zuverlässigeren Trigger behandeln.
- Ein einfacher Anwesenheits-Fusions-Template-Sensor könnte „belegt" nur melden, wenn entweder der Radarsensor aktiv ist oder der PIR-Sensor innerhalb der letzten paar Minuten ausgelöst hat — das deckt sowohl sofortige Erkennung als auch den Fall einer still sitzenden Person ab.
- Für Sicherheitsautomatisierungen reduziert die Kombination eines Kontaktsensors (Tür geöffnet) mit einem kamerabasierten Personenerkennungsereignis (siehe den Leitfaden zu lokalen KI-Sicherheitskameras) vor dem Auslösen einer Benachrichtigung Fehlalarme — etwa wenn eine Tür geöffnet wird, aber niemand zu sehen ist.
- Halte die Fusionslogik in einem Template-Sensor, statt die Multi-Condition-Logik über mehrere separate Automatisierungen zu duplizieren — das erleichtert spätere Anpassungen.
Häufige Fusionsmuster
Die häufigsten Fusionsmuster sind Anwesenheit (Radar + Bewegung), Sicherheit (Kontakt + Kameraerkennung) und Umgebungsdaten (mehrere Temperatur-/Feuchtigkeitssensoren gemittelt, um die Platzierungsverzerrung eines einzelnen Sensors auszugleichen).
- Anwesenheit: Radarsensor für die Erkennung stillsitzender Personen, PIR für sofortige Bewegungsreaktion, kombiniert, damit Lichtautomatisierungen schnell reagieren und nicht bei einer still sitzenden Person abschalten.
- Sicherheit: Tür-/Fensterkontaktsensoren kombiniert mit kamerabasierter Personenerkennung, sodass eine Benachrichtigung nur ausgelöst wird, wenn sowohl ein physisches Eintrittsereignis als auch eine visuelle Bestätigung übereinstimmen.
- Umgebung: Mittelung mehrerer Temperatursensoren in einem Raum, um den Einfluss eines Sensors zu reduzieren, der in einem Luftzug oder in der Nähe einer Wärmequelle platziert ist — das liefert Klimaautomatisierungen eine repräsentativere Messung.
Gewichtete Fusion und Robustheit
Wenn einfache UND/ODER-Regeln nicht reichen, gewichtet der Bayes’sche Binärsensor von Home Assistant Sensoren probabilistisch: Jede Beobachtung verschiebt eine Wahrscheinlichkeit nach oben oder unten, und der Sensor schaltet ein, sobald sie einen Schwellenwert überschreitet.
- Bayes’scher Binärsensor: Du legst einen Prior (die Basiswahrscheinlichkeit) fest und gibst jeder Beobachtung (Zustand, Zahlenbereich oder Template) ein prob_given_true und ein prob_given_false. Der Sensor schaltet ein, wenn die resultierende Wahrscheinlichkeit probability_threshold (Standard 0,5) übersteigt. Einrichtung in der UI (Prozent) oder in YAML (Werte von 0 bis 1).
- Nimm feste Template-Logik, wenn die Regel in einen Satz passt (Radar ODER kürzlicher PIR-Trigger). Nimm den Bayes’schen Sensor, wenn mehrere unvollkommene Signale — Radar, PIR, ein Lichtschalter, die Anwesenheit eines Telefons — jeweils Teilbeweise liefern. Die Wahrscheinlichkeiten schätzt du selbst, also einfach starten und nachjustieren.
- Füge dem fusionierten Template-Binärsensor eine Abschaltverzögerung (delay off) hinzu, damit kurze Lücken zwischen Sensormeldungen einen Raum nicht auf „unbelegt“ kippen. Template-Binärsensoren unterstützen delay_on und delay_off in YAML und unter „Zusätzliche Optionen“ im UI-Helfer.
- Gehe bewusst mit ausgefallenen Eingängen um: Eine Template-Entität ist immer verfügbar, solange du kein Availability-Template konfigurierst — ein offline gegangener Quellsensor besteht also einfach seinen „an“-Test nicht. Prüfe die Verfügbarkeit der Quellen im Template, wenn ein fehlender Eingang nicht als „keine Aktivität“ gelesen werden darf.
- Für die Umgebungsfusion kombiniert der Min/Max-Helfer zwei oder mehr Sensoren mit gleicher Einheit zu Mittelwert, Median, Minimum oder Maximum (UI-Helfer oder YAML).
Häufig gestellte Fragen
Brauche ich spezielle Hardware für Sensorfusion?
Nein — es ist ein Automatisierungslogik-Muster, das mit Standard-Home-Assistant-Template-Sensoren und Multi-Condition-Triggern umgesetzt wird und die Sensoren kombiniert, die du bereits besitzt.
Was ist das einfachste Sensorfusions-Beispiel zum Einstieg?
Die Kombination eines Radar-Anwesenheitssensors mit einem PIR-Bewegungssensor für die Anwesenheitserkennung ist ein häufiger Einstiegspunkt — sie adressiert direkt die Einschränkung von PIR, „hört auf, eine still sitzende Person zu erkennen".
Erhöht Sensorfusion die Automatisierungskomplexität spürbar?
Etwas — du schreibst einen Template-Sensor mit kombinierter Logik, statt eine Automatisierung direkt auf einen Sensor zu richten. Das ist ein überschaubarer Trade-off für spürbar weniger Fehlauslösungen bei Automatisierungen, die wichtig sind (wie Sicherheitsbenachrichtigungen).
Kann ich die Logik eines lokalen LLM mit Sensordaten fusionieren?
Ja — sobald fusionierte Sensordaten als Standard-Home-Assistant-Entität verfügbar sind, kann eine LLM-Automatisierung (siehe den Leitfaden zu KI-Automatisierungen) genauso darüber schlussfolgern wie über jeden anderen Sensor und potenziell weitere kontextbewusste Logik hinzufügen.
Ist das dasselbe wie ein digitaler Zwilling des Zuhauses?
Verwandt, aber enger gefasst — Sensorfusion kombiniert wenige Sensoren für eine spezifische Automatisierungsentscheidung. Ein digitaler Zwilling (siehe diesen Leitfaden) ist ein breiteres, fortlaufendes Modell des gesamten Zustands des Hauses, aus dem viele Automatisierungen schöpfen könnten.
Wann sollte ich den Bayes’schen Sensor statt eines Template-Sensors nutzen?
Nutze einen Template-Sensor, wenn eine einfache UND/ODER-Regel die Logik abdeckt. Nutze den Bayes’schen Binärsensor, wenn mehrere unvollkommene Signale jeweils Teilbeweise liefern und nach Zuverlässigkeit gewichtet werden sollen — er braucht einen Prior und Wahrscheinlichkeiten je Beobachtung, die du selbst schätzt.
Was passiert mit einem fusionierten Sensor, wenn ein Eingangssensor offline geht?
Standardmäßig bleibt ein Template-Sensor verfügbar, und ein ausgefallener Eingang erfüllt seine Bedingung einfach nicht — das fusionierte Ergebnis kann also ohne Warnung falsch sein. Füge ein Availability-Template hinzu oder prüfe die Eingangszustände, wenn dem Ergebnis bei fehlendem Eingang nicht vertraut werden darf.