Use Cases for MQTT Occupancy Automation

Most occupancy projects fail at the same point: the data exists, but it arrives too late or in the wrong shape to trigger anything. A REST API polled every five minutes cannot release a meeting room that emptied ninety seconds ago, and a proprietary sensor protocol locks you into one vendor's dashboard. This is exactly the gap MQTT occupancy automation closes. A counting sensor publishes an event the moment someone crosses a line; the broker fans it out to HVAC logic, lighting scenes, cleaning schedules and safety dashboards simultaneously, each subscriber acting on its own terms. The publish-subscribe model matters more than most spec sheets admit, because it decouples the sensor layer from every downstream decision.

Demand-Controlled Ventilation That Reacts in Seconds, Not Cycles

CO2-based demand control is the default in most buildings, but CO2 lags occupancy by ten to twenty minutes. By the time the sensor reads high, forty people have already been sitting in stale air. When a people counter publishes zone occupancy to a topic like building/floor3/zoneB/occupancy, a subscriber on the BMS side — often bridged through Node-RED or a BACnet/MQTT gateway — can pre-stage air handling the moment a conference block fills. The reverse case saves the real money: when occupancy drops to zero and stays there for a configurable window, ventilation ramps down without waiting for CO2 decay. Integrators typically publish both a raw count and a derived state (empty, low, normal, near-capacity) so the BMS logic stays simple and the thresholds live in one place.

Meeting Room Release and Desk Utilisation

Ghost bookings are the quiet tax on every corporate real-estate budget. An MQTT-connected counter at the room threshold publishes an occupied/vacant state; a small service subscribes and cross-references the booking calendar. If a room booked for ten shows zero entries fifteen minutes past the start, the booking auto-releases and the room returns to the pool. The same feed drives utilisation reporting — not badge data, which counts people who entered the building, but actual bodies in actual rooms. Facility teams use six months of this data to justify (or kill) fit-out decisions with numbers instead of anecdotes.

Occupancy-Triggered Cleaning and Consumables

Fixed cleaning rotas clean empty washrooms and skip busy ones. With cumulative counts published per washroom entrance, a facilities app subscribes and dispatches cleaning when a zone crosses, say, 80 visits since last service — resetting the counter via a retained command topic when the cleaner checks in. Sites running this pattern typically shift from time-based to usage-based servicing across washrooms, kitchens and touchdown areas, and the same counts feed consumables forecasting. It is unglamorous, and it is one of the fastest payback use cases in the entire category.

Live Capacity Limits and Life-Safety Dashboards

Fire-code occupancy limits, event venues, gyms and canteens all need a live number, not yesterday's average. Bidirectional counters at every entrance publish in/out events; a lightweight aggregation service maintains the net figure and publishes it as a retained message, so any new subscriber — a lobby display, a security tablet, a turnstile controller — gets the current state instantly on connect. When the count approaches the limit, the same topic can gate entry signage or hold a door. Accuracy is non-negotiable here, which is why contractual guarantees matter: Vemco Group commits to a 96% minimum counting accuracy, with 98–99% typical in practice when lighting, layout and visitor behaviour allow. That distinction between guaranteed and typical is worth writing into your own SLAs downstream.

Lighting, Signage and After-Hours Logic

PIR sensors tell you motion happened; counters tell you how many people remain. That difference lets lighting hold full scenes while a zone is occupied and step down only when the count genuinely reaches zero — no more lights dropping on the one person sitting still. After hours, a non-zero count in a supposedly empty wing becomes a security event published to the alarm integration. Digital signage subscribes to the same feed and switches content by crowd size: wayfinding when busy, promotions when quiet.

What Implementers Learn the Hard Way

A field note that rarely makes it into vendor documentation: in/out counters drift. Each direction carries a small independent error, so a net occupancy figure computed from raw events will slowly diverge from reality over a long day — a location can show minus four people at midnight. Every serious deployment schedules a nightly reset to zero (or a reconciliation against a known-empty state) and treats intraday figures as operationally accurate rather than forensically exact. Plan for it in your automation logic from day one, or you will retrofit it after the first awkward dashboard screenshot.

Other decisions that separate clean deployments from messy ones:

• QoS choice: QoS 1 for count events (a lost message means a lost person forever), QoS 0 acceptable for high-frequency state heartbeats.
• Retained messages for current state topics, never for event streams — new subscribers need the latest count, not a replay.
• Last Will and Testament on every sensor connection, so the broker publishes an offline flag the instant a device drops, and your automation fails safe instead of silent.
• Topic hierarchy agreed before hardware ships: site/building/floor/zone/metric. Renaming topics after twelve subscribers depend on them is a week of coordination nobody budgets for.
• TLS on port 8883 and per-device credentials with topic-level ACLs, not a shared account across the fleet.

Privacy Is the Architecture, Not an Afterthought

Occupancy data feels harmless until a works council or DPO asks what exactly the sensor captures. The defensible answer is aggregate counts with no personal identification and staff traffic excluded from the figures — which is how Vemco Group has approached GDPR-compliant people counting since 2005, now across 2000+ customers in 95+ countries, with hosted or private cloud deployment so the data pipeline fits the customer's IT and residency requirements rather than the other way around. For integrators, this matters practically: an MQTT payload containing only {"in": 3, "out": 1, "ts": ...} sails through a privacy review that a camera stream never would. Before you commit compliance language to a proposal, verify the specifics — certifications, retention periods, data residency — directly with your platform provider rather than assuming them.

Where to Start

Pick one zone, one broker, one subscriber. A single conference floor with counter-driven room release proves the topic design, the QoS strategy and the reset logic before you scale to forty zones and six consuming systems. The pattern is the product: once occupancy flows as clean MQTT events, each new use case is a subscriber, not a project.

If you are scoping an MQTT occupancy automation deployment — whether it is demand-controlled ventilation, capacity management or a full smart-building rollout — talk to the team at Vemco Group about sensor accuracy guarantees, payload formats and integration with your existing broker and BMS stack. Get in touch here and bring your topic hierarchy questions with you.