Smart Building Bulk Device Deployment in Malaysia: A Rollout That Works

Answer up front — Provisioning twenty devices and provisioning two thousand are different jobs, and the difference is inventory, network planning and who holds the knowledge afterwards. Pilot one floor before you commit the building, hold an asset record per device, treat firmware as a scheduled operation rather than a surprise, and write the handover before the integrator's invoice is due. The question to ask is simple: when the integrator leaves, who can service this?

Pilot a floor, not a demo

A working demo tells you the product works. It tells you nothing about whether it can be deployed to four hundred spaces in a building that is still occupied, over eight weeks, without a single incident. A pilot tells you the operational things:

• Whether your installers can repeat the same work twice with the same result
• Whether the design survives being copied to a space that is not identical
• Whether your facilities team can reset a scene, replace a failed device and update the asset record
• How long a real floor takes, including the parts that are not devices — chasing, back box work, testing, snagging
• What breaks when the occupants are not the people who commissioned it

Pilot one floor or one wing, chosen for representativeness rather than prestige. A typical open-plan floor tells you about typical open-plan floors; a flagship lobby with a feature ceiling tells you about flagship lobbies, which is one room. Run the pilot long enough to see a maintenance cycle, not just an install — a device up for six weeks that has not yet needed a battery or a re-pair has not been tested.

Twenty devices versus two thousand

The jump is not linear, and the things that break are structural rather than technical.

Aqara is Zigbee-first, and a hub controls up to 128 related devices. That number is the planning constraint that matters most: it is a ceiling, and a design that puts a floor's worth of devices on a single hub is a design that has planned for the best case and not the failure case. Plan hub distribution by floor and by riser, and decide before the first hub is mounted where the main equipment room is and how the hubs talk to each other.

The AqaraLink Industry Application Platform is built for this shape of work — batch device onboarding, space design, scene configuration, technical operations and monitoring, for real estate, buildings, hotels, campus and senior care. The honest way to describe what that buys you is not speed. It is repeatability: the difference between a rollout that depends on one senior installer remembering how it was done and a rollout where the method is the same on floor three as on floor thirty.

We are not going to quote you a throughput number — devices per day, or devices per project. We do not have a verified figure for your building, and a number from a different building is worse than no number.

The asset record is the deliverable

A device that is not in a record does not exist. When it fails in three years, there is no location, no model, no purchase date, no warranty status and no idea which scene it was part of. Minimum fields per device — this is not an over-specification:

• Unique asset ID, following your own naming convention
• Physical location — building, floor, room or zone, and a position if it matters
• Model and quantity per location
• Install date and installer
• Which hub it belongs to, and which scene or automation references it
• Purchase date and warranty position
• Whether it is landlord or tenant asset
• Last firmware version and last seen date

Two fields do the real work. "Last seen" turns a silent failure from a complaint into a work order. And "which scene references it" stops a replacement device coming back online and quietly running an automation nobody wants at 2am.

The last two fields on that list are the handover items. If your team cannot answer "what is the last firmware version of device X" and "is X still referenced by an automation", you do not own the system — you rent access to it from whoever does.

Turnover: the process nobody has written

Every building changes hands. Fit-outs come out, offices move, tenancies end, a sensor gets knocked by a trolley and is never replaced. Without a process, you accumulate orphan devices that still report, still trigger scenes, and no longer correspond to anything in the building. A workable turnover process, in four steps:

1. Trigger — a fit-out removal, a tenancy end, a reported fault, a refurbishment scope. Any of these starts it.
2. Identify — what is in the space now versus what the asset record says should be there. The difference is your work list.
3. Dispose of correctly — remove, or decommission in the platform so it stops reporting and stops appearing in scenes. Do not simply stop charging the battery and hope.
4. Update — the record, the scene list, the spares count and the drawing. All four, in the same week.

Orphaned automations are the specific danger. A door sensor that no longer exists can leave a scene waiting on a trigger that never fires, so a light stays on permanently in a room nobody uses — a small fault and a permanent cost, invisible until someone reads the electricity bill and wonders.

Firmware is an operational task, not a surprise

Firmware updates reach buildings the same way they reach homes: partly deliberately and partly on their own. The commercial difference is that an update touching thirty devices at once is an event, and events need a plan.

• A window — not a Tuesday at 9am. Agree out-of-hours slots with whoever is affected, and know which areas cannot be taken offline.
• A test — one device, or one zone, before a floor or a building. Know in advance whether the update changes behaviour.
• A record — version before, version after, which devices, who did it, what broke if anything did.
• A rollback plan — know what you do if an update takes a zone offline and does not come back. If the honest answer is "call the integrator", that is the stranded-system problem again.

The same discipline applies to batteries. Battery-powered sensors are a consumable with a service life, and a building with two thousand of them has a recurring replacement task with a real annual cost. Put it in the maintenance budget with a named owner, not in the head of a technician who happened to install the thing.

Handover to the facilities team: the step everyone skips

After the integrator leaves, who holds the knowledge? This is the question, and the answer determines whether you own a system or a liability.

The handover pack should contain, and should be signed for:

• As-built drawings, including where neutrals are and which circuits are used
• Network point schedule with locations, and the hub plan by floor
• The device list per space or room type, as an asset record
• Scene and automation definitions, by name, with what triggers what
• The account and credential ownership statement — whose email, whose phone number, whose cloud account
• The support contact, with a phone number and a response expectation
• A maintenance schedule: what is checked, how often, by whom
• A spare device list and the reorder point
• The training record: who was trained, on what, on what date

And three things that are routinely missing and should not be:

• A "what this system does not do" page. Every operator should know the boundary of the automation — which lights are on the system and which are still manual, which areas the sensors cover and which they do not.
• A reset procedure. One page, for one role. If the system needs an integrator to reset, it is not handed over, it is hosted.
• A second certified party. Not to run the building, to exist. A quoted price for someone else to service the system is what keeps the incumbent honest. See building a smart building business case for the contractual side.

Train by role, in this order: the person who resets a scene daily, the person who replaces a failed device, the person who changes an automation, the person who holds the account. Most facilities teams need the first two and should not be given the last two. Handing account credentials to a broad group of staff is how a tenant or an occupant ends up reconfiguring a building's lighting.

For the higher-level operational view of a property, see hotels, serviced apartments and offices. For the platform underneath, AqaraLink developer platform: APIs and SDKs covers the developer side.