BMS and Smart Building IoT in Malaysia: Where Aqara Ends, Omaya Begins

Answer up front — Aqara is room-level and Omaya is site-level, and the two are not competitors. An Aqara presence sensor answers "is anyone in this room right now" — one space, one device, a binary state. Omaya answers "how is this building being used, who is in it, and what needs attention" — people, devices, environment and space across a whole site, aggregated into reports, alerts and workflows. Neither replaces the other, and a building does not need two hundred room sensors to know it is empty after hours; it needs a handful of good signals and a system that aggregates them. We do not publish prices, licence fees or payback figures for Omaya, because they depend on a site survey.

This is the strategic post. If you are a building owner, a facilities director or a developer evaluating smart building systems in Malaysia, the most useful thing we can do is tell you where each layer genuinely ends.

Two different jobs

Most confusion in this market comes from treating "smart building" as one product category. It is not. It is at least two layers doing genuinely different work.

One line captures the difference: a room sensor is an input; a site platform is the thing that makes an input useful.

What a BMS actually has to answer

If your brief is "we want a building management system", the requirements underneath are usually four questions:

1. How is this building being used? Which floors, which rooms, which hours.
2. Who is in it? Staff, contractors, visitors — and where.
3. What needs attention? Not what is normal — what is abnormal.
4. What is the evidence? When a question is asked in three months, what can you show.

Sensors answer none of these on their own. They produce the raw signals; answering the four questions requires a layer that holds the streams, correlates them, applies thresholds, keeps history and produces output someone can act on.

Omaya: the four streams

Omaya is Synchroweb's own platform, not an Aqara product. Its own description is that it "turns the people, devices, environment and space inside your site into one live picture." Four streams, and each one maps to one of the questions above.

People. Real-time tracking of people and assets, with the ability to replay the last hour, day or month. This is what turns a set of binary door events into an operating picture.

Devices. A device inventory showing health, firmware, last-seen, battery and location — "twelve gateway vendors, one screen." That last phrase matters more than it sounds: most building operators run a mixed estate, and the alternative to one screen is a spreadsheet and four vendor portals.

Environment. Temperature, humidity, noise and air quality, with threshold alerts and what Omaya describes as "evidence-ready logs." In a tropical building with condensation and air quality complaints, a monitored threshold with a retrievable history is the difference between an argument and a record.

Space. Space utilisation heatmaps, dwell time, traffic patterns, peak hours and underused rooms. This is the commercial output — the reason the other three streams exist.

The operational workflows

Beyond reporting, Omaya ships the workflows that building operations teams actually run on. These are the security and safety functions, and they are the clearest example of work that needs a site rather than a room:

Each of these assumes you know where people are across a site. That is the structural argument: after-hours intrusion and lone-worker safety are not room problems. They only become tractable when you have a view of the whole building.

Reporting, automation and visitors

Twenty-eight built-in report types are included. For an operator asked to justify a system to a management committee, the report is usually the product — not the sensor.

"If this, then that" automation handles the recurring rules: if the space is occupied and the temperature crosses a threshold, do this; if the floor is empty after a certain hour, escalate that. The value is not that the logic is sophisticated; it is that the trigger is a real occupancy state rather than a clock.

The Visitor Management System covers automated registration, geofencing and a blacklist — pre-registration, arrival routing and a record of who was expected, which is a genuinely harder problem in a Malaysian office tower than in a single-tenant building.

For energy and sustainability reporting specifically, see energy metering and ESG reporting for Malaysian buildings.

The boundary — and why it is commercially important

Here is the honest part, and it is the reason this post exists.

Neither platform replaces the other. A building operator who installs Aqara devices everywhere and expects a BMS view will be disappointed: they will have excellent signals in rooms and no site picture. An operator who buys a site platform and skips the devices will have a dashboard with nothing to display.

The practical consequence, stated plainly:

A building does not need two hundred room sensors to know it is empty after hours. It needs a handful of good signals and a system that aggregates them.

A small number of well-placed presence sensors covering the spaces that actually consume energy, plus access events, plus environment monitoring, plus a platform that aggregates and reports, answers the after-hours question for a fraction of the cost and a fraction of the maintenance of per-room instrumentation. Per-room density is a design failure, not a feature.

This boundary also decides procurement. If a supplier is selling you a per-room sensor for every desk in a twelve-floor building, ask what the site-level architecture is and who operates it after go-live. Our post on rolling out smart devices at scale covers the deployment question, and building a smart building business case covers the commercial one.

Ecosystem and integration

Omaya is deployed across 8 industries, in five languages, on one platform — industries listed include manufacturing and warehouse, smart building and workspace. That is Synchroweb's published claim on its own platform pages, offered as context on how it is used rather than as a performance figure.

Integrations include Dusun IoT access points and Mokosmart / Minew IoT sensors. In practice this matters for one reason: a site operator is rarely starting with nothing, and rarely wants to rip out what is already there. Access control, gateways and sensors that are already commissioned stay in service and report into the same picture. Our post on choosing a deployment model for spatial intelligence covers where the data sits and who operates it.

What to ask in a project meeting

If you are evaluating this, these are the questions that separate a credible answer from a brochure:

• Which layer are you selling — devices, or aggregation? Both are legitimate. Know which one you are buying.
• How many devices does this actually need for the requirement, and why that number? If the answer is one per desk, ask what the site-level architecture is.
• Who operates the platform after go-live, and what happens when the person who set it up leaves? This is the real failure mode in Malaysian building projects.
• What is retained, for how long, and who can see it? Occupancy data about named staff has PDPA consequences — see SIRIM, Suruhanjaya Tenaga and PDPA compliance.
• How do you evidence an after-hours intrusion six months later? A dashboard is not a record.
• What happens when a gateway vendor changes or a device goes unpatched? The "twelve gateway vendors on one screen" promise is only worth what the device-health view does when something fails.
• Which existing systems stay in service? Access control, BMS, fire, lifts. Integration is where building projects go wrong.

What this page does not claim

• It does not state a price, a licence fee, a maintenance cost or a payback period for Omaya. Those depend on a site survey of your building, your floor area and your device estate.
• It does not state a customer count, a deployment count or a named reference. Synchroweb's published deployment figures are theirs to state, not ours to extrapolate from.
• It does not describe a case study. We have not invented one.
• It does not claim Omaya is a certified building automation standard, a replacement for your BMS contractor, or a compliance certificate. It is an operational visibility and workflow layer.
• It does not claim Aqara devices are obsolete because Omaya exists, or the reverse. They do different jobs.
• It does not claim any device reduces energy by a particular amount. Build that against your own occupancy profile.