For as long as I have been putting radios in this flat, the advice has been the same and it has been boring: pick one protocol per device and stop fiddling. A bulb is either a Zigbee bulb on my Zigbee2MQTT network or it is a Thread device on somebody’s Matter fabric. Not both. That constraint is the reason my mesh is stable, and it is the reason I can answer the question “what happens if the internet dies” with a shrug.
Silicon Labs and Signify announced on 23 June that they are removing the constraint. Select Philips Hue bulbs built on Silicon Labs’ MG26 and SiMG301 wireless SoCs will run Zigbee and Matter over Thread concurrently — the same bulb, the same radio, two networks at once. Today those bulbs still make you choose at commissioning time. The firmware update that flips on concurrent operation is promised “later this year.”
My first reaction was that this is a marketing slide. My second reaction, after reading how the silicon actually does it, was more interesting: it is real, it is clever, and it quietly changes what “my device” means.
Why one radio can do this at all
Zigbee and Thread are not rival radio technologies. They are rival network layers sitting on the same 802.15.4 PHY, both using OQPSK modulation in the same 2.4 GHz band. That shared foundation is the whole trick. Silicon Labs’ own multiprotocol documentation spells out the easy case: if both networks happen to sit on the same 802.15.4 channel, a single radio can receive Zigbee and Thread frames concurrently with no time slicing at all. It is just listening. The upper layers sort out which stack gets the packet.
The hard case is the realistic one, because your Zigbee coordinator and your Thread border router almost certainly did not pick the same channel. For that, the chips use what Silicon Labs calls concurrent listening: the radio flips between two channels on the order of tens of microseconds, just long enough to sniff for a preamble, and parks on whichever channel is actually talking. It is not the coarse time-slicing that Bluetooth-plus-Thread devices have to do, because Bluetooth uses GFSK and genuinely requires the radio to change modes. Two 802.15.4 networks are close enough cousins to share.
There is a cost, and it is documented rather than hidden. Silicon Labs notes that enabling concurrent listening degrades PHY performance slightly, with 802.15.4 sensitivity dropping to around −98 dBm. That is a general figure for the feature, not a measurement of any specific Hue bulb, and I would not pretend otherwise. But directionally it is what you would expect: a radio that spends part of its life looking somewhere else hears a little less well. In a dense mesh with a mains-powered bulb every four metres, a decibel or two is noise. At the ragged edge of coverage — the garage, the far end of a concrete corridor — a decibel or two is the difference between a device that responds and a device you have to go and reset.
The channel-planning problem nobody wants to talk about
Here is the part that actually worries me, and it has nothing to do with Hue. Everything above lives in 2.4 GHz. My Zigbee network is on channel 20 specifically because it sits in a gap between the Wi-Fi networks my neighbours run, and finding that gap took an evening with a spectrum scan and a bad mood. A Thread border router commissioning itself onto a channel of its own choosing is one more radio competing for the same air.
Until now, a dual-stack device was a device that had picked a side, so its traffic all went to one place. A bulb that is genuinely live on two 802.15.4 networks is emitting for both, answering both, and being polled by both. Multiply by thirty bulbs in a well-lit flat and the aggregate is not nothing. I have already written here about eight months I wasted blaming my walls for interference that turned out to be a USB 3 port. I am not eager to hand myself a new class of ambiguous RF problem to misdiagnose.
What it actually solves, and for whom
Be fair about the problem being fixed. Hue’s differentiated features — dynamic scenes, entertainment sync, the gradient stuff that genuinely does look good — live in the Hue Bridge and speak Zigbee. Matter gives you cross-ecosystem control and easy setup, but a Matter-over-Thread Hue bulb was a dumber Hue bulb. Signify’s CTO for Hue, George Yianni, framed the collaboration as supporting “the interoperability consumers want through Matter while preserving the advanced capabilities” of the Hue ecosystem. Stripped of the press-release grammar, that is an honest description of a real trade-off customers have been complaining about for three years.
And for someone in a mixed household — an Apple Home user married to a SmartThings user, say — being able to bind the same bulb into Hue’s own world and into a Matter fabric without buying two bulbs is a genuine improvement. This is a good feature. It is aimed at people who are not me.
What I will actually do about it
Nothing, for now, and I want to be precise about why rather than waving the local-first flag.
My bulbs are joined directly to Zigbee2MQTT. There is no Hue Bridge in this flat, which means the entire premium half of the pitch — the scenes, the entertainment sync, the Hue app experience — is something I have already declined. What CMP offers me is the ability to also put a bulb into a Matter fabric I do not run, on a border router I do not own, for control I already have through Home Assistant. The value is genuinely zero here. That is not a criticism of the feature; it is just a reminder that “more connectivity” is only a benefit if you wanted the second connection.
The part I will be watching is the security surface, because it is new. A device that maintains simultaneous membership in two networks has two sets of credentials, two commissioning paths, and two ways to be talked to. Whether a Matter fabric can be joined to one of these bulbs without the Zigbee network noticing — and what a Zigbee2MQTT user would see if it happened — is not something the announcement addresses, and it is the question I would put first if I were reviewing one. My instinct is that Signify has thought about it. My instinct is not evidence, and the industry’s recent track record on default-open commissioning states is not spotless.
So the buying advice stays where it was. If you are building a local-first house, buy the plain Zigbee device, join it to one coordinator, and enjoy having exactly one thing to debug. Concurrent multiprotocol is not a reason to buy and not a reason to avoid — it is a capability that will quietly arrive in silicon you were going to buy anyway, and the interesting question is not whether it works. It is who else gets to talk to your lights once it does.
I will report back when the firmware lands and I can put a scanner on it. Until then: one radio, one network, one thing to blame.
Leave a Reply