Smart Home Software Stack: Matter, Home Assistant & Aqara (2026)
A connected home becomes difficult when every new light, sensor and camera adds another hub, app and automation engine. The solution is not necessarily “one app for everything.” A cleaner approach is to decide which software controls each layer: the network, device radio, Matter/Zigbee bridge, automation engine, household interface, voice assistant and backup/recovery process.
Quick answer
For most homes, use one primary automation/controller layer and treat vendor apps as configuration/firmware tools rather than creating the same automation in five places.
- Simple Apple household: Apple Home as the main household interface, a suitable HomePod/Apple TV home hub where needed, Matter/Thread devices where practical, vendor apps retained for firmware and advanced features.
- Simple Google household: Google Home plus a Matter/Thread-capable Google hub such as Google TV Streamer or compatible Nest hardware, vendor apps for device-specific functions.
- Aqara-heavy home: Aqara Home + Hub M3 for local Aqara Zigbee/Thread/Matter automation, bridge supported devices outward to Apple/Google/Home Assistant through Matter.
- Power-user / mixed-brand home: Home Assistant OS as the main automation engine, with Matter, Zigbee and selected vendor integrations; Apple/Google/Alexa can remain the easier voice/family interface.
Matter reduces ecosystem lock-in, but it does not automatically expose every manufacturer feature. Thread is a network transport, not an automation platform. Zigbee still remains useful for low-power sensors. Home Assistant is a controller/automation platform, not a replacement for Wi-Fi or Thread. Keeping those layers separate makes purchasing decisions much easier.
The six-layer smart-home stack
| Layer | Examples | Job | Common mistake |
|---|---|---|---|
| 1. Network | Ethernet, Wi-Fi, router, VLANs | Moves IP traffic around the home | Blaming the hub for weak Wi-Fi |
| 2. Device transport | Thread, Zigbee, Wi-Fi, Ethernet, Bluetooth | Connects the physical device | Thinking Thread itself controls devices |
| 3. Device/controller protocol | Matter, HomeKit, vendor Zigbee bridge | Defines how devices are commissioned/controlled | Assuming every Matter platform exposes every feature |
| 4. Automation engine | Home Assistant, Aqara Home, Apple Home, Google Home | Runs scenes, triggers and conditions | Duplicating the same rule in several platforms |
| 5. Household interface | Home app, Google Home, dashboards, voice | Lets people control the home | Making a technical admin interface the only family interface |
| 6. Recovery/admin | Backups, setup codes, account recovery, device inventory | Restores the system after failure/change | Discovering recovery requirements during an outage |
Layer 1: the network is part of the smart home
Wi-Fi cameras, speakers, hubs and Matter-over-Wi-Fi devices depend on the home network. A brilliant automation controller cannot fix a weak access point behind two brick walls.
Use wired Ethernet where it is practical for fixed infrastructure such as PoE hubs, controllers, NVRs and access points. Keep Wi-Fi capacity for mobile devices and products that genuinely need wireless networking.
If you create a separate IoT VLAN or guest-style network, remember that smart-home discovery protocols can depend on local multicast/mDNS communication. Segmentation can improve security, but an over-restrictive firewall can break commissioning and cross-platform control. Document required paths rather than simply blocking everything and then creating random exceptions.
Layer 2: Thread, Zigbee and Wi-Fi are transports, not competitors in every situation
Thread
Thread is a low-power IPv6 mesh network designed for connected devices such as sensors, switches and locks. Home Assistant’s current documentation is explicit: Thread by itself does not provide smart-home control; a higher-level protocol such as Matter or HomeKit is required.
Thread devices need a Thread border router to connect the Thread mesh to the rest of the IP network. Current examples include Google TV Streamer (4K), Nest Hub 2nd generation, Nest Hub Max, Nest Wifi Pro, HomePod mini, supported Apple TV 4K models and some Aqara/Home Assistant hardware.
Zigbee
Zigbee remains widely used for battery sensors, plugs, lights and switches. It normally needs a coordinator/hub because Zigbee devices do not simply join the normal IP network like Wi-Fi devices.
Aqara’s classic sensors are a good example: supported Zigbee accessories connect to an Aqara hub, and the hub can then bridge supported device types into Matter-compatible ecosystems. You do not need to replace a working Zigbee sensor just because Matter exists.
Wi-Fi
Wi-Fi is appropriate for higher-bandwidth devices such as cameras, speakers and displays, and it is convenient because it uses infrastructure already in the home. The downside is that large numbers of poorly behaved IoT devices can add management and wireless-airtime complexity.
Use the transport that fits the device. A tiny door sensor does not need the same network design as a 4K security camera.
Layer 3: what Matter actually does
Matter is an application/control standard that runs over IP networks such as Ethernet, Wi-Fi or Thread. A Matter controller can commission and control supported Matter devices; each controller ecosystem maintains its own Matter fabric or participates in supported shared/multi-admin approaches.
Matter’s biggest practical advantage is multi-admin: a supported device can be shared with multiple platforms, so the same light or sensor can potentially appear in Home Assistant and Apple Home, or Google Home and another ecosystem, without the manufacturer building a separate proprietary cloud integration for every combination.
Matter 1.6, released in June 2026, added Joint Fabric as another multi-ecosystem management path and added NFC-based commissioning plus other device-management improvements. But the Connectivity Standards Alliance warns that device makers and ecosystems integrate specification features according to their own timelines. “Matter 1.6 exists” is not proof that your current phone, hub and device all expose Joint Fabric today.
Matter does not eliminate vendor apps
A vendor app can still be useful—or required—for:
- firmware updates;
- device calibration;
- advanced sensor parameters;
- camera recordings/features;
- energy statistics;
- special lighting effects;
- hub migration;
- diagnostics and support.
The goal is not to uninstall every manufacturer app. It is to avoid making the household remember which app controls which ordinary light every day.
Option 1: Apple Home as the household layer
Apple Home is strongest when the household already uses iPhone, iPad, Apple Watch, HomePod and Apple TV. Current Apple support lets compatible Matter accessories be paired into the Home app, and paired Matter accessories are tracked through iCloud Keychain with end-to-end encrypted pairing-key storage.
Apple has reduced the strict need for a hub in some newer Matter scenarios: current iOS documentation says an iPhone on iOS 18 or later can add/control Matter accessories without a home hub, and newer iPhones can directly control some Thread accessories. Apple still recommends a home hub for the best experience, remote access and broader automation behaviour.
Use Apple Home as the main interface when family simplicity and Siri/Apple integration matter more than building deeply customised automation logic.
Option 2: Google Home as the household layer
Google Home supports Matter over Wi-Fi and, with a Thread-capable Google hub, Matter over Thread. Current Google Thread border-router examples include Google TV Streamer (4K), Nest Hub (2nd gen), Nest Hub Max, Nest Wifi Pro and the 2026 Google Home Speaker.
Google securely stores Thread credentials in the user’s Google Account to simplify setup/recovery across supported Android/Google Home devices. That is convenient, but it also means Google Account recovery and security form part of the smart-home recovery plan.
Google Home is a sensible primary interface when Android/Google Assistant/Google TV/Nest already dominate the household.
Option 3: Aqara Home + Hub M3 for an Aqara-heavy home
Aqara Hub M3 is a useful example of a vendor ecosystem becoming a broader local controller. The M3 supports Aqara Zigbee and Thread devices, acts as a Matter controller and Matter bridge, and can bring supported third-party Matter devices into Aqara Home.
Aqara’s architecture also focuses heavily on local execution. The company says many Aqara Home automations can move from cloud execution to the M3/edge so they continue when the external internet/cloud is unavailable, although cloud-dependent functions such as push notifications still need connectivity.
The M3 provides dual-band Wi-Fi, Power over Ethernet and encrypted local storage. For an Aqara-heavy installation, PoE is especially useful because it gives the hub one wired cable for stable data and power.
We have an approved Aqara UK Awin affiliate relationship. This exact M3 route is commission tracked and does not increase the buyer’s price.
Check Aqara Hub M3 at Aqara UK
Do not interpret the M3 as universal local control for every Matter device/feature. Aqara itself notes that third-party Matter support varies by device type and ecosystem.
Option 4: Home Assistant as the automation core
Home Assistant is the strongest option when you want one automation engine spanning multiple brands and protocols, detailed dashboards, local integrations and much deeper conditional logic than most consumer apps.
Its Matter integration runs a dedicated Matter controller/server and can control Matter devices on local Wi-Fi or Thread networks. A Matter device can be commissioned directly into Home Assistant’s fabric or shared into Home Assistant from another ecosystem such as Google or Apple.
This is important architecturally: Home Assistant does not require every Matter device to use Home Assistant’s own Thread border router. It can use compatible third-party border routers to transport encrypted Matter traffic. The border router passes the packets; the Matter controller manages the device.
Home Assistant’s own Thread border-router integration is still described as work in progress. Home Assistant Yellow, Connect ZBT-1 and ZBT-2 can be configured for Thread, but the project currently recommends Home Assistant OS for the most supported Matter setup. Avoid redesigning a stable Thread network just because your controller can technically become another border router.
A good power-user pattern: Home Assistant core, Apple/Google front end
You do not have to choose one ecosystem for every task. A practical mixed household might use:
- Home Assistant: main automation engine and technical dashboard;
- Aqara M3: local Aqara Zigbee/Thread hub and device-specific automation/bridging;
- Apple Home or Google Home: family-friendly room controls and voice;
- Matter multi-admin: shares selected compatible devices between controller ecosystems;
- vendor apps: firmware, calibration and features Matter does not expose.
The mistake is duplicating the same critical automation everywhere. Decide where each rule’s “source of truth” lives so a troubleshooting session does not turn into hunting through four apps.
Where should automations live?
| Automation | Good home for it | Reason |
|---|---|---|
| Aqara motion sensor → Aqara light | Aqara local automation | Fast/simple and can remain local on supported devices |
| Mixed-brand presence + energy + weather rule | Home Assistant | Cross-vendor logic and complex conditions |
| “Good night” household scene | Main household interface or Home Assistant exposed outward | Needs to be easy for everyone to trigger |
| Voice command | Apple/Google/Alexa front end | Natural household interface |
| Vendor firmware/calibration routine | Vendor app | Matter often does not expose device-specific maintenance |
Keep cameras separate from the low-power sensor mindset
Security cameras are bandwidth-heavy, privacy-sensitive devices. They often depend on vendor recording/cloud features and do not behave like a Matter door sensor. Do not select a whole smart-home platform purely because it exposes lights/sensors nicely and then assume it is automatically the best camera/VMS platform.
For camera-heavy homes, decide separately where video is stored, who can view it, whether local recording continues without internet and how long recordings are retained. Our Home Security Camera Systems coverage handles that part of the stack.
Backups are a software-stack component
Home Assistant currently supports backup/restore across all installation types and built-in automatic backups through the UI. It also exposes an automatic-backup action that can create an extra recovery point before updates or major changes.
Other ecosystems may store much of their state in vendor cloud accounts rather than a downloadable backup file. That makes account recovery, household-member access, Matter setup codes and a device inventory more important.
Use our recoverable smart-home guide for the full recovery model. A system is not well designed if replacing one failed hub requires rediscovering every device model, setup code and automation from memory.
Do not create three Thread networks accidentally
Thread is designed to support multiple border routers, but separate ecosystems can also create separate Thread networks/credentials. Home Assistant’s current documentation specifically discusses situations where Apple, Google and Home Assistant Thread networks coexist and asks the administrator to select the preferred network when integrating a Home Assistant border router.
Before adding more Thread radios:
- check which Thread network already exists;
- identify the border routers already active;
- decide which ecosystem stores/owns the credentials you want to use;
- share/synchronise credentials using supported platform procedures;
- avoid factory-resetting stable Thread devices merely to “standardise” without a reason.
Voice assistants should be the interface, not necessarily the automation brain
Voice is excellent for simple requests: lights, temperature, media and scenes. Complex home logic is easier to audit in a visual automation engine where conditions and dependencies are explicit.
A useful design is to create a named scene/script in Home Assistant or the device platform, then expose that action to Siri/Google/Alexa. The voice layer becomes a trigger instead of duplicating the automation logic.
Security checklist for the software stack
- Use unique passwords/passkeys and MFA for smart-home cloud accounts.
- Keep hubs, routers and controllers updated.
- Remove old household members and unused integrations.
- Do not expose Home Assistant/router/admin panels directly to the internet without a secure architecture.
- Review third-party integrations/tokens periodically.
- Keep device setup/recovery codes securely stored.
- Prefer local execution for essential rules where it genuinely works, but keep cloud-dependent functions documented.
- Know which vendor will stop supporting each important device.
Three example software stacks
Simple mainstream home
- Google Home or Apple Home as primary app;
- one compatible Matter/Thread hub already serving another purpose (Google TV Streamer, HomePod/Apple TV, etc.);
- Matter-over-Thread sensors/plugs where supported;
- vendor apps retained only for setup/firmware;
- no Home Assistant unless the household has a requirement it solves.
Aqara-focused home
- Aqara M3 as local Aqara automation/controller layer;
- Aqara Zigbee/Thread devices;
- Aqara Home for advanced configuration;
- bridge selected compatible devices through Matter to Apple/Google;
- optional Home Assistant later for mixed-brand logic.
Power-user mixed home
- Home Assistant OS as main automation engine;
- Ethernet controller/PoE where practical;
- Zigbee coordinator/hub for existing low-power devices;
- one well-managed Thread network with suitable border routers;
- Matter devices commissioned/shared between needed fabrics;
- Apple/Google/Alexa as household/voice interface;
- automatic controller backups and documented recovery.
When Matter is not the best buying criterion
Do not reject an excellent mature device solely because it uses Zigbee behind a supported bridge. Matter helps interoperability, but a well-supported bridged Zigbee device can be more reliable and feature-rich in a specific ecosystem than a cheap native-Matter product.
Likewise, do not buy something merely because the box says “Matter.” Check:
- the exact device type your chosen platform currently supports;
- whether the features you care about are exposed through Matter;
- whether Thread requires a border router you already own;
- whether firmware/calibration still needs the vendor app;
- whether multi-admin sharing works in the combination you intend to use.
How we researched this guide
We checked current Home Assistant Matter/Thread/backup documentation, Google Home Matter and Thread guidance, Apple Matter pairing guidance, Aqara Hub M3 architecture and the Connectivity Standards Alliance’s Matter 1.6 and multi-admin information. We deliberately distinguish specification capability from features already implemented by every platform.
Primary sources
- Home Assistant — Matter
- Home Assistant — Thread
- Home Assistant — Backup
- Google Home — Matter/Thread hubs
- Apple — Matter accessories
- Aqara Hub M3 local/Matter architecture
- Connectivity Standards Alliance — Matter 1.6
Frequently asked questions
Do I need Home Assistant if I have Matter?
No. Matter provides interoperable device control; Home Assistant is an automation/controller platform. A simple Apple/Google/Aqara household can work perfectly well without Home Assistant. Use Home Assistant when its cross-brand automation, dashboards and integrations solve a real requirement.
Is Thread the same as Matter?
No. Thread is a low-power IP mesh transport. Matter is a control/application standard that can run over Thread, Wi-Fi or Ethernet.
Can I use the same Matter device in Apple Home and Google Home?
Matter supports multi-admin/device sharing, but the exact onboarding flow and supported device features depend on the platforms and their current implementations. Do not assume every advanced vendor feature appears in both apps.
Can Aqara M3 work with Home Assistant?
Aqara M3 can bridge supported Aqara devices through Matter to compatible ecosystems, and Aqara lists Home Assistant among its Matter bridge targets. Exact exposed device types/features vary, so verify the devices you plan to use.
Does Home Assistant need its own Thread border router?
Not necessarily. Home Assistant can control Matter-over-Thread devices using compatible third-party Thread border routers. Home Assistant can also be configured as a Thread border router on supported hardware, but its own documentation still describes that integration as work in progress.
Should every automation run locally?
Local execution is useful for speed and resilience, especially for lights/heating/sensors, but cloud services still make sense for remote notifications, weather data, voice services and vendor features. Document which essential rules continue without the internet.
Final verdict
The cleanest smart home is not the one with the fewest apps installed; it is the one with a clear source of truth. Choose one main automation engine, one household interface, use Matter to share compatible devices where it genuinely helps, keep vendor apps for device-specific maintenance, and treat Thread/Zigbee/Wi-Fi as networking choices rather than ecosystems.
For most mainstream homes, Apple Home or Google Home plus Matter is enough. Aqara-heavy homes gain meaningful local control from Hub M3. Mixed-brand power users gain the most from Home Assistant—but should add it deliberately, not because complexity itself is a feature.
Next, see our Best Smart Home Hubs UK, Recoverable Smart Home and Smart Home Hubs & Sensors guides.
