# Back for another try **URL:** \ **Category:** Off-Topic\ **Created:** [January 10, 2026, 3:16pm UTC](https://community.homey.app/t/back-for-another-try/148988 "2026-01-10T15:16:59Z")\ **Posts on this page:** 5\ **Page:** 2
**Author:** ![Pascal\_Nohl](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/pascal_nohl/32/164446_2.png) [@Pascal\_Nohl](https://community.homey.app/u/Pascal_Nohl)\ **Post date:** [February 25, 2026, 9:53pm UTC](https://community.homey.app/t/back-for-another-try/148988/21 "2026-02-25T21:53:52Z")
> [@smarthomesven](#): > > I’ve never seen Matter or Thread used in any industrial environment, and that’s for a good reason. 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: > **[ISH 2023, The Leading HVAC/Water Trade Fair, Kicks Off - Siemens To...](https://threadgroup.org/Newsroom/Blog/ish-2023-the-leading-hvacwater-trade-fair-kicks-off-siemens-to-demonstrate-next-thread-based-building-portfolio?utm_source=chatgpt.com)** > > From March 13th until March 17th, Frankfurt will be the home of ISH 2023. For the first time again in many years, the world’s leading event for the HVAC and Water industries will hold an in-person trade event, bringing together all the leaders of the... Dali, one of the biggest concurring systems to KNX uses Thread: > **[DALI+ Over Thread Brings Unparalleled Flexibility to Lighting in Smart Buildings](https://threadgroup.org/Newsroom/Blog/dali-over-thread-brings-unparalleled-flexibility-to-lighting-in-smart-buildings?utm_source=chatgpt.com)** > >   > >   > >   > > For over three decades, the DALI protocol has been the worldwide standard for interconnecting lighting systems, luminaires, and related devices. DALI’s bi-directional digital interface allows for communication in lighting installations in... > **[DALIplus - Digital Illumination Interface Alliance](https://www.dali-alliance.org/daliplus/)** > **[diiase001a-dali-at-a-glance-for-lighting-designers-and-specifiers.pdf](https://www.dali-alliance.org/data/downloadables/4/3/5/diiase001a-dali-at-a-glance-for-lighting-designers-and-specifiers.pdf?utm_source=chatgpt.com)** Tridonic: > **[Case Studies](https://threadgroup.org/Tridonic-Thread-Border-Router?utm_source=chatgpt.com)** > > The Tridonic net4more Thread Border Router is a compact, easy to install device that can be used out-of-the-box to get Thread networks started. 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](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). ---
**Author:** ![Hsd1965](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/hsd1965/32/30160_2.png) [@Hsd1965](https://community.homey.app/u/Hsd1965)\ **Post date:** [February 26, 2026, 5:43am UTC](https://community.homey.app/t/back-for-another-try/148988/22 "2026-02-26T05:43:15Z")
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. ---
**Author:** ![Pascal\_Nohl](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/pascal_nohl/32/164446_2.png) [@Pascal\_Nohl](https://community.homey.app/u/Pascal_Nohl)\ **Post date:** [February 26, 2026, 7:29am UTC](https://community.homey.app/t/back-for-another-try/148988/23 "2026-02-26T07:29:14Z")
> [@Hsd1965](#): > > Matter over Thread is still in development. 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. > [@Hsd1965](#): > > But that it does not work in your case does not mean Homey Pro is bad in general. That is stretching it too much. 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. ---
**Author:** ![Vnet](https://avatars.discourse-cdn.com/v4/letter/v/d78d45/32.png) [@Vnet](https://community.homey.app/u/Vnet)\ **Post date:** [February 27, 2026, 2:41pm UTC](https://community.homey.app/t/back-for-another-try/148988/24 "2026-02-27T14:41:31Z")
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. ---
**Author:** ![Pascal\_Nohl](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/pascal_nohl/32/164446_2.png) [@Pascal\_Nohl](https://community.homey.app/u/Pascal_Nohl)\ **Post date:** [February 28, 2026, 9:34am UTC](https://community.homey.app/t/back-for-another-try/148988/25 "2026-02-28T09:34:51Z")
> [@Vnet](#): > > 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. > [@Vnet](#): > > i like zwave, 868mhz , long distance , rock solid. 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). [Previous page](https://community.homey.app/t/back-for-another-try/148988.md?page=1)