Fair warning before you scroll: I’ve never been good at keeping things short 
If you only read one part, make it the numbers.
I’ve spent the last few days measuring my own Thread network properly, because I wanted to put numbers next to the claims in this thread rather than impressions. Sharing the results here, including the parts that don’t support my own position.
Setup: Home Assistant OS, OTBR add-on 2.16.8 (Thread 1.3), Matter Server 9.1.0. The radio is an SLZB-MR3 (EFR32MG24) running as a networked Thread RCP, so the Thread radio is dedicated hardware and the OTBR runs as its own add-on container. Channel 15. 27 Matter devices, 21 of them over Thread, and 12 distinct RLOC16 exchanged frames with the border router during the measurement hour. The whole thing averages under 1% CPU, so none of this is about throwing hardware at the problem. It’s about which radio does what.
Getting to a frame count was harder than it should be. There is no ot-ctl on the HAOS host shell, no OpenThread Prometheus exporter and no Thread MAC counter entities in HA. There is a /diagnostics endpoint on the OTBR REST API that returns per-node macCounters, which I found afterwards and is arguably the better route, but nothing in either UI surfaces any of it. What I ended up doing was raising otbr_log_level to debug and counting spinel STREAM_RAW frames in Loki. Either way the point stands: on neither platform can a normal user see how busy their own Thread network is without going well off the supported path.
60-minute MAC baseline
| Measured at the border router |
Value |
| Frames transmitted (on air) |
1,222 |
| Frames received |
3,550 |
| Total |
4,772 (79.5/min, 1.33/s) |
| Busiest minute |
166 |
| Quietest minute |
52 |
| IPv6 datagrams |
4,168 (69.5/min) |
| Dropped |
90 |
| TX timeouts / RCP failures |
0 / 0 |
Important limitation: this counts frames this border router itself sent or received. It excludes link-layer ACKs, CSMA backoff and MAC retries, which the RCP handles without telling the host, and CRC-failed frames, which it drops outright. More importantly it excludes traffic between other pairs of nodes. The radio filters by PAN ID and destination address, so a poll from a sleepy device to a parent that isn’t me never appears at all. Only 12 of my Thread nodes showed up as radio neighbours. Real channel occupancy across the mesh is therefore meaningfully higher than 80/min, and this is not apples-to-apples with a figure taken from a sniffer or from another point in the stack.
28 days at normal log level
| From the OTBR log |
Value |
| “Dropping IPv6 UDP msg” entries |
41,003 (~¼ of my whole OTBR log) |
| Rate |
flat at ~1/min, every single day |
| 16 July, two devices went offline |
drop rate unchanged |
That last row is the interesting one. A noisy log tells you something is unresolved; it doesn’t tell you the network is failing. Worth remembering before anyone’s logs get used as a diagnosis.
@Doekse @Pascal_Nohl one observation for both of you, since it cuts across what you have each been arguing.
On the “more than 900 Thread messages per minute” figure: my own rate is ~80/min. But the more useful comparison is per device. 900 across 50 devices is roughly 18/min each, against 6.6/min per node across the 12 nodes my border router actually exchanges frames with. That’s a per-device difference, not simply a device-count difference.
And more to the point: 900/min is 15 frames a second. At 250 kbps with typical Thread frame sizes, that lands somewhere around 1-4% channel occupancy. A 2.4 GHz channel is not congested at 4%. So I’m genuinely unsure raw message rate is the mechanism here at all, and I’d be careful about treating it as one.
The question I’d rather ask is Pascal’s from #186: what kind of messages were those? Real application-level reports, Thread routing traffic, or retries of messages that had already failed? If it’s largely retries, the number is a symptom rather than a cause. And for what it’s worth Doekse, the second finding in that same report, the radio channel access errors pointing at 2.4 GHz interference, strikes me as the more interesting of the two.
One more thing worth putting on the record, and it cuts against my own setup.
Moving didn’t make my problems disappear. It changed which ones I have. The Zigbee side of my SLZB-MR3 still wedges every few weeks and needs a power-cycle. That’s a coordinator firmware problem rather than an architecture one, but it’s real and I live with it. I’m not sitting here with a perfect system, and I don’t believe one exists.
What I did do is stop being surprised by it. I’ve built Grafana alerts for the three failure modes I know about: the Zigbee coordinator’s SRSP stall, the border router going silent, and the crash-loop where the supervisor watchdog quietly gives up after ten retries. None of that makes the faults go away. It means I hear about them within a minute or two, instead of finding out because a light didn’t respond.
What did change is that I can see it. Close to 60 million Zigbee log lines have passed through my logging stack since I set it up at the start of April, and I still go through them. That visibility is the thing I wanted on the HP23 and never had, which is exactly Pascal’s point.
And here is what separate radios actually bought me. Every time the Zigbee coordinator has wedged, the longest well over an hour, the Thread radio on the same board, same host, same power, same Ethernet, kept forwarding Matter traffic without a single failure. The lights never noticed. And when the Thread side had its own bad day in July, Zigbee ran clean throughout.
That’s the property I’d point at. Not “dedicated radios are faster”. Dedicated radios fail separately. On one shared radio, whatever takes it down takes both protocols with it, by construction. For something that runs the lights in a house, that isolation may end up mattering more than throughput ever will.
@Doekse first, genuinely, thank you for the depth you have brought into this thread. Your diagnostics, your own setup description and your observations have been really interesting reading in here for me.
And thank you for #202 in particular. You listed three differences between the ZBT-2 and Homey Pro: Thread-only mode rather than Multi-PAN, a different chipset, and a different antenna design. Plenty of people in here have circled that question, Pascal not least, who asked back in #186 whether the multiprotocol design might be missing packets and causing retries. But it carries a different weight coming from Athom than it does from those of us on the outside. Multi-PAN is the shared radio. That is the whole thing, in one word.
That raises a question I’d genuinely like the answer to: does Homey Pro run Multi-PAN even when no Zigbee devices are paired to it? If Multi-PAN is a mode rather than a load, then someone who has moved Zigbee elsewhere is still paying for a radio that spends part of its time serving a PAN with nothing on it. And if that’s the case, being able to switch a Homey Pro into Thread-only mode, giving up the internal Zigbee radio (which several of us have already done in practice), would be a very different offer than “buy the next box”.
Which is why I want to be clear about one thing: my HP23 isn’t faulty. It was never an RMA case, and I never asked for one. The unit does exactly what it was designed to do. That matters because Pascal already put it well in #97: buying a new one with the same hardware and the same problems is unrealistic. If Multi-PAN versus Thread-only is the real difference, then he’s right, and a newer box on the same shared radio isn’t a fix for it. My argument has always been with the design, not with the hardware I own.
And I should be upfront about where that leaves me. I don’t run Homey any more, so I have nothing at stake in this, and anyone reading should weigh my opinion accordingly. I’m still in this thread because I’d like to see Homey get better, not because I have something to settle.
So the offer is open to everyone here, Athom included: if the measurements, the method or the queries behind them are of any use to you, take them. Ask me and I’ll share whatever I have.
@deejayreissue thank you for sharing your move, and I’d like to say clearly that I’d prefer it stays in this thread. Someone running the comparison in their own house and posting the result is about the most useful thing that can happen in a thread like this, whichever way the result falls. That’s worth encouraging.
Your case also matters more than mine, and here is why. You don’t have Zigbee devices on Homey at all. Your Zigbee lives on a separate Hue Bridge Pro on CH25, Homey on CH20, and as I understand your setup, no other border routers. You cleaned up your network properly, WiFi on CH1 at 20MHz, removed the router that sat above the stack. And 50 Thread devices ran flawlessly for nine months until v13.3.
And here is where your case stops being a counter-example to mine and becomes the cleanest evidence in this thread.
If Multi-PAN is a mode rather than a load, which is how I read Doekse’s #202, then Homey Pro was time-slicing its radio between two PANs on your setup as well, even with zero Zigbee devices paired to it. You removed everything that could be blamed: no Zigbee traffic, no other border routers by your own account, a clean channel plan, clean WiFi, the upstream router gone. What was left was the radio mode itself. And it still wasn’t stable.
I could never have produced that test. I moved Zigbee to a separate coordinator and moved off Homey at the same time, so my result has two variables in it. Yours has one.
I’d also note that you removed the Eve and the IKEA plugs and the problems stayed. And the 17 Aqara devices you kept are bulbs rather than plugs. They’re mains-powered, so they’re rx-on-when-idle and don’t poll at all.
Worth saying too: with my device count I have never been able to stress it the way you have. You were running roughly twice the Thread devices I am, so your setup surfaces things mine simply never will, which makes me wonder whether the HP2x starts struggling to keep up with itself once the network gets big enough.
Your 30-second, zero-failure commissioning on the ZBT-2, against sometimes up to five attempts for a battery-powered device on Homey, is the comparison I’d most like to see someone at Athom look at properly. Commissioning reliability isn’t a mesh-load story at all.
@Pascal_Nohl your point in #201 about the missing availability log is the one I’d underline hardest, and my measurements are an accidental proof of it.
Look at what it took to get to a single traffic number: raising a log level, grepping spinel frames out of Loki and normalising by hand, on a platform far more open than Homey. A red triangle that clears itself keeps the true scale of the problem invisible.
@smarthomesven raised a fair objection to this in #203, and I’d split it in two. The “when and how long” part is already solved on my side. Home Assistant’s recorder keeps every state change, so I can pull up any device and read off exactly when it went unavailable, when it came back and how long it was gone, down to the second. The default is ten days, and I’ve raised mine to 90. That isn’t exotic, it’s on by default and it’s one line of config. The “suspected cause” part is the one nobody does, and I wouldn’t blame any vendor for that, because it is genuinely hard. But “when and how long” is the part you actually troubleshoot with, and that’s the gap.
Most people won’t dig through 41,000 log lines, and shouldn’t have to. I happen to enjoy it, but that’s a hobby, not a diagnostic strategy. The recording should come from the platform.
On the off-topic question (#200): I’m with you. Removing the comparison removes the control group.
One last thing @Doekse and this is a question, not a proposal. Would Athom be OK with us forming a small community of practice around this, a Teams call or whatever shared medium suits people, for those of us who have actually been through it? It wouldn’t need to be hosted by Athom, and it isn’t about me running anything. But it shouldn’t happen without your blessing either, so I’d rather ask. 
Happy to take it to its own thread so this one stays focused.
And if you made it all the way down here: congratulations, and thank you 
I did warn you at the top.
