Home / Blog / Commercial & property
Commercial & property

Aqara Presence vs Omaya Occupancy: Room-Level or Site-Level?

View through a half-open light-oak office door into a small open-plan workspace — a small white round presence sensor mounted flush on the wall in the sharp foreground beside the door, rows of white desks with black monitors and mesh-back chairs beyond in soft focus, warm afternoon light falling through tall multi-pane windows on the right — the composition puts the room-level device in the foreground and the whole floor behind it, which is the comparison this post is about

Answer up front — Aqara presence sensors are room-level, inexpensive, local, and answer one question well: is someone in this room right now. Omaya is site-level, more expensive, and answers a different set — how the whole site is being used, who is in it, which devices are unhealthy and what needs attention. Neither replaces the other. A building does not need two hundred room sensors to know it is empty after hours; it needs a handful, and something that aggregates them.

Most occupancy arguments are really arguments about scope. Someone hears "presence sensing" and assumes a people counter; someone else hears "occupancy analytics" and assumes a surveillance system. Both assumptions are wrong, and they cost money when they reach a tender document.

There are two genuinely different tools here. They operate at different scales, and the useful sentence is short: Aqara is room-level, Omaya is site-level.

The comparison, in one table

Aqara presence sensingOmaya (site-level platform)
Unit of measurementOne room, or one defined zone inside a roomThe whole site — a floor, a building, a group of buildings
The question it answersIs anyone here right nowHow is this site being used, who is in it, and what needs attention
Cost shapeDevice-level and lowPlatform-level and higher
Data pathLocal — automations keep running on the hub or over local Wi-FiAggregated into a site view across gateways
Breadth of dataPresence, and on some devices light, temperature and humidityFour streams: People, Devices, Environment, Space
When a device diesYou find out when somebody says soDevice inventory showing health, firmware, last-seen, battery and location
ReportingRules, scenes and automationsDwell time, traffic patterns, peak hours and underused rooms; described as twenty-eight built-in report types
Vendor spreadOne ecosystemDescribed as twelve gateway vendors on one screen
Works when the internet dropsLocal automation continuesDepends on the gateway and the connection — ask us rather than assume

Read the "when a device dies" row twice. It decides whether a presence sensor deployment is an operating detail or an ongoing expense.

What an Aqara presence sensor is genuinely good at

It answers one question well, locally and cheaply: is there a person in this space at this moment. Because the answer stays on the hub or the local network, it is also the version that keeps working when the fibre drops, and the version that raises the fewest questions about data leaving the building.

The devices differ in ways that matter to that question, and none of them is interchangeable:

  • FP2 — 60 GHz mmWave, up to 40 m², up to 5 people, IPX5. Wi-Fi 2.4 GHz and Bluetooth only — no Zigbee and no Thread — and no Aqara hub required. Zone positioning and multi-person detection require wall mounting. Fall detection requires a ceiling mount and disables most features, including zone positioning and presence detection.
  • FP1E — 60–61 GHz with a 360° rotating head, distinguishing moving from still plus duration. Zigbee only, so it needs an Aqara hub. But Aqara's own product page still ships unreplaced "Lorem ipsum" copy, so treat FP1E claims as unconfirmed.
  • FP300 — 5-in-1: PIR, mmWave, light, temperature and humidity, on CR2450 ×2 batteries for up to 3 years on Zigbee or 2 years on Thread. No IP rating. 45° corner mounting recommended.
  • FP400 — up to 10 people, 120° field of view, headcount and ambient light. Side mount 10 m × 8 m, corner 7 × 7 m, ceiling specified for 3–4 m; at 3 m, 5 × 6 m of motion and 4 × 5 m of presence directly below. Thread and Zigbee, IPX5 — and not confirmed as a Malaysian-channel product.

The full comparison, including which can actually be bought in Malaysia, is in our FP2 vs FP1E vs FP300 vs FP400 post.

The honest summary of the room-level side: excellent at occupied or unoccupied, local, cheap, private — and silent about everything else.

What a site-level platform is genuinely good at

The moment the question stops being about one room, the room-level answer stops being useful. "Is Meeting Room 3 occupied" is a device question. "Which of our eleven sites needs attention tonight, and what has been broken since Tuesday" is an operating question, and it is answered on a different layer.

Synchroweb's Omaya platform runs on four streams — People, Devices, Environment and Space — and two of them most often change a budget decision:

  • Devices. An inventory showing health, firmware, last-seen, battery and location, described on the site as "twelve gateway vendors, one screen", with integration for Dusun IoT access points and Mokosmart and Minew sensors — which matters when you have inherited equipment from more than one previous vendor. This is what converts "somebody said the meeting room sensor stopped working" into a named item with a location.
  • Space. Dwell time, traffic patterns, peak hours and underused rooms. This is where an operator gets the answer a room sensor was never going to give: not is this room busy right now, but which rooms are never used, and when are the three that are actually busy.
  • People. Real-time tracking of people and assets, replay of the last hour, day or month, plus security workflows including roll call, lone-worker check-in, panic-button escalation, after-hours intrusion and denied badge.
  • Environment. Temperature, humidity, noise and air quality with threshold alerts and evidence-ready logs.

There is also a Visitor Management System with automated registration, geofencing and a blacklist, and if-this-then-that automation across the whole site rather than within one room. More of this is set out in where Aqara ends and Omaya begins.

Where the two overlap — and where budgets get wasted

They overlap in exactly one place: a room-level sensor is an input to a site-level view. That is the correct relationship, and it is also where the confusion starts — because the input is cheap and the platform is not. It is very easy to buy a hundred room sensors and then discover that nobody can aggregate them, that battery levels are invisible, and that "which sensor is dead" is still a phone call.

The mirror-image mistake is worse: buying a site-level platform and then expecting it to tell you whether Meeting Room 3 is occupied right now, with the reliability and response time of a local device. It is a different instrument. Nobody should ask it to be the other thing.

If the requirement isUse
Turn the lights and aircon off in a room when people leaveAqara room-level presence sensing
Count how often each meeting room is used across a yearSite-level space analytics
Know which of eleven sites needs attention tonightSite-level device inventory
Know whether a specific room is occupied at 3 a.m.A few room sensors plus a site-level view
Prove when a threshold was breached, for an auditSite-level environment logs
Detect a fall in a homeFP2, ceiling-mounted — with the documented feature trade-off

The two-hundred-sensor arithmetic

Here is the argument, stated plainly, because it is the most common specification mistake we see.

A building does not need a room sensor in every room to know it is empty after hours. Occupancy is a sum, and a sum does not need every term. You need enough terms to know the answer is zero — which means circulation points, the main doors, and the spaces that are plausibly still occupied.

Two hundred room sensors would tell you what you already know, more slowly, at a per-device battery maintenance cost, with two hundred opportunities for a device to fail unnoticed. That is a worse system, not a better one.

A workable method:

  1. Write the decisions first. "Do we turn the aircon off at 8 p.m.?" and "Who do we call if a site is still occupied at 11 p.m.?" are different decisions and need different instruments.
  2. Sensors go where the decision is made — the room whose lighting or aircon is being controlled. If nobody makes a decision in a room, a sensor in that room is decoration.
  3. Coverage maths decides how many. Divide the area you need to cover by the realistic coverage for the mounting you can achieve, then check it against mounting height. The FP400's ceiling coverage is specified for 3–4 m and gives 5 × 6 m of motion at 3 m — a 2.7 m suspended ceiling is a different calculation. Aqara's hub capacities are not linear either, so a deployment across several rooms should be counted before it is quoted.
  4. Then decide what aggregates them, and be honest that this is a separate decision with a separate cost. Not aggregating is the failure mode, not under-sensing.

The privacy difference between the two

A room-level sensor answering a local question produces little that leaves the building, and mmWave sensing produces no image and identifies nobody. That is a genuine advantage, and it is why room-level presence sensing is straightforward to justify where privacy matters.

Aggregation is what changes the analysis. Once presence across many rooms is collected, correlated over time and made browsable by an operator, you have moved from a building signal to a behavioural record — and the questions about consent, purpose, retention and access become real questions about identifiable people. That is true whether the aggregation is done by a site-level platform, a spreadsheet, or a well-meaning person with a dashboard.

The distinction to hold onto: a room sensor answers "is this room in use", which is a property of the building. A site-level record of room usage over months is a record about people. Neither is automatically a problem. Both deserve a decision rather than an assumption.

In a healthcare environment this needs care in a specific way, written out in our clinic automation post. In an office it is covered in choosing an occupancy sensor for a Malaysian office floor, including the coverage maths at 2.7 m against a 3.6 m ceiling.

What this page does not claim

  • We do not publish a price or a licence fee for any site-level platform. Ask us directly and we will answer commercially rather than on a web page.
  • We do not claim that room-level sensors are being replaced by site-level platforms. They are not.
  • We do not claim any Aqara presence sensor counts people reliably enough to be a customer counter, or identifies anyone.
  • We do not state your obligations under the Personal Data Protection Act 2010. Those need someone qualified to advise on them.
  • We do not claim the FP400 can be bought in Malaysia. It is not confirmed as a Malaysian-channel product.

Planning a project?

Tell us about your space. Our B2B team will reply within one business day with a recommended setup and quotation.

WhatsApp us →
[email protected]
+603-5880 5486