Daniel sent us this one, and it's a layered question. He's been looking at professional building automation — Modbus, KNX, that world — and basically concluded what a lot of us conclude: the cost gap versus consumer gear is enormous and you can't even figure out where to buy the stuff. So he's asking, if we accept that industrial OT is off the table for a DIY smart home, how well do the consumer networks we actually use — Zigbee and Matter — scale to a proper house? Say a two-story place with outdoor coverage.
The deeper question he's asking, which I think is the real meat here, is whether we should be trying to mimic the professional topology. The hotel model where you bundle devices at the room level, then floor level, then central brain. He wants to know which network lets you do that, or how you'd build it.
By the way, DeepSeek V four Pro is writing today's script. Which feels appropriate — precision and discipline for a topic about network topologies.
Let's dig in, because Daniel's instinct about the cost gap is dead right and I want to put some numbers on it before we get to the scaling question.
I love when you put numbers on things. It's my second favorite thing you do, after the archery.
I haven't picked up a bow in weeks and you know it. But the numbers: a basic KNX push-button wall switch — just two rockers, four buttons — runs somewhere between eighty and a hundred and twenty euros. That's one switch. The equivalent Zigbee switch from a decent brand like Aqara or Sonoff? Fifteen to twenty-five euros. And that's before we talk about the KNX power supply unit, which is another two hundred to three hundred euros, or the IP interface to actually program the bus, which is another two hundred fifty to four hundred.
You're into what, six hundred euros before you've turned on a single light.
And Daniel's second point is the one that really kills it — procurement. KNX devices are sold through certified system integrators and electrical wholesalers. You can't just open Amazon and order a KNX actuator. Even if you find a supplier willing to sell to an individual, you need the ETS software to commission the bus, and that's a licensed product — ETS Professional runs about a thousand euros for the full version.
I did some poking around on this too. There's a weird gatekeeping dynamic where the manufacturers don't want to deal with end users. Not because the technology is dangerous — it's low voltage bus wiring — but because their business model assumes an installer who's done the KNX certification course. The whole ecosystem is built around the assumption that the person buying the parts is not the person living in the house.
That's the fundamental architectural difference between industrial OT and consumer IoT, before we even get to the technical protocols. One assumes a professional integrator, the other assumes the occupant. Daniel's conclusion — put it in the "probably not the way to go" category — is exactly right for a DIY context, even with a generous budget. The budget isn't the only barrier. The ecosystem is designed to exclude you.
Alright, so we've buried KNX. Rest in peace, elegant German engineering. Now let's talk about what Daniel actually wants to build. He's asking about scaling Zigbee and Matter across a house that's maybe a hundred to a hundred fifty square meters, two stories, with outdoor coverage. And he's noticed this new SM Light multi-radio coordinator that combines Zigbee, Z-Wave, and Matter radios in one box.
The SM Light SLZB hyphen O Six M. It's a PoE-powered coordinator with an Ethernet interface, and it packs a Texas Instruments CC2652P7 for Zigbee and Thread, plus a Silicon Labs EFR32MG21 for Z-Wave, all on one board. It's been getting genuinely good reviews, and Daniel's right — people have been asking why nobody built this for years.
What took so long?
Partly it's a radio coexistence problem. Zigbee and Thread both operate on two point four gigahertz, and Z-Wave operates on sub-gigahertz frequencies — eight hundred sixty-eight megahertz in Europe, nine hundred eight in the US. Putting multiple radios on one board without them interfering with each other requires careful antenna design and shielding. But the bigger reason is that the chipset manufacturers have been siloed. Silicon Labs makes both Zigbee and Z-Wave chips, but they historically sold them as separate product lines with different SDKs. Nobody was asking for a combo because the software stack assumed one radio, one network.
SM Light did the integration work that the silicon vendors didn't bother with.
And they put it behind Ethernet, which matters more than people realize. USB coordinators have been the default for Home Assistant setups forever, but USB means your coordinator is physically tethered to the host machine. If your Home Assistant box is in a network cabinet in the basement, your Zigbee network's starting point is in the basement. With PoE, you can place the coordinator anywhere you can run a Cat five cable — ceiling mount it on the top floor, put it centrally in the house. That alone solves a chunk of the range problem before we even talk about mesh hops.
Let's talk about those mesh hops, because that's where Daniel's question gets interesting. He's asking whether a single Zigbee coordinator can cover a two-story house with outdoor devices, or whether latency and backhaul become a problem at that scale.
Let's get specific about how Zigbee mesh routing actually works. A Zigbee network uses a routing protocol called AODV — Ad hoc On-Demand Distance Vector. When a device wants to send a message to a destination it doesn't have a route for, it broadcasts a route request. Neighboring routers rebroadcast it until it reaches the destination, which sends back a route reply. The route is then cached for future use.
The catch Daniel mentioned — only mains-powered devices act as routers. Battery-powered end devices don't participate in the mesh.
Zigbee defines three device types: coordinator, router, and end device. The coordinator is exactly one per network — it forms the network and manages security keys. Routers are mains-powered devices that forward messages and can also be application endpoints — your wall switches, your smart plugs, your powered sensors. End devices are battery-powered and only talk to their parent router, never forward traffic.
The mesh depth depends entirely on how many mains-powered devices you've got and where they're placed.
Here's the number that matters: Zigbee supports a maximum of thirty-two hops. That's the theoretical limit in the spec. In practice, nobody should be anywhere near that. The Zigbee Alliance's own deployment guidelines recommend a maximum of five hops for reliable performance. Beyond five hops, latency becomes noticeable and the probability of a route failure increases because you're chaining through multiple devices, any of which could be temporarily busy or have a weak link to its neighbor.
Five hops in a house. Let's do the math on what that actually means for coverage. A typical Zigbee router indoors has a reliable range of maybe ten to fifteen meters through walls, depending on construction. If you're doing five hops, you're talking about a theoretical reach of fifty to seventy-five meters from the coordinator.
In a hundred-fifty-square-meter house — which is about sixteen hundred square feet — you're well within range even with one or two hops. A two-story house with the coordinator centrally placed might need three hops to reach the farthest outdoor sensor. You're not hitting the five-hop limit in a residential setting unless you're trying to cover a farm or something.
Daniel specifically asked about latency. What does each hop actually add?
A single Zigbee hop adds roughly ten to thirty milliseconds under good conditions. The radio transmits at two hundred fifty kilobits per second, and the routing overhead per hop includes the time to receive the packet, check the routing table, and retransmit. So five hops is maybe a hundred to a hundred fifty milliseconds of added latency on top of the initial transmission. For turning on a light, that's imperceptible. For a door lock or a security sensor, it's still fine. Where it becomes noticeable is if you're doing something like streaming a firmware update to a device five hops away — but that's a background operation anyway.
The short answer to Daniel's first question is: yes, Zigbee scales fine to a two-story house with outdoor coverage, assuming you've got enough router devices placed sensibly. The mesh will form, latency won't be a problem, and a single coordinator can handle it.
With one caveat. A single Zigbee network has a hard limit of — depending on the coordinator — somewhere between thirty-two and two hundred direct children, and the total network size is theoretically sixty-five thousand nodes, but real-world coordinators start getting flaky above two hundred devices. For a typical house, that's way more than anyone would install. But if you're the kind of person who puts a Zigbee sensor on every window, every door, every light switch, every outlet, plus motion sensors in every room and temperature sensors everywhere, you could theoretically bump into that limit.
I've seen your Home Assistant dashboard. You're not far off. Alright, let's move to the second network Daniel asked about: Matter. And this is where the topology question gets really interesting, because Matter has a fundamentally different approach to scaling.
Matter over Thread is what we're really talking about here. Matter is the application layer — it defines how devices communicate and interact. Thread is the network layer — it handles routing and the mesh. And Thread is architecturally different from Zigbee in ways that directly address Daniel's question about the hotel-style topology.
Walk me through it. What makes Thread different?
Thread uses IPv6 natively. Every device on a Thread network has an IPv6 address. That sounds like a small detail, but it changes everything about how the network routes traffic. Instead of Zigbee's AODV routing, Thread uses a distance-vector routing protocol that maintains routes proactively. The network knows its topology at all times, rather than discovering routes on demand.
It's more like how the internet routes packets than how Zigbee builds ad hoc paths.
And here's the key piece: Thread has a concept called a Border Router. A Border Router is a device that sits at the edge of the Thread mesh and connects it to the wider IP network — typically your Wi-Fi or Ethernet LAN. A Thread network can have multiple Border Routers. They're not competing coordinators; they all participate in the same mesh and provide redundant paths out to your IP network.
If I have a Border Router on the top floor and another on the ground floor, and one fails, the mesh re-routes through the other?
And this is the architectural answer to Daniel's question about hotel-style topology. In a professional building automation system, you have floor-level controllers that aggregate room-level subnets and then connect upward to a building management system. Thread with multiple Border Routers gives you a version of that. The mesh itself is the room-level and floor-level network, and the Border Routers are the aggregation points that connect to your central brain.
It's not quite the same as the hotel model, is it? In the hotel model, each room controller has local logic. If the central brain goes down, the room still works. A Thread mesh with Border Routers is still a flat network — all the devices are on one logical network, and the Border Routers are just gateways to IP.
That's a fair distinction. The hotel model distributes control logic. Thread distributes connectivity but not control logic. Your Home Assistant instance is still the single brain. If it goes down, your Thread devices don't have local fallback logic.
Unless you're using Matter's binding feature, which does allow some direct device-to-device communication. A Matter light switch can be bound directly to a Matter bulb so that the switch works even if the controller is offline.
Right, and that's worth highlighting. Matter supports what's called "direct device-to-device communication" through bindings. A binding is a persistent relationship between two devices that works at the network level. Once bound, the switch talks directly to the bulb over Thread without routing through the Border Router or the controller. That's not quite a room-level controller with its own logic, but it's the consumer version of distributed resilience.
If Daniel wants to emulate the hotel topology within consumer IoT, what's the closest he can get?
I'd build it like this. Use Matter over Thread as the primary network for the house. Deploy multiple Thread Border Routers — at least one per floor, maybe one in the outdoor area if you can get power and weather protection. These can be dedicated devices, or they can be devices that happen to include Border Router functionality. Apple HomePod Mini, Google Nest Hub, the newer Echo devices — they all have Thread Border Routers built in. But if you want to stay vendor-neutral, you can use a Home Assistant SkyConnect or the SM Light coordinator in Thread mode.
Then for the room-level clustering Daniel was talking about?
That's where you get creative with how you organize devices. In Home Assistant, you can group devices by area — kitchen, living room, bedroom — and those areas can be used to define automations. But the physical network doesn't enforce the grouping. If you wanted actual network-level segmentation, you'd need multiple Thread networks with separate PAN IDs, and that gets messy fast. The practical answer is: use the software layer for room-level organization, and use the physical mesh for reliable connectivity.
There's a middle ground. In a larger house, you could run multiple Zigbee networks on different channels — one per floor — each with its own coordinator, all feeding into the same Home Assistant instance. That gives you network-level segmentation without the complexity of trying to partition a single mesh.
That's actually a pattern I've seen people use. If you've got a Zigbee coordinator on channel eleven for the ground floor and another on channel twenty for the top floor, they don't interfere with each other. Home Assistant handles them as separate integrations. Devices on the ground floor mesh don't need to route through top-floor routers, so you reduce hop count and improve reliability. The downside is you lose the benefit of a single large mesh where a device on one floor can route through a device on the other floor if its direct path is blocked.
In a house, if your direct path is blocked on the ground floor, a top-floor router probably isn't helping you anyway. The walls are in the way.
And that's the practical reality: in a residential setting, the mesh doesn't need to be a single flat network. Segmenting by floor is a perfectly valid strategy, and it mirrors the professional approach of floor-level controllers. You're not distributing control logic, but you're distributing the network fabric.
Let's talk about the outdoor piece separately. Daniel mentioned wanting outdoor Zigbee devices. Outdoor is hard for a bunch of reasons — range, weather, the fact that your walls attenuate the signal.
Outdoor Zigbee works, but you need to think about your router placement. The ideal setup is a mains-powered router physically located outside — something like a Zigbee smart plug in a weatherproof enclosure, or a purpose-built outdoor Zigbee switch. That router becomes the bridge between your indoor mesh and your outdoor devices. Without it, your outdoor end devices are trying to connect through your exterior walls, and that's a losing battle at two point four gigahertz.
What about the temperature range on these things?
Most consumer Zigbee devices are rated for indoor use only — typically zero to forty degrees Celsius. If you're putting a smart plug outside in a climate that gets below freezing, you need to check the specifications. Some devices are rated for negative twenty to forty-five, but you have to look for them. Or you put them in an enclosure that provides some thermal buffering.
Alright, let's pull this together. We've established that Zigbee scales fine to a two-story house, that latency isn't a problem at residential distances, and that Matter over Thread with multiple Border Routers gives you a more resilient topology that looks a bit more like the professional model. But I want to go back to something Daniel said that I think is the real insight: the dominant assumption in consumer IoT is one brain, everything comes back to it.
The professional world assumes distributed logic. That's the philosophical split.
Does that actually matter for a house? Hotels need distributed logic because they have hundreds of rooms and they can't have a single point of failure that takes down the lighting in every guest room. A house has, what, five to ten rooms? If Home Assistant goes down for five minutes while you reboot it, you're mildly inconvenienced, not facing a hotel full of angry guests.
That's the pragmatic answer. But there's a subtler point. The "one brain" model creates a dependency that gets more annoying as your device count grows. Every time you add a device, you're adding another thing that has to be configured in the central brain, assigned to a room, added to automations. Daniel mentioned how much time can be wasted just identifying what room a device belongs to. That's a real friction point.
The professional model solves that by making the room the unit of configuration. You don't configure individual devices; you configure the room controller, and the devices in that room are its concern.
We're starting to see glimmers of this in the consumer space. Home Assistant's area model is one approach. Matter's multi-admin feature, where a device can be controlled by multiple controllers simultaneously, is another step in that direction. But we're a long way from a consumer product that says "this is a room controller, plug it in, pair the devices in this room to it, and it handles the rest.
Which brings me to SM Light's multi-radio coordinator. Daniel mentioned it as an example of consolidation, but I think what's interesting about it is that it points toward a different architecture entirely. If you've got one device that can run Zigbee, Z-Wave, and Thread simultaneously, connected over Ethernet and placed centrally in the house, you're essentially building a single network appliance that handles all your IoT radios. That's not distributed logic, but it's a step toward treating the IoT network as a separate infrastructure layer from the controller.
PoE is the unsung hero here. Power over Ethernet means you're not dependent on USB, you're not dependent on Wi-Fi for the backhaul, and you can place the coordinator exactly where it needs to be for optimal radio coverage. You run one Cat six cable to the ceiling of your top-floor hallway, mount the coordinator there, and you've got a central radio point that isn't in the basement next to your server.
I want to push on that, though. Is a single central radio point actually better than multiple coordinators spread around the house? If I've got a two-story house and I want outdoor coverage, wouldn't I be better off with a Zigbee coordinator on each floor, each with its own mesh, rather than one central coordinator trying to reach everything?
It depends on your device density. If you've got enough mains-powered routers on each floor, a single well-placed coordinator can absolutely cover a two-story house. The mesh does the work of extending the network. The coordinator doesn't need to reach every device directly — it just needs to reach the nearest routers, and they handle the rest.
You're adding hops, and we talked about hop count.
In a two-story house with the coordinator on the top floor, a device on the ground floor is maybe two hops away — coordinator to a top-floor router, that router to a ground-floor router, that router to the end device. That's three hops total, well within the five-hop recommendation. Outdoor adds another hop if you've got an outdoor router.
What about interference? Two point four gigahertz is crowded. Wi-Fi, Bluetooth, microwave ovens, Zigbee, Thread — they're all fighting for the same spectrum.
This is a real problem that people don't take seriously enough. Zigbee uses sixteen channels in the two point four gigahertz band, numbered eleven through twenty-six. Wi-Fi channels one, six, and eleven are the most commonly used, and they overlap with Zigbee channels eleven through twenty-two. If your Zigbee network is on channel eleven and your Wi-Fi is blasting on Wi-Fi channel one, they're overlapping and you'll see packet loss.
Channel selection matters.
It matters enormously. The standard advice is to put Zigbee on channels fifteen, twenty, or twenty-five — these fall between the main Wi-Fi channels and avoid the worst of the interference. Thread uses the same two point four gigahertz spectrum, so the same advice applies. And if you're running both Zigbee and Thread in the same house, you need to put them on different channels.
Which the SM Light coordinator presumably handles.
You configure it. It doesn't auto-negotiate between the different radios. You need to know what channels your Wi-Fi is using and pick non-overlapping channels for Zigbee and Thread. It's one of those things that makes consumer IoT harder than it should be — the average person doesn't know what a radio channel is, and they shouldn't have to.
Daniel is not the average person. He's the kind of person who reads spec sheets and asks about mesh hop latency. So let's give him the topology playbook he actually asked for.
If I were building a two-story house with outdoor coverage, using consumer IoT gear, with a generous budget but not KNX-generous, here's what I would do. Network backbone: Ethernet. Run Cat six to every room, and especially to ceiling locations on each floor and one outdoor-adjacent location. PoE switch in a central networking cabinet. For the coordinator: SM Light SLZB hyphen O Six M, PoE-mounted on the top-floor ceiling, running Zigbee on channel twenty and Thread on channel twenty-five. Z-Wave on the European or US sub-gigahertz frequency — no channel conflict there since it's in a completely different band.
For the mesh?
Deploy mains-powered Zigbee routers on each floor — smart plugs are the cheapest way to do this, but in-wall switches are cleaner. Aim for at least two router devices per floor, placed to create overlapping coverage. For the outdoor area, a weatherproof Zigbee smart plug or an outdoor-rated switch that acts as a router. All battery-powered sensors become end devices that connect to the nearest router.
The Matter side?
For Matter over Thread, deploy at least two Thread Border Routers — one on each floor. These can be dedicated devices or they can be integrated into something you already have, like a smart speaker. If you're using Home Assistant, the Home Assistant Connect ZBT hyphen One or the SkyConnect dongle in Thread mode can serve as a Border Router. The key is redundancy: if one Border Router goes down, the Thread mesh routes through the other.
You've got two separate mesh networks — Zigbee and Thread — both running in parallel, both covering the whole house. Why not just pick one?
Because device availability is still fragmented. Some of the best sensors are Zigbee-only. Some of the best locks are Thread-only. Matter is the future, but Zigbee has a fifteen-year head start in terms of device ecosystem. Running both networks gives you access to the widest range of devices. And with a multi-radio coordinator, you're not adding much complexity.
Z-Wave is the third network on the SM Light coordinator, and it's worth having as an option. Z-Wave operates at sub-gigahertz frequencies, which means better wall penetration and less interference. It's also a fully interoperable standard — every Z-Wave device is certified to work with every Z-Wave controller, which is not something you can say about Zigbee. The downside is that Z-Wave devices are more expensive than Zigbee equivalents, and the ecosystem is smaller. But for critical devices like door locks and smoke detectors, Z-Wave's reliability advantage is worth the premium.
The playbook is Ethernet backbone, multi-radio coordinator placed high and central, Zigbee for the bulk of sensors and switches, Thread for Matter-compatible devices and future-proofing, Z-Wave for security-critical devices. And all of it feeding into Home Assistant as the single brain, with areas and automations doing the room-level organization.
That's the practical answer. It's not the hotel model. It doesn't distribute control logic. But it gives you a network that scales reliably across a two-story house with outdoor coverage, and it gives you device flexibility that a single-protocol setup can't match.
I think there's a deeper point here that Daniel is circling around, which is that the consumer IoT industry has been weirdly resistant to the idea that houses might need infrastructure. The professional world assumes infrastructure — bus wiring, floor controllers, managed networks. The consumer world assumes you'll just stick a hub somewhere and everything will magically connect.
That assumption works for a sixty-five-square-meter apartment. It breaks down when you scale to a house.
And the fix isn't to adopt KNX. The fix is to treat your consumer IoT setup like infrastructure. Place your coordinator deliberately. Think about router placement and channel selection. Do the things that a professional integrator would do, but with gear you can actually buy and configure yourself.
The SM Light multi-radio coordinator is a step in that direction. It's a device that acknowledges that your IoT network is infrastructure, not a peripheral. You plug it into your network rack, you power it over Ethernet, and it becomes a permanent part of your house's connectivity layer.
It's a hundred bucks, not a thousand euros.
That's the sweet spot. Professional-grade thinking, consumer-grade pricing. Well, prosumer-grade pricing, but you know what I mean.
Alright, let's talk about where this is all heading, because there's an interesting convergence happening. Zigbee and Matter over Thread are both mesh networks based on IEEE eight zero two fifteen four, the same physical layer. The chipsets are increasingly shared. The SM Light coordinator runs both on the same hardware. How long before we stop thinking of them as separate networks and just think of them as the IoT radio layer?
That's where the industry is going, but it's not there yet. The Zigbee Alliance rebranded to the Connectivity Standards Alliance and launched Matter specifically to solve the interoperability problem. But Zigbee isn't going away — there are billions of Zigbee devices in the field, and the standard is still actively developed. Zigbee Pro twenty twenty three added new security features and improved onboarding. It's going to coexist with Matter for years.
The multi-radio coordinator is not a transitional product. It's the permanent answer.
I think so. The idea of a single-protocol smart home was always a fantasy. The real world has Wi-Fi, Zigbee, Z-Wave, Thread, Bluetooth, and probably something else next year. The smart move is to build a network layer that can handle all of them.
Which brings us back to Daniel's original question about the hotel topology. The hotel model distributes control logic to room-level controllers. We've been talking about distributing the network layer with multiple Border Routers and multiple meshes. But what about distributing the control logic? Is there a consumer-friendly way to do that?
Not really, and this is where the consumer IoT industry has a genuine gap. Home Assistant is the closest thing to a distributed control system for consumers, but it's still a single instance. You can run multiple Home Assistant instances and link them with the remote Home Assistant integration, but that's an advanced setup that most people won't attempt. There's no off-the-shelf product that says "I am a room controller, pair me with a central brain.
Maybe there shouldn't be, for a house. The complexity of distributed control logic only pays off when you have dozens of rooms and hundreds of devices. For a two-story house, a single Home Assistant instance with a well-designed network layer is more than sufficient.
The network is where you should invest your architectural thinking. The control logic can stay centralized.
Let's land this. Daniel asked three questions. One: can Zigbee scale to a two-story house with outdoor coverage? Yes, easily, with properly placed routers and sensible channel selection. Two: does Matter over Thread handle scaling better? Yes, in some ways — multiple Border Routers give you redundancy and better backhaul, and the IPv6 routing is more robust than Zigbee's AODV. Three: how would you emulate the hotel topology in consumer IoT? You can't fully, but you can approximate it with a multi-radio coordinator, Ethernet backbone, and network segmentation by floor.
The SM Light multi-radio coordinator is the hardware that makes this approach practical. PoE-powered, centrally placed, running Zigbee, Thread, and Z-Wave from a single device.
One thing we haven't mentioned: the software side of this is Home Assistant, and it's worth noting that Home Assistant's multi-protocol support is impressive. It handles Zigbee through ZHA or Zigbee2MQTT, Z-Wave through Z-Wave JS, Matter through the Matter integration, and it presents them all as a unified device model. The network layer is fragmented by necessity, but the control layer is unified.
That's the right split. Let the network be heterogeneous. Let the control be homogeneous. That's the consumer version of the professional model, and it works.
I think we've earned our fun fact.
Now: Hilbert's daily fun fact.
Hilbert: In the nineteen fifties, astronomers operating a radio telescope in Chile's Atacama Desert discovered that the instrument would periodically detect a strong signal at exactly the same time every day. After weeks of investigation, they traced it to a faulty microwave oven in the observatory's kitchen that a technician used to heat his lunch at precisely twelve fifteen.
The universe was trying to tell them to eat.
The cosmos wanted a hot pocket.
This has been My Weird Prompts. Our producer is Hilbert Flumingtop, and our prompts come from Daniel. If you enjoyed this, leave us a review wherever you listen — it helps.
We're at myweirdprompts dot com, and we'll be back soon.
