
Network field notebook
Thread Claims Interoperability.
Your Network Has Three Meshes.
Apple, Amazon, and eero each run a separate Thread mesh in my house. The devices remain IP-reachable, but the meshes do not share radio paths or redundancy.
Three meshes, one IP network
My capture found separate network names and credential sets for Apple, Amazon, and eero. That means three radio meshes, not three unreachable islands.
When two Thread devices sit on different meshes, their traffic crosses a border router, the home IP network, and another border router. I did not measure enough to claim a specific latency penalty.
Below is a model based on my discovery output. Press play to compare an eero-mesh sensor reaching an Amazon-mesh bulb with a same-mesh route.
What the apps do not show
Each vendor app shows a clean local view. None show the cross-mesh path.
- Apple Home shows the sensor and TV, but not the border routers or routed IP path.
- Alexa shows the bulb and Echo, but not the eero side of the route.
- eero shows Wi-Fi and clients, but not Thread hops at all.
The command nobody runs
Thread border routers announce themselves over mDNS under _meshcop._udp. Group the results by network name and the separate meshes become visible.
dns-sd -B _meshcop._udp .
eero-thread-3d8a
MyHome503847291
AMZN-Thread-9e6bThe apps show which ecosystems can control a device. The browse shows which Thread network carries its packets. Those are different questions.
Why I commission via eero first
eero has three border routers in my house, while Apple's mesh had one. Most of my Thread devices were already on eero's mesh-local prefix, so commissioning there avoids creating another network in my current setup.
A Matter fabric controls application trust; a Thread network carries packets. Pairing order can affect the second without making those two layers the same thing.