Back for another try

Off-Topic
21

II never claimed Matter over Thread is widely used in “industrial environments”. I was talking about Thread as an IPv6 mesh radio for IoT in buildings.

Also, with respect: I’ve worked for ~20 years as senior project manager for large facilities (55,000 m² + two ~6,000 m² sites). Thread is not “just smart home fluff” anymore—there are public, building-industry references from major players and building standards:

Dali, one of the biggest concurring systems to KNX uses Thread:

Tridonic:

ABB (Thread/Matter/KNX) :

https://new.abb.com/news/detail/120015/abb-and-zumtobel-group-partner-to-advance-smart-lighting-and-building-solutions-and-direct-current-dc-industry-applications

So yes: Thread is being positioned and used in real building ecosystems (especially lighting and IP-based building automation). If your claim is “I’ve never seen it in industry, therefore it’s not used for good reasons”, that’s simply not a reliable argument—absence of personal exposure isn’t evidence.

Do you need more evidence, or are you arguing a different point—e.g., that Thread is not appropriate for certain safety-critical industrial control networks?

B.T.W. I’ve never seen Zigbee in a large scale building. Dali and KNX are the standards for wired devices and since 2022, both use Thread for their new wireless devices. Schneider Electric is in the starting blocks, as ABB is (ABB bought Eve).

22

Let me rephrase. Matter over Thread is still in development. And the level of implementation of the Matter standard is not up to par for many manufacturers.

Apple’s implementation of Matter in Apple Home is known for not playing nice with other Matter hubs running in parallel. Multi admin is not working properly yet in all cases, some device manufacturers don’t even support it yet.

In my setups, in two different homes, I have never got Apple HomeKit working stable when using Matter over Thread. However, the Homey Pro Thread network has been rock solid.

In your case it is the other way around. So maybe there are other factors at play.

For your case it maybe is a Homey thing. But that it does not work in your case does not mean Homey Pro is bad in general. That is stretching it too much.

23

I don’t think that wording is accurate.

  • Thread is a mature, production networking standard. The more recent updates (e.g., around 2024) focus on things like improved multi-vendor interoperability and diagnostics, not fundamental changes to the core concept.

  • Matter is still evolving fast, but that doesn’t mean it’s “in development” in the sense of being unstable or unfinished. It’s a young standard that adds device classes and features with new releases — which is normal. A newer spec version doesn’t imply that earlier versions are not stable, or that compliant devices are inherently unstable.

If we label that as “still in development”, then the same logic would apply to Zigbee (e.g., Zigbee 4.0) and even Z-Wave, which continues to evolve through new chip generations and feature extensions. Continuous evolution doesn’t automatically equal instability.

Agreed — and to be clear, I never claimed Homey is bad in general. I actually like it a lot and I’d say it’s one of the best systems I’ve owned apart from this Thread issue.

That said, for me a home automation controller must be reliable enough to run the whole house. What I’m seeing doesn’t look like occasional RF interference or normal routing/role changes:

  • the system repeatedly loses the same devices,

  • often devices that are well covered by multiple Thread routers,

  • and they don’t recover on their own — they stay unavailable indefinitely,

  • until a Homey reboot brings everything back within 2–3 minutes.

I’m also a developer, and even though I obviously can’t see what happens inside Homey, I can still evaluate reproducible symptoms and map them to likely classes of failure.

What I’m seeing has a consistent, repeated pattern. That is not how normal RF interference or routine Thread rerouting typically behaves.

Based on that, this looks much more like a software/stack state problem on Homey’s Thread side — e.g. the Thread subsystem getting stuck, failing to re-attach/refresh routes, or the availability tracking not recovering — rather than a hardware radio defect. In other words: the radio hardware may be fine, but the Thread software layer ends up in a bad state and only a restart clears it.

I understand being enthusiastic about a platform, but the symptoms are consistent and reproducible, and the facts don’t change just because we like the product.

24

i am a bit sceptical on thread due to the frequency band it uses. again a technology fighting for bandwidth on the crowded 2.4ghz. its already known that apple use thread channel 25 a lot which overlaps with the wifi channels used.

so bluetooth, zigbee,wifi,thread,hue and even the microwave, especially the cheap non-ce ones leaking interference on the 2.4ghz.

i put zigbee,hue on different channels and as far as possible from wifi. not sure if the thread channels can be fixed.

i like zwave, 868mhz , long distance , rock solid.

25

I agree with most of what you say, but I’m looking at it from a different angle.

Z-Wave often performs very well (sub-GHz, good range, usually very stable), but the hardware is frequently expensive, and “ghost nodes” can be a real nuisance if devices are removed incorrectly. In my own setup I ran a Z-Wave-only system for about two years and still had occasional issues (e.g. some window contacts dropping or TRVs behaving unreliably). Less often than with other systems, but not perfect either (USB3, SSD interferences, old LTE at proximity,…)

On the 2.4 GHz side: Thread (like Zigbee) is in the 2.4 GHz band, so coexistence with Wi-Fi matters. In professional deployments I’ve seen Thread networks run extremely stable when Wi-Fi is configured conservatively (dedicated 2.4 Ghz IoT net, fixed channel plan, 20 MHz bandwidth, careful AP placement, fewer “auto” features).

Right now I’m using an ASUS XT12 as the main AP plus three XT8 nodes with Ethernet backhaul — good consumer gear, but still consumer-grade. That’s why I’m considering moving to a more professional Wi-Fi setup that gives real control over channel planning and radio behavior (e.g., TP-Link Omada with controller + managed switches), without going all the way into expensive enterprise systems like Meraki (that perform exceptionally good).

But Homey is still a major part of the problem in my case, and I think this is a design issue:

  • The 2026 model still doesn’t use fully separate Zigbee and Thread radios (separate chips + separate antennas). Sharing radio hardware for two networks is a compromise by definition and makes stable coexistence harder than it needs to be.

  • For a “new generation” hub, a built-in Ethernet port (ideally PoE+) would have been the sensible choice. It improves placement, stability, and removes another external dependency.

  • And yes, multiprotocol / shared-radio setups are widely known to cause trouble in practice. Even the Home Assistant world increasingly advises against running Zigbee + Thread on the same radio if you care about stability — dedicated radios are the recommended approach.

Finally, about channel changes: Thread can handle channel changes by design, but on Homey you don’t get proper, deterministic channel control. It’s more like trial-and-error “reshuffling” — and the worst part is that this process effectively blow away your network state, so devices need to be rejoined. That’s not just annoying, it’s a real operational downside. You can’t have separate channels for Zigbee and Thread, they share the same hardware, the same channel and the same radio standard (802.15.4).

1 Like