Matter vs Zigbee vs Vendor API: Choosing a Smart Home Integration Strategy

Answer up front — There is no single correct route, because the three solve different problems. Matter buys cross-vendor interoperability and the ability to walk away from one ecosystem later. Zigbee buys reliable low-power mesh with rules that keep running when the internet drops. The vendor API buys the capabilities only that vendor exposes — Aqara's own locks, cameras, IR and local automations. The honest answer for most Malaysian projects is a split: Matter for anything a client may replace, Zigbee for the local-control backbone, vendor API only where nothing generic exists. On Aqara specifically, Matter needs a controller such as Hub M3 set up in Aqara Home first, and Matter sub-devices in the SDK must be connected via an Aqara Matter hub using Magic Pair before they can be configured or controlled.

Choosing a hub covers which hub to buy, and Matter with Aqara covers setting up the Matter controller. Neither is about the architecture decision, which is what this post is for.

The decision is about failure, not features

Every integration strategy is really an answer to one question: when the vendor, the cloud or your own server disappears, what still works? That framing beats a feature matrix, because features change and failure modes do not.

• If the answer must be "the lights still work", you need local execution, which means a hub and a mesh protocol.
• If the answer must be "I can swap vendors in two years", you need an interoperability standard the vendor does not control.
• If the answer must be "I need Aqara's specific lock behaviour", you need Aqara's API, and you accept the dependency.

Teams get this wrong by picking the route that demos best. The route that demos best is usually the vendor API, because it has the prettiest integration and the most capability. It is also the one that puts your client's building on a dependency you do not control.

The three routes, honestly

Matter: the route out

Matter's value is not features. It is that it lets you leave. A Matter accessory commissioned onto a Matter controller is controlled by that controller, and the accessory is not tied to the app that set it up. If your client outgrows Aqara, the device does not become a brick.

The engineering cost is real and sits in commissioning, not in the API. You have to get the controller right, the fabric right, and the multi-admin story right. Aqara's supported Matter device type list covers lighting and actuators — on/off, dimmable, temperature colour and enhanced colour lights; on/off and dimmable plug-in units; mounted on/off control and mounted dimmable load control. That is a genuine range, and it is worth checking against your device list rather than assuming.

The Aqara facts that trip people up:

• Matter accessories, including Matter over Thread, require a Matter controller such as the Hub M3, set up in Aqara Home first. Matter with Aqara covers the sequence in detail. Do the setup before you pair, not after.
• Zigbee devices can go onto the Hub M3 or the Panel Hub S1 Plus, because the S1 Plus is itself a Zigbee hub. This is the single most common source of confusion in the Aqara range: the S1 Plus is a Zigbee hub, not a Matter controller. Matter accessories are added through a Matter controller such as the Hub M3, and can then be controlled from the S1 Plus.
• In the SDK, Matter sub-devices cannot be configured and connected directly. The Matter vertical category SDK documentation is explicit: they must be connected via an Aqara Matter hub, using Aqara's private Magic Pair protocol, before device configuration and control can be performed. If you are building a mobile onboarding flow, that is a hard sequencing constraint in your UX, not a detail.

The lock-in caveat: escaping the device layer is not escaping the hub layer. Whichever controller you commission onto becomes the thing your client depends on. Matter reduces one axis of lock-in, not all of them.

Zigbee: the route that keeps working

Aqara is Zigbee-first, and a hub controls up to 128 related devices. The value of Zigbee for an integrator is not the protocol — it is that the rule runs in the unit. Motion lighting in a corridor does not care whether the fibre is up, and a smart home where the lights need a datacentre is a smart home with a single point of failure that is not in your building.

Local execution is the deciding factor, and it is why the automation and scene decision belongs at the hub rather than only in your cloud. The platform documentation advertises localised multi-device automations for stable scene control, with Away Mode and Home Mode as the examples.

Engineering effort is lower per device and higher in aggregate. The mesh is simple; the commissioning, the placement and the routing are not. A sub-device on the far end of a three-storey shophouse with one repeater is a site problem, not a protocol problem, and no API decision fixes it.

Vendor API: the route that does the thing nobody else can

Aqara's platform declares itself multi-protocol: Zigbee, Wi-Fi, Thread, Bluetooth, Ethernet, IR, Matter, BACnet, KNX, DALI and Modbus. On the developer side, the cloud HTTP API covers device status queries, remote control and linkage configuration, with message push for real-time device reports. The App SDK set covers device pairing, device control, IR remote control, camera and door lock product lines.

This is where you go for Aqara-specific behaviour: IR learning and IR virtual sub-devices, the door lock product line, camera preview and playback, the Aqara Home ecosystem experience. None of that is coming to a generic standard tomorrow, and pretending otherwise is how integrations get stuck.

The cost is the one you already know: your client's building now depends on one vendor's roadmap, one vendor's cloud and one vendor's pricing. The Aqara IoT Solution Platform targets exactly this — real estate, buildings, hotels, campus and senior care, with batch onboarding and operations tooling — and it works, because that is a deliberate choice of lock-in in exchange for capability.

Choosing, in practice

The failure mode to avoid is a single-vendor stack presented to the client as vendor-neutral. If the property manager is told they can change vendors later and every device turns out to be Aqara-only, that is a commercial problem you created and cannot undo. If Matter is your exit strategy, the devices that matter must actually be Matter.

Sequencing, which is where projects fail

The order is not negotiable and it is the same on every project:

1. Decide the protocol strategy per device category, not per project. "Zigbee backbone, Matter for replaceable lighting, vendor API for locks and IR."
2. Commission the controllers first. For Aqara, that means a Matter controller such as the Hub M3 set up in Aqara Home before any Matter accessory is paired.
3. Place hubs for mesh coverage, not for looks. Then verify the far corner before you commission the rest.
4. Put safety and egress-critical rules on the hub, not only in your cloud.
5. Only then wire the vendor API layer for the things the standard routes genuinely cannot do.
6. Write down which devices are vendor-dependent and hand that list to the client with the maintenance contract.