Der komplette Leitfaden zur Home Assistant Occupancy-Integration

Jeder, der schon einmal einen Besprechungsraum mit PIR-Sensoren automatisiert hat, kennt die Szene: Vier Personen sitzen still in einem Workshop, nach zwölf Minuten geht das Licht aus, die Lüftung fährt herunter, jemand wedelt mit den Armen. Genau an diesem Punkt scheitern die meisten ersten Versuche einer Home Assistant Occupancy Integration – nicht an der Plattform, sondern an der Sensorwahl und an einer Automationslogik, die Bewegung mit Anwesenheit verwechselt.

Dieser Leitfaden richtet sich an Teams, die über den Proof-of-Concept hinaus wollen: Integratoren, Facility Manager und Entwickler, die Belegungsdaten nicht nur anzeigen, sondern damit HLK, Beleuchtung und Sicherheitsprozesse steuern möchten. Wir gehen die drei Entscheidungen durch, die über Erfolg oder Frust entscheiden: Sensorik, Datenarchitektur und Automationsdesign.

Entscheidung 1: Bewegung, Präsenz oder Zählung?

Home Assistant behandelt Belegung standardmäßig als binären Zustand – ein binary_sensor mit der Device Class occupancy. Das reicht für einen Flur, aber nicht für ein Gebäude. In der Praxis gibt es drei Ebenen, und jede erfordert andere Hardware:

• Bewegungserkennung (PIR): günstig, schnell, aber blind für ruhende Personen. Geeignet für Durchgangszonen, ungeeignet für Arbeitsplätze und Besprechungsräume.
• Präsenzerkennung (mmWave-Radar): erkennt auch sitzende Personen über Mikrobewegungen wie Atmung. Der aktuelle Standard für raumgenaue Automation in Home Assistant, meist per Zigbee oder ESPHome eingebunden.
• Personenzählung (KI-Sensorik): liefert konkrete Zahlen statt ja/nein. Erst damit werden Automationen wie bedarfsgeführte Lüftung nach Personenzahl oder Alarme bei Erreichen einer definierten Kapazitätsgrenze überhaupt möglich.

Die häufigste Fehlplanung: Man versucht, mit binärer Präsenz Probleme zu lösen, die Zähldaten erfordern. Ob ein Großraumbüro von 3 oder 60 Personen genutzt wird, ist für die HLK-Steuerung der entscheidende Unterschied – ein Präsenzsensor meldet in beiden Fällen schlicht „belegt".

Entscheidung 2: Wie kommen die Daten in Home Assistant?

Für gewerbliche Projekte hat sich MQTT als Rückgrat durchgesetzt, und zwar aus einem Grund, der in Heimprojekten selten auffällt: Zustandserhalt. Wenn Home Assistant neu startet – bei Updates unvermeidlich –, verlieren viele Integrationen ihren Zustand. Ein Belegungszähler, der nach dem Neustart auf null steht, obwohl 40 Personen im Gebäude sind, löst falsche Automationen aus. Mit retained MQTT-Messages publiziert die Sensorik oder das Zählsystem den letzten bekannten Wert, und Home Assistant liest ihn beim Start sofort ein.

Bewährte Architektur für Gebäude mit mehr als einer Handvoll Zonen:

• Ein Topic-Schema pro Zone, z. B. gebaeude/etage2/raum204/belegung, mit Personenzahl als Payload – nicht nur ein globaler Wert.
• Ein sensor-Entity je Zone (Zählwert) plus abgeleitete binary_sensor-Templates für belegt/frei, damit einfache Automationen einfach bleiben.
• REST- oder Webhook-Anbindung nur dort, wo das Quellsystem kein MQTT spricht – etwa wenn eine professionelle Zählplattform Daten per API bereitstellt.
• Ereignisse (Eintritt, Austritt, Grenzwert erreicht) getrennt von Zuständen publizieren. Automationen auf Ereignisse reagieren schneller und sauberer als auf Zustandsvergleiche.

Wer Belegungsdaten aus einer professionellen Zählinfrastruktur bezieht, kann Home Assistant als flexible Automationsschicht darüberlegen. Systeme wie VemFusion verbinden Belegungsdaten ohnehin bereits mit HLK, BMS und Sicherheitstechnik – Home Assistant übernimmt dann die Rolle des schnellen Prototyping- und Ergänzungswerkzeugs für Anwendungsfälle, die das BMS nicht abdeckt, etwa raumindividuelle Beleuchtungsszenen oder Benachrichtigungen an das Facility-Team.

Entscheidung 3: Automationslogik, die nicht nervt

Die Automation selbst ist der Teil, den Teams am meisten unterschätzen. Drei Muster haben sich bewährt:

• Asymmetrische Verzögerungen: Beim Betreten sofort reagieren, beim Verlassen mit Hysterese. Licht an in unter einer Sekunde, Licht aus erst nach fünf bis zehn Minuten bestätigter Abwesenheit. Bei HLK sind längere Nachlaufzeiten sinnvoll, weil Anfahren teurer ist als Weiterlaufen.
• Schwellenwert-Automationen statt Binärlogik: Lüftungsstufe 1 ab einer Person, Stufe 2 ab zehn, Stufe 3 ab zwanzig. Und ein Alarm, wenn eine vordefinierte Kapazitätsgrenze erreicht wird – für Brandschutz-Auflagen oder Raumkomfort gleichermaßen relevant.
• Zeitfenster als zweite Bedingung: Belegung außerhalb der Betriebszeiten ist kein Komfort-, sondern ein Sicherheitsereignis. Dieselben Daten, andere Automation: Benachrichtigung an den Sicherheitsdienst statt Licht und Lüftung.

Eine Beobachtung aus realen Installationen, die in kaum einer Anleitung steht: mmWave-Sensoren erkennen alles, was sich rhythmisch bewegt – Deckenventilatoren, flatternde Vorhänge vor gekippten Fenstern, in einem dokumentierten Fall sogar eine schwingende Zimmerpflanze über einem Lüftungsauslass. Wer die Erkennungszonen nicht sauber eingrenzt und den Sensor nicht mit Blick auf Luftströmungen positioniert, bekommt Räume, die dauerhaft als belegt gelten. Das Ergebnis ist das Gegenteil des Einsparziels: Die HLK läuft rund um die Uhr, weil der Sensor nie „frei" meldet. Kalibrierung ist keine Fünf-Minuten-Aufgabe, sondern ein Vor-Ort-Termin pro Raum.

Genauigkeit: der Punkt, an dem Hobby und Gewerbe sich trennen

Für die Wohnzimmerbeleuchtung ist ein gelegentlicher Fehlzustand ärgerlich. Wenn dieselben Daten aber die Lüftung eines Hörsaals steuern, Reinigungsrouten priorisieren oder Kapazitätsnachweise liefern, ändern sich die Anforderungen grundlegend. Professionelle KI-Zählsensorik arbeitet mit einer vertraglich zugesicherten Mindestgenauigkeit von 96 %, typischerweise werden 98–99 % erreicht, wenn Beleuchtung, Raumlayout und Bewegungsmuster es zulassen. Ebenso wichtig im Gebäudekontext: die Ausfilterung von Personal. Ein Reinigungsteam, das dreimal täglich durch alle Etagen zieht, verzerrt sonst jede Auslastungsstatistik und triggert unnötige HLK-Zyklen.

Genau hier liegt der sinnvolle Schnitt zwischen Home Assistant und professioneller Zählinfrastruktur: Home Assistant ist hervorragend darin, aus verlässlichen Daten flexible Automationen zu bauen. Es ist nicht dafür gebaut, aus unzuverlässigen Sensoren verlässliche Daten zu machen. Wer die Datenqualität am Anfang der Kette sichert, spart sich Wochen an Template-Sensoren, Bayes-Filtern und Workarounds am Ende der Kette.

Vom Pilotraum zum Gebäude: die realistische Roadmap

Der pragmatische Weg, den erfahrene Integratoren gehen:

• Phase 1: Zwei bis drei repräsentative Räume mit mmWave-Präsenz und einem Zählpunkt ausstatten. Vier Wochen nur Daten sammeln, keine Automationen. Die Baseline zeigt, wie viel Laufzeit von Licht und Lüftung tatsächlich auf leere Räume entfällt.
• Phase 2: Automationen mit konservativen Verzögerungen aktivieren, Beschwerden erfassen, Schwellen nachjustieren. Erst wenn zwei Wochen ohne Nutzerbeschwerden vergehen, gilt die Logik als tragfähig.
• Phase 3: Skalieren – und dabei entscheiden, welche Zonen binäre Präsenz genügt und wo Zähldaten den Mehrwert liefern. Foyer, Kantine und Hörsäle rechtfertigen Zählsensorik fast immer; Kopierräume nicht.

In Büros, Hochschulen und öffentlichen Gebäuden ist der größte Hebel dabei fast immer derselbe: Systeme, die im Dauerbetrieb laufen, obwohl niemand da ist. Belegungsgeführte Steuerung greift genau dort an – und Plattformen wie VemSpace liefern die Auslastungsanalysen, mit denen sich über die Automation hinaus auch Flächenentscheidungen begründen lassen: welche Etagen konsolidiert, welche Räume umgewidmet werden können.

Sie planen eine Belegungsintegration, die über den Pilotraum hinaus tragen soll – mit verlässlichen Zähldaten als Fundament für Home Assistant, BMS oder beides? Sprechen Sie mit unserem Team über Sensorwahl, Datenarchitektur und realistische Genauigkeitserwartungen für Ihr Gebäude: Kontaktieren Sie Vemco Group.