KahWee Teng

Network field notebook

Thread Claims Interoperability.
Your Network Has Three Meshes.

Apple, Amazon, and eero each run a separate Thread mesh on the same physical network. When devices cross meshes, packets take the scenic route.

8 min readInteractive field note

Three meshes, no bridge

Thread was designed for local communication. In practice, Apple, Amazon, and eero each operate their own Thread mesh with their own border router. These meshes do not bridge to each other.

When a device on one mesh talks to a device on another, the packet must exit the first mesh, cross Wi-Fi, then enter the second mesh through a different border router.

Below is a live model from my home network. Press play to watch a temperature sensor on the eero Thread mesh report to an Alexa app on the Amazon Thread mesh.

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 Wi-Fi ferry.
  • Alexa shows the sensor and Echo, but not the eero side of the trip.
  • 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 fragmentation becomes visible.

dns-sd -B _meshcop._udp .

eero-thread-3d8a
MyHome503847291
AMZN-Thread-9e6b

The apps show which ecosystems have keys to a device. The network shows which mesh is doing the actual work. Those are often different answers.

Why I commission via eero first

eero has three border routers, survives a single node going offline, and joins reachable Matter devices anyway. Pairing through eero first aligns the fabric controlling the device with the mesh routing its packets.

That is not the unified network Thread promises. It is the cleanest setup I can get under the current fragmentation.