@ulrikb First up, thank you for the elaborate research and post. Very much appreciated!
This is exactly the kind of contribution I was hoping to see here: actual measurements, comparisons and observations that we can discuss and learn from, rather than going around in circles with “but why this?” and “why that?”. So genuinely, thanks for putting the time into this.
There are a couple of things I’d like to clarify though.
Homey Pro indeed runs the Silicon Labs radio in Multi-PAN mode, allowing Zigbee and Thread to coexist on the same radio. We don’t dynamically switch the radio between Zigbee-only, Thread-only and Multi-PAN depending on whether Zigbee devices are present.
I do want to make one important distinction here: running Multi-PAN doesn’t necessarily mean that the available radio bandwidth is permanently divided between Zigbee and Thread, regardless of actual traffic. They share the same radio and therefore the same radio resources, but that isn’t quite the same thing as saying that an otherwise idle Zigbee PAN continuously consumes a fixed portion of the available airtime.
That said, your comparison with a dedicated Thread radio is absolutely interesting, especially the isolation aspect you describe. With separate radios, a failure or issue affecting one radio doesn’t inherently affect the other protocol. That’s a perfectly valid architectural advantage.
Regarding diagnostics, I also understand the point you and @Pascal_Nohl are making.
Yes, being able to browse through a full set of raw chipset, OTBR or protocol logs can be fun and incredibly useful for the people who know what they’re looking at. But for everyone who doesn’t, it can also be very confusing and potentially lead to completely wrong conclusions. We’d rather have people reach out, and we can lend a hand in figuring out what is going wrong. That’s why we have a support team and why I like to hang out here.
The Homey Developer Tools already provide quite a bit of information here, including when devices connect and disconnect (Matter → ⋮ next to a Thread device → Thread Network Information). That can be very useful for establishing a timeline and identifying patterns.
Determining why a device became unavailable is obviously a different matter. That can involve anything from the device itself, routing and network conditions to interference or issues further down in the radio/protocol stack, and isn’t something we can necessarily derive from a simple disconnect event.
For Thread specifically, the Thread Diagnostics app can provide quite a bit of additional insight as well.
And just to add some personal experience here: Thread hasn’t been flawless for me either.
For example, my Motionblinds blinds tend to drop off the Thread network every couple of days. When that happens, however, they’re not just unavailable in Homey. They’re gone from Google Home as well as the Home Assistant instance I have running. In my case, it seems to be related to the sleep/wake behaviour of the blinds, as sending a command using the 433 MHz remote wakes them up and suddenly makes them available over Thread again.
And my own environment certainly isn’t an RF-clean laboratory either. I live right in a city centre with tens of Wi-Fi networks around me (80 devices on my own network), probably even more Bluetooth devices, and both of my direct neighbours are running Philips Hue networks as well. There’s quite a lot happening in the 2.4 GHz spectrum around here.
Yes, that is absolutely frustrating, but unfortunately, it’s also the reality sometimes.
That’s obviously a very different situation from what is being investigated in this topic, but I mention it because Thread as an ecosystem is still something I personally encounter quirks with as well. I simply haven’t experienced these kinds of issues with my Zigbee and Z-Wave networks, which have generally been extremely stable.
Lastly, I really want to stress that I’d like to keep the discussion here civil and respectful. We’re here to have a healthy technical conversation, share experiences and hopefully learn something from each other’s findings.
@deejayreissue; I’d really like you to stop with these types of comments. They aren’t helping anybody move the discussion forward, and I don’t appreciate them one bit.
It’s absolutely fine to disagree with me, challenge what I’m saying or compare experiences between Homey, Home Assistant or other platforms when that helps us understand what’s happening. In fact, comparisons like the one @ulrikb has made here can be genuinely useful. But let’s do that based on the technical arguments and findings rather than making comments about each other.
As said earlier: In the end, there’s a smart home platform for everyone, and that’s perfectly fine. Let’s use the different platforms, setups and experiences represented here to help figure out what’s actually happening, rather than turning those differences into a competition.
And of course! It’s always fun and useful to do these kinds of things. That’s what the Forum is for, but a get-together or Teams call can definitely be helpful as well if people are up for it.
As for me, I’ll probably stick to the Forum. My girlfriend still likes to see me in my spare time as well 
