@EricM_Inovelli any update on the firmware update you mentioned previously RE: update to Thread 1.4?
Also, still crossing my fingers for a signal power configuration option and some of the other stuff I mentioned before. Any chance of that stuff making it?
FWIW (mostly for the rest of the members here, since I’ve mentioned most of this to Eric via DM before), there was a recent beta patch I’ve tested locally for about a month that fixed most of our flickering issues. We only have them very occasionally now, where previously we had them mulitiple times a day throughout the house.
I recently posted White Series Missing Configuration Values in Home Assistant in hopes of finding a way to access more configuration values in the white-series dimmers. Would that be relevant to this thread? Is this actually something not exposed by the firmware to matter? If not that would be a very helpful enhancement.
Using the Eve app, I’ve carefully monitored the Thread mesh and confirmed a major bottleneck: Inovelli switches promote to Thread routers aggressively, quickly hitting the 32-router cap imposed by the Thread protocol.
Problem
Inovelli switches auto-promote to Thread routers, even when not needed
The Thread network hits its router cap well before all switches are online
This causes:
New switches to fail to join fully or become “Endpoint 0-0”
“Could not complete operation” errors in HomeKit when configuring automations
Zombie router nodes that persist even after switches are removed or reset
Apple’s Thread stack is conservative about pruning stale routers
There’s no current way to manually prevent a device from becoming a router
Workaround Attempts
Created a clean mesh with only Eve Energy and Apple Border Routers online
Powered switches up in small batches, tracking router roles via Eve
Replaced all direct accessory automations with scene-based automations
Kept router count under 28 to maintain stability
These steps worked — but they require constant monitoring and limit scalability.
Feature Request
Please expose a firmware-level setting to allow users to manually configure a switch as an endpoint-only device (non-router).
Why this matters:
Avoids hitting the 32-router cap in Thread
Improves network stability in large deployments
Eliminates “zombie router” issues from removed or reset switches
Enables clean, predictable mesh design with intentional router placement
This could be implemented via:
A Matter configuration cluster attribute (role preference)
A firmware parameter accessible during commissioning
A toggle surfaced to supported platforms (e.g., HomeKit, SmartThings)
Why It’s Important
Thread is a mesh network with incredible potential, but at scale, unmanaged router promotion becomes a serious constraint — especially when using Apple Home, where the user cannot see or control routing behavior.
Giving users the ability to set router vs. endpoint behavior would make the White Series switch the most deployment-friendly Thread switch on the market — especially for advanced users building large, stable smart homes with Matter.
Open to Suggestions
If there’s anything I haven’t tried — configuration tips, diagnostics, hidden Matter attributes, platform-specific tricks — I’d love to hear them. Thanks for considering this request!
tvos 26, now out in beta, implements a Thread 1.4 border router which has improved routing features. I understand that Inovelli plans to do a firmware update and move to Thread 1.4.
It seems the fastest / most likely / least error prone path to improvement is to wait until the updated Inovelli firmware / updated tvOS are release, which should improve networking significantly. Trying to alter the Silicon Labs networking stack seems incredibly riskly.
Thanks — I totally agree that tvOS 26 and Thread 1.4 are exciting steps forward. Coincidentally just finished watching the Apple WWDC update now. Improved route healing and multi-border router coordination should definitely help with general mesh reliability.
That said, my core issue isn’t just route stability — it’s the 32-router cap being hit by a large number of router-eligible devices (Inovelli switches), which Thread 1.4 doesn’t directly solve. Thread still doesn’t auto-demote routers aggressively, and there’s no role prioritization without the vendor explicitly managing it in firmware.
To be clear, I’m not asking for deep changes to the Silicon Labs stack — just a firmware-level setting or Matter config flag to optionally force endpoint-only mode during commissioning. Even as an unsupported advanced feature, that would make a huge difference for large deployments like mine, and would let us stabilize things today rather than waiting on multiple future dependencies to align.
Would Inovelli consider exposing that option in a future firmware update?
I just took a look at this on my network. I have all Apple Border Routers however I have all my Matter devices paired with Home Assistant. HA allows me to see the Thread “Device type” being reported by HA for each Inovelli device (assuming the info provided by HA is correct). Of the 22 Inovelli devices I have, 12 are reporting as an “Routing end device” and the rest are reporting as an “End device”. Based on the topology of the network (the number of switches grouped together) these numbers would appear make some sense in my network. I believe the terminology that HA uses is a hangover from Zigbee.
Now, I have a lot less total thread devices than you do (32 including 5 Apple Border Routers) however I seem to be seeing a different behavior than what you are reporting. This could be due to the topology of your network or a facet of the way that Eve reports things.
My understanding of Thread was that up to the “best” 32 nodes would be “nominated” as routers and the rest would operate as end nodes (even if they were “router capable”). Based on what HA is reporting in my network that would appear to be how things are working. In my case 10 out of 22 Inovelli nodes are reporting as End devices. Note I don’t have visibility to the devices not attached to HA but I assume the border routers are all acting as Thread Routers.
Here is a quote from OpenThread that seems to fit with what I believe I’m seeing:
Thread tries to keep the number of Routers between 16 and 23. If a REED attaches as an End Device and the number of Routers in the network is below 16, it automatically promotes itself to a Router.
There was an Eve employee that used to provide good advice in the Eve forums (I say “used to” as he left Eve). He had explained that the Eve network topology information was originally an “internal” tool and really hasn’t kept up as thread and border router tech has evolved, so its usefulness is questionable.
A complexity with thread is that routing is dynamic, so what you see at one point, may be entirely different a few hours later. Everything from atmospheric conditions affecting radio propagation, to adding new devices can cause the system to re-evaluate route strengths and reconfigure.
Add to this the fact that modern OTBRs, like Apple TVs and homepods (which can function as either an OTBR or as a router) also support TREL (Thread Radio Encapsulation Layer) when in router mode. With TREL, if you have more than one Apple devices, the ones acting as routers can take thread packets being routed through them, encapsulate into TCP packets and send by WiFi/Ethernet to the final OTBR (saving hops over the thread network). Its a great way to expand the network capacity! Eve’s thread analysis doesn’t know about this.
Simply put, trying to figure out or manually optimize a thread network is an impossible task and the Eve tool isn’t much help (unless they can get the tool to be highly accurate, it would probably create a whole lot less user confusion and time waste for them to just remove the tool).
I’m not sure this helps or not but when I was first looking at Thread networks I played with Nordic’s nRF Thread Topology Monitor which gives you a visual view of a Thread network. Now this tool needs a Linux or Windows PC with nRF52840 Dongle.
The software is a pain in the tail to install (please don’t ask for assistance with that), however once done the monitor inserts itself as a Thread node on the network and you can see all of the interconnections.
The big issues with the tool is that it does not appear to have been updated recently and hence is almost certainly not up to the latest Thread standards and also since it adds a Thread node to the network (itself) it is effecting what it it is observing. As such I don’t use it on a regular basis and this morning I just fired it up for a few minutes to take the attached screenshots.
What you can see is that there is a core group of 17 (ish) routers with a bunch of devices connected as end nodes. As I said above I have 22 Inovelli nodes (#23 gets added tomorrow) plus 5 Apple OTBR/Routers plus 2 other Thread devices that are router capable. This means as HA indicated when I looked at things yesterday that a bunch of the Inovelli switches are (correctly) acting as End Nodes while about half of them are acting as routers.
When you watch the tool in real time you can see routers being “demoted” to end nodes and end nodes being “promoted” to routers every few minutes just as @jvm33 described which is how I believe a Thread network is intended to work.
Note there are two screenshots taken a few seconds apart. The first shows the complete network, the second a closeup or the central router portion of the network. You can see (if you look carefully) that each router has multiple connections to other routers and end nodes have a single connection to a router (however that single connection may “hop” to another router as network conditions change).
@nmorea If I were you I would be tempted to remove the Eve switches from your network (so that the only Router capable devices you have are Inovelli and Apple) and see if things stabilize.
Appreciate the insights and suggestions. I only added the Eve switches after I started having issues to try and get better visibility into the network and what was connected to which devices. Things have somewhat stabilized although not perfect by any means. I still think this is a case of HomeKit being overloaded and hitting a limit. I’ve noticed some of the Inovelli switches being demoted to endpoints (which is good) but my HomeKit Scenes don’t always get applied to the switches and the commands don’t always take effect when being called. I’ll dive more into this with 1.4 when the betas get release for Apple too.
If you cannot resolve the issue in Homekit, you might want to pair the switches with Home Assistant and then export them to Homekit. There is a significant learning curve but animations in HA are much more flexible than those in Homekit and you can also work around the issues related to light bars being visible in Homekit where you might wish they were not (there are multiple threads on that subject here).
I started with a 100% Homekit installation but have migrated to having all but two devices paired to Home Assistant and all but one of my animations in Home Assistant.
Any chance of that stuff making it?
Feature Request: Allow Manual Endpoint Mode for Matter-over-Thread White Series Switches
Context
Problem
Workaround Attempts
Feature Request
Why It’s Important
Open to Suggestions
