Running two platforms on purpose, without breaking your house
Two controllers is a design decision. Treated as one, it works. Treated as two homes, it does not.
Why two platforms happens anyway#
Almost nobody chooses this on day one. It arrives for four reasons, and all four are legitimate.
Household split: one person has an iPhone and one has a Pixel, so Apple Home and Google Home both need to work. Capability gap: your controller has no Zigbee or Z-Wave radio, so a second hub carries the radios. Voice preference: your automation engine has no assistant, which is true of Hubitat and Homey Pro and true of Home Assistant unless you build the local voice pipeline. Or hardware you already own: a Samsung TV with a SmartThings hub inside it is a controller whether you wanted one or not.
The pattern that works#
Step one: pick the owner. The owner is whichever platform can do the most and depends on the least. In practice that ordering is Home Assistant, then Hubitat or Homey Pro, then SmartThings, then Apple Home, then Alexa, then Google Home. The reasoning behind that ranking is in the seven platforms compared and scored in the Local Control Index. The owner holds the Zigbee and Z-Wave radios, runs every rule, and is where you go when something is wrong.
Step two: commission devices to the owner first. Whichever controller commissions a Matter device first becomes the administrator that can hand out access to others. Do that step deliberately rather than scanning a QR code into whichever app happens to be open.
Step three: share, do not duplicate. From the owner, generate a Matter pairing code for the second platform. The device now sits in two fabrics, both of which can control it and read its state. The second platform gets the device, not the responsibility.
Step four: give the second platform nothing but voice and dashboards. No routines, no schedules, no motion triggers. If someone asks for an automation, it gets built on the owner.
Step five: name things once. Room and device names diverge instantly across two apps, and the moment they do, voice commands start hitting the wrong device. Set the convention in naming and room structure that scales and apply it everywhere.
The four failure modes#
1. Duplicate automations. Both platforms decide to turn the porch light on at sunset. They disagree about sunset by four minutes, so the light flickers. Worse, both platforms have a rule to turn lights off when the last person leaves, one fires on geofence and one on presence sensor, and someone gets left in the dark in the living room. This is the most common failure and the easiest to prevent: automations in one place, always.
2. State divergence. The second platform shows a light as on when it is off. Usually this is a subscription problem: the second fabric is not receiving attribute reports, or the device is reachable on the mesh but not discoverable over mDNS from that controller. The tell is that control still works while state is stale. Do not re-pair. Check discovery first, as described in a device shows as unresponsive.
3. Thread fragmentation. Each ecosystem forms its own Thread network with its own credentials by default. Two platforms with border routers means two meshes, each with half the relays it could have had. Thread 1.4 made credential sharing mandatory for certified border routers, but it is user triggered and single use, not automatic. Doing it deliberately is covered in why you have three Thread networks. Homey Pro 2026 is a special case, because it forms its own network and cannot join an existing one at all.
4. Version mismatch. Two controllers on different Matter versions expose different subsets of the same device. As of September 2026 Home Assistant is on Matter 1.6 in shipping code, SmartThings and Homey Pro are on 1.5, and Google Home's documented device types top out at 1.3. A device can appear complete on one platform and half-working on the other, and the platform is not broken, it just does not implement that device type yet. What Matter still cannot do covers the pattern.
What the second platform costs you#
Adding a voice front end reintroduces a cloud dependency you may have paid to avoid. If Home Assistant runs your automations locally but everyone controls the house by talking to an Echo, then during an internet outage your automations run and your voice control does not. That is a reasonable trade as long as it is a decision rather than a surprise. The device-by-device version is in what still works when the internet goes down.
There is also an ongoing tax. Every new device now gets commissioned twice, every rename happens twice, and every troubleshooting session starts with working out which layer is lying to you.
| Platform | Matter support | Thread border router | Local Control Index | Best for |
|---|---|---|---|---|
| Apple Home | Apple does not publish a version. Behavior matches roughly Matter 1.2 to 1.4 device types. | Yes | 60 | All-iPhone households that want reliable local automation without maintaining anything. |
| Google Home | Documented device types top out at Matter 1.3, and Matter 1.2 types were still being added through late 2025. | Yes | 15 | Households already invested in Nest hardware that mainly want voice control. |
| Amazon Alexa | Echo devices run the Matter 1.5 SDK and expose a subset of 1.5 and earlier device types. | Yes | 5 | Getting a lot of devices working cheaply, and voice control in every room. |
| Samsung SmartThings | Matter 1.5, shipped about a month after the specification and ahead of every other consumer platform. | Yes | 30 | Mixed protocol homes, and anyone who wants Matter features first. |
| Home Assistant | Matter 1.6 in the current Matter Server, the most current implementation of any platform, though not yet re-certified by the alliance. | Yes | 100 | People who want everything local, every protocol, and no vendor able to switch a feature off. |
| Hubitat Elevation | Hubitat states Matter 1.5 on current hubs. That is a vendor claim we could not confirm in a certification record. | Model dependent | 88 | Z-Wave and Zigbee heavy homes that want rules to run locally with no maintenance culture. |
| Homey Pro | Matter 1.5, certified in June 2026. Cameras are not included and are deferred to a later release. | Yes | 63 | Homes full of legacy hardware that needs bridging into Matter, especially infrared and 433 MHz gear. |
When two platforms is worth it#
Worth it when the household is genuinely split between iPhone and Android, when your automation engine has no voice assistant and someone in the house wants voice, when you need radios your main controller does not have, or when you are mid-migration and running both deliberately for a few weeks.
Not worth it when the only reason is that you are curious. Two platforms doubles the surface area of everything that can break, and the second platform rarely adds a capability you could not get another way. If you are considering a second platform because the first one frustrates you, you are probably describing a migration rather than a coexistence. Read switching platforms without rebuying and price the move with the exit cost calculator before you commit to permanent duplication.
A worked arrangement#
A common and durable setup for a mixed household:
- Home Assistant on a Green with a ZBT-2 for Zigbee and a ZWA-2 for Z-Wave. It owns every device and every automation.
- One Thread border router, whichever ecosystem the phones use, with credentials shared so there is a single Thread mesh.
- Matter devices commissioned to Home Assistant first, then shared to Apple Home and Google Home by multi-admin so both phone platforms show the same devices.
- Echo or Nest speakers used only for voice, with no routines defined in either app.
- Zigbee and Z-Wave devices exposed to the ecosystems through Home Assistant's bridge, accepting the loss of detail that a bridge implies.
Nobody has to switch phones, everyone can talk to a speaker, and there is exactly one place where behavior is defined.
Can one Matter device belong to two platforms at once?
Yes. Matter multi-admin lets a device join several fabrics, so Apple Home and Google Home can both control the same light and both see its state. You generate a pairing code from the controller that already has the device and use it in the second app. Devices do have a limit on how many fabrics they can join, and cheaper or older ones sit at the low end, so check the documentation if you plan to share something three or more ways.
Which platform should own the devices?
The one that can run the most automations locally and depends on the least. Home Assistant, Hubitat and Homey Pro all execute rules on hardware in your house. Apple Home runs automations on a HomePod or Apple TV, which also survives an outage. Google Home and Alexa should generally be clients rather than owners, because their routines are cloud side.
Will two Thread border routers from different platforms work together?
Not automatically. Each ecosystem forms its own Thread network by default, so two border routers usually means two meshes that do not relay for each other. Thread 1.4 credential sharing lets you join one to the other, but it is a manual, single-use, user-triggered step. Homey Pro 2026 cannot join an existing Thread network at all.
Do I need two hubs if my household has iPhones and Android phones?
Not necessarily two hubs, but you will need two controller apps. Commission devices to whichever platform owns them, then share Matter devices to both Apple Home and Google Home by multi-admin. Both households members see the same devices, and neither platform runs automations. That avoids buying duplicate hardware for every room.
Why do my lights turn on twice with two platforms?
Almost always duplicate automations. Both platforms have a rule triggered by sunset or presence, and they fire seconds apart. Search both apps for schedules and routines, delete every rule from the client platform, and keep automations only on the owner. If a light still double-fires, check for a scene defined on the device itself.
Is running two platforms bad for reliability?
It adds failure modes rather than removing them. The mesh does not care, but discovery, naming, automation ownership and Thread credentials all become things that can be inconsistent. Done with a strict owner-and-client split it is stable. Done as two peers writing rules against the same devices it is not.
Can I use Alexa or Google purely for voice without giving them my whole house?
Yes, and it is the recommended approach. Share only the devices people actually talk to: lights, plugs, a thermostat, maybe the TV. Leave sensors, locks and anything safety related on the owner platform. Fewer exposed devices means fewer naming collisions and less to reconcile when something changes.
What happens to the second platform if I cancel or lose it?
If it only ever held shared Matter devices and no automations, very little. Remove its fabric from each device and the house continues. That is the practical benefit of the owner-and-client pattern: the client is disposable, which is not true when both platforms hold half your logic.
Primary sources
Specification and vendor documentation we checked while writing this page. Where a claim depends on firmware behaviour rather than a published spec, the page says so inline.