Automation Guide for Home Assistant Occupancy Integration

Most Home Assistant occupancy setups fail for one reason that has nothing to do with the platform: they treat presence and occupancy as the same thing. A PIR motion sensor tells you someone moved. A proper occupancy source tells you how many people are in the space right now. If your automations only know "motion detected in the last five minutes," you cannot pre-condition a meeting room for twelve people, throttle ventilation to actual headcount, or trigger a security workflow when a floor that should be empty is not. This guide covers how to wire genuine occupancy data — counts, not blips — into Home Assistant, and where the real engineering effort sits.

Choose Your Occupancy Source Before You Touch YAML

Home Assistant will happily ingest almost anything, which is exactly why teams end up with unreliable automations. Rank your candidate sources by what they actually measure:

• AI-based people counting sensors at entrances and zone boundaries give you directional in/out counts and a running occupancy figure per zone. This is the only source that supports capacity-based logic, such as alerts at a predefined occupancy limit.
• mmWave radar detects stationary humans (breathing, micro-movement) and solves the classic "lights turn off while someone sits still" problem, but it gives presence, not counts.
• PIR is cheap and fast to trigger, useful only as a wake-up signal or as one input into a fused sensor.
• CO₂ and environmental proxies lag by 10–20 minutes and drift, so use them for validation, never for real-time control.

Accuracy matters more here than in most IoT projects because errors accumulate. A counting sensor that misreads 1 person in 20 will drift a zone's occupancy figure badly within a day. This is why enterprise counting platforms specify accuracy contractually. Vemco, which has been in people counting since 2005, commits to a minimum of 96% accuracy, typically reaching 98–99% where lighting, layout and visitor behaviour allow. If a vendor quotes a flat "99% guaranteed" with no conditions attached, that number was produced in a lab, not a lobby.

Integration Patterns: MQTT First, REST Second, Webhooks for Events

For live occupancy in Home Assistant, MQTT is the pattern that scales. Run Mosquitto as an add-on or an external broker, have your counting layer publish per-zone counts to topics like occupancy/floor2/meetingroom_a/count, and define MQTT sensors with a sensible expire_after so a dead sensor shows as unavailable instead of frozen at its last value. Frozen-at-last-value is the silent killer of occupancy automations — HVAC keeps conditioning a room that emptied hours ago because the entity still reads 8.

REST polling works for slower-moving data: daily footfall, utilisation summaries, capacity ratios pulled from an analytics platform every few minutes via a rest sensor or a scheduled automation calling rest_command. Reserve webhooks for genuine events — a capacity-limit breach, a zone that should be vacant registering people after hours. Home Assistant's webhook triggers make these one-liners, and event-driven beats polling for anything security-related.

One structural decision to make early: whether Home Assistant computes occupancy from raw in/out events, or receives an already-reconciled count. Compute it yourself and you own drift correction, midnight resets, and staff exclusion logic. Platforms like VemFusion, which connects occupancy data to HVAC, BMS and security systems, handle reconciliation upstream and hand you a clean number. In mixed estates — some spaces on a commercial BMS, some on Home Assistant — letting the counting platform be the single source of truth avoids two systems disagreeing about how many people are in the building.

Automations Worth Building (and the Ones That Waste Your Time)

Once per-zone counts exist as entities, the high-value automations follow a pattern: they act on count thresholds and duration, not instantaneous state.

• Demand-based ventilation: map occupancy bands to fan speed or damper position. Zero for 15 minutes → setback. One to four people → stage one. Above a threshold → full airflow. Universities and public buildings run this logic against counting data specifically to cut waste from always-on systems, and it is where the payback lives.
• Capacity alerting: real-time occupancy with an alert at a predefined limit, pushed to a wall panel, a notification group, or a signage integration. Straightforward with a numeric-state trigger and a for: duration to suppress flapping at the threshold.
• Ghost-meeting release: a room booked in the calendar but showing zero occupancy 10 minutes past the start time triggers a release workflow. This one automation regularly recovers 15–25% of room inventory in offices.
• After-hours anomaly: nonzero count in a secured zone outside schedule fires a security scene — cameras to record, notification with zone and count.

Skip the automations that toggle anything on single-person entry/exit events in high-traffic zones. The switching noise annoys occupants and wears equipment. Debounce everything with duration conditions.

The Detail Implementers Learn the Hard Way: Staff Pollute Your Counts

Ask anyone who has commissioned occupancy automation in a working building: the first week of data looks wrong because cleaners, security rounds and facilities staff crisscross zones constantly. A cleaner entering a "vacant" floor at 21:00 triggers your after-hours automation, keeps HVAC alive, and skews utilisation reports. You have three options — schedule-based suppression (fragile), badge-data cross-referencing (integration-heavy), or sensors with built-in staff exclusion, which is why Vemco's AI sensors support it natively. Whichever route you take, decide before go-live, because retrofitting exclusion logic into a month of automations and dashboards is miserable work.

A related field note: always implement a scheduled count reconciliation. Even at 98–99% accuracy, small errors compound, so reset or true-up zone counts nightly when the building is verifiably empty. Every mature deployment does this; almost no tutorial mentions it.

Where Home Assistant Ends and the Analytics Layer Begins

Home Assistant is excellent at real-time control and terrible as a long-term utilisation database. Its recorder was not built for multi-year, multi-building space analysis. The workable architecture keeps roles separate: sensors feed an analytics platform such as VemSpace for space utilisation and facility optimisation — which desks, rooms and floors actually earn their footprint — while the same data streams into Home Assistant for minute-to-minute automation. Facility managers get the strategic view for lease and layout decisions; the automation layer gets clean, current counts. Developers get one API to build against instead of scraping state history.

Ready to feed contractually accurate occupancy data into your Home Assistant or BMS environment? Vemco's team has integrated counting into offices, universities and public buildings since 2005 and can scope the sensor layout, exclusion logic and data feeds for your site. Contact Vemco Group to discuss your occupancy integration project.