Most Home Assistant occupancy setups fail for a reason nobody puts in the tutorials: the sensor tells you motion, not presence, and definitely not how many people. A PIR sensor in a meeting room goes quiet the moment eight people sit still for a video call, and your automation dutifully shuts off the ventilation while the CO2 climbs past 1,200 ppm. If you are building a Home Assistant occupancy integration for a real facility rather than a living room, the architecture decisions you make in the first week determine whether you get usable data or an expensive false-positive machine.
Before touching a YAML file, define the question each zone needs answered. There are three distinct data types, and they need different hardware:
Mixing these up is the most common integration mistake we see. Teams deploy twenty mmWave sensors and then wonder why they can't answer "how many desks were used on Tuesday" — because area presence and headcount are different measurements with different error models.
For anything beyond hobby scale, standardise on MQTT as the transport into Home Assistant. Run Mosquitto as a broker, use MQTT Discovery so entities register themselves, and keep retained messages on for occupancy state topics so a Home Assistant restart doesn't leave zones in unknown state for hours. Professional counting systems typically expose data via API or webhook; a small middleware service (Node-RED or a Python script running as an add-on) that polls the counting API and republishes to MQTT gives you one consistent entity model regardless of vendor.
Structure your topics by building semantics, not by device: building/floor2/zone-a/count beats sensor/ld2410-0043/state every time. In eighteen months, when someone replaces the hardware, your automations survive.
Beam-break counters and ESP32-based solutions drift. Two people walking abreast register as one; a cleaning trolley registers as a person; and cumulative counts diverge from reality within days. That is tolerable for a single office door. It is not tolerable when the count drives HVAC setpoints across a university campus or triggers a capacity alert in a public building.
This is the point where teams bring in dedicated platforms. Vemco Group has been doing people counting since 2005, and their AI sensor approach addresses exactly the failure modes that kill DIY counts: a contractual minimum of 96% accuracy, typically reaching 98–99% when conditions such as lighting, layout and visitor behaviour allow — and, critically, staff exclusion, so your occupancy figures aren't inflated by the same facilities technician crossing a threshold forty times a day. Their VemFusion product connects occupancy data directly to HVAC, BMS and security systems, which matters if Home Assistant is one consumer of the data rather than the only one. VemSpace covers the space utilisation side — which rooms are actually used, and how often — which is the dataset your workplace strategy team will eventually ask you for anyway.
The practical pattern for integrators: let the professional platform own counting and accuracy, and let Home Assistant own automation logic and cross-system orchestration. Pull the counts in over API-to-MQTT and treat them as trusted upstream data.
Raw occupancy state is too noisy to drive equipment directly. Three patterns that hold up in production:
Here is something you learn only after running counts in production: even good counters accumulate small errors, and a zone that shows three occupants at 2 a.m. is almost always drift, not intruders. Schedule a nightly reset-to-zero automation for each zone, conditioned on the building's security state, and log the pre-reset value. That pre-reset residual is your best ongoing accuracy metric — if it grows week over week, a sensor's field of view has changed, usually because someone moved furniture, installed signage, or repositioned a light fixture under it. Nobody tells facilities about these changes; the residual log tells you.
The economics of this integration live in the gap between scheduled operation and actual occupancy. Offices, universities and public buildings routinely run HVAC and lighting on timetables that assume full occupancy from 7 a.m. to 7 p.m., while real usage is patchy and shifting. Occupancy-driven control through Home Assistant — fed by counts you can actually trust — closes that gap zone by zone. Start with your highest-consumption zones, prove the delta with before/after energy data from the same season, and expand from there. The energy team will fund phase two once they see phase one's numbers.
One warning for developers: keep occupancy history out of your default recorder retention if you're logging per-second mmWave states. Route high-frequency raw data to InfluxDB or a long-term statistics setup and keep the Home Assistant database lean, or your SD card and your dashboards will both suffer.
If you're planning a Home Assistant occupancy integration and need counting data accurate enough to drive HVAC, BMS and capacity alerts with confidence, talk to the Vemco Group team about VemFusion and VemSpace for your building at vemcogroup.com/contact-us — bring your floor plans and your automation goals, and they'll help you scope the sensor layout properly from day one.