Home Assistant Occupancy Sensor Automations: Lighting, HVAC, Alerts

It is 18:40, the open-plan floor has six people still working, and the lights in the far bay have just cut out for the third time because nobody walked past a PIR in the last ten minutes. Meanwhile the ventilation on the empty third floor is still running at full airflow because the entity for that zone froze at a count of 8 when the sensor dropped offline at lunch. Both failures have the same root cause: the automations were written around motion events instead of a home assistant occupancy sensor that reports how many people are actually in each zone. This article is a set of concrete recipes for lighting, HVAC and alerting that act on counts, thresholds and durations, written for people who already have occupancy entities in Home Assistant and want them to do useful work.

The Pattern Behind Every Reliable Home Assistant Occupancy Sensor Automation

Every recipe below follows the same four-part shape, and skipping any part is where automations go wrong. First, the trigger is a numeric_state crossing on a per-zone count entity, not a state change on a binary motion sensor. Second, the trigger carries a for: duration so a single person stepping in and out does not flap the output. Third, a condition checks that the count entity is not unavailable or unknown, which only works if the underlying MQTT sensor has a sensible expire_after so a dead sensor stops reporting instead of freezing at its last value. Fourth, the action sets a target state rather than toggling, so repeated triggers are idempotent.

If you are still deciding how to get counts into Home Assistant in the first place, the complete guide to Home Assistant occupancy integration covers sensor types and transport options. Everything here assumes you already have an entity such as sensor.floor2_meetingroom_a_count publishing a reconciled headcount.

Lighting Recipes: Stop Punishing People for Sitting Still

• Zone hold on count, not motion. Trigger when the zone count drops below 1 and stays there for 10 minutes; condition that the entity is available; action sets the light group to a low dim level rather than off. A second automation turns the group fully off after a further 20 minutes at zero. People who are stationary do not register on PIR, but they do register on a people counter that tracked them in and has not tracked them out.
• Count-weighted scene selection. For a large room, map bands to scenes: 1 to 3 people selects task lighting over the occupied end only, 4 and above selects the full scene. Use one automation with a choose block keyed on the count, triggered on any change but with a 2-minute for: on each threshold to avoid scene thrashing while people file in.
• Fused wake-up signal. Keep a cheap PIR or mmWave sensor as the instant trigger to bring lights on at entry, but hand the turn-off decision to the count. The fast sensor solves latency; the count solves the false-off problem. Never let the fast sensor switch anything off on its own.

One rule to apply to all of these: in high-traffic zones such as corridors and lobbies, do not switch anything on single-person entry or exit. The constant switching irritates occupants and wears equipment. Debounce every lighting action with a duration condition.

HVAC and Ventilation Recipes: Air for the People Who Are There

This is where occupancy-driven home assistant automation earns its payback, because always-on ventilation in half-empty buildings is pure waste. The recipe is a banded controller rather than an on/off switch:

• Band 0: count at zero for 15 minutes moves the zone to setback, meaning minimum fan speed or damper position and a relaxed temperature setpoint.
• Band 1: one to four people for 3 minutes selects stage-one airflow and the normal setpoint.
• Band 2: count above your room-specific threshold for 3 minutes selects full airflow. Set the threshold from the room's design occupancy, not a guess.

Implement this as one automation with a choose block and three numeric-state triggers, each writing to an input_select that represents the current band. A separate automation translates band changes into fan, damper or climate entity calls. Separating the decision from the actuation lets you swap the HVAC integration later without touching the occupancy logic, and it gives you a history graph of band transitions to tune the thresholds against.

A useful companion recipe is calendar pre-conditioning: trigger 20 minutes before a booked meeting start, condition on the booking's attendee count, and bring the room to Band 1 or Band 2 in advance. Then let the live count take over once people arrive. If the count is still zero 10 minutes after the start, the ghost-meeting recipe below takes the room back.

Alert Recipes: Capacity, After-Hours and Ghost Meetings

• Capacity limit. Numeric-state trigger above the zone's predefined limit with a 1-minute for:, action pushes a notification to a facilities group and sets a flag entity that a wall panel or signage integration can display. Add a second trigger below the limit minus a margin of two or three people to clear the flag, so it does not oscillate at exactly the threshold.
• After-hours anomaly. Trigger when a secured zone's count rises above zero, condition on a schedule helper being off, action runs a security scene: cameras to record, notification with zone name and count. This is the one place an event-driven webhook from the counting platform beats polling, because latency matters.
• Ghost-meeting release. Trigger 10 minutes after a calendar event starts, condition on the room count being zero for the whole 10 minutes, action releases the booking and returns the room to Band 0. Offices that run this regularly recover 15 to 25 percent of room inventory.
• Stale sensor. Trigger when any count entity goes unavailable for 5 minutes, action notifies the integrator. Without this, your first warning of a dead sensor is an HVAC bill.

Two Guardrails That Keep the Recipes Honest

First, staff pollute counts. A cleaner on a vacant floor at 21:00 fires the after-hours scene, holds ventilation at Band 1 and wrecks the utilisation data. You can suppress by schedule, cross-reference badge data, or use sensors with built-in staff exclusion, which Vemco's AI sensors support natively. Decide before go-live; retrofitting exclusion into a month of automations is miserable.

Second, counts drift. Even at the 98 to 99 percent accuracy a well-sited sensor typically reaches, and with a contractual minimum of 96 percent, small errors compound over a day. Schedule a nightly reconciliation when the building is verifiably empty, either by resetting zone counts in Home Assistant or by letting an upstream platform such as VemFusion hand you an already-reconciled number. Keep the long-term utilisation analysis in a tool built for it, such as VemSpace, and let Home Assistant do what it does best: minute-to-minute control.

Frequently Asked Questions

How long should the duration conditions be? Start with 2 to 3 minutes for anything that turns equipment up and 10 to 15 minutes for anything that turns it down. Then review the band-transition history after two weeks and lengthen whichever thresholds are flapping most.

Can I run these recipes with mmWave or PIR instead of a people counter? Lighting hold and wake-up work with presence sensors, but every banded or capacity recipe needs a count. Presence tells you someone is there; it cannot tell you whether that is two people or twenty.

Should Home Assistant compute the count from in/out events or receive it ready-made? Receive it ready-made wherever you can. Computing it yourself means owning drift correction, midnight resets and staff exclusion, and in mixed estates it risks Home Assistant and the BMS disagreeing about how many people are in the building.

If you want these recipes running on counts you can trust, Vemco's team has integrated people counting into offices, universities and public buildings since 2005 and can scope sensor placement, staff exclusion and the data feeds your automations depend on. Contact Vemco Group to discuss your occupancy automation project.