Multi-protocol smart home hubs promise a simple thing to the end user — buy one hub, control devices from any ecosystem — but delivering on that promise means the hub has to run several radio stacks simultaneously on shared hardware, translate between fundamentally different device protocols, and keep all of it updatable in the field for years. Each of those is a nontrivial engineering problem on its own; together they define what makes hub design harder than single-protocol device design.
Radio coexistence: several radios, one enclosure, limited spectrum
Zigbee, Thread, and Bluetooth Low Energy all operate in the 2.4 GHz band, and Wi-Fi frequently does too — packing multiple radios that share overlapping spectrum into one compact enclosure creates real interference risk between them. Managing that requires attention at both the hardware and firmware level: physical antenna placement and shielding to reduce radios interfering with each other inside the enclosure, and firmware-level coexistence schemes that coordinate radio timing so that, for example, a Wi-Fi transmission doesn't reliably stomp on a time-sensitive Zigbee packet. Z-Wave operates in a different, sub-GHz frequency band and is largely spared this specific problem, but it still has to share board space, power budget, and antenna routing with the other radios. Getting coexistence wrong doesn't show up in a spec sheet — it shows up as intermittent, hard-to-diagnose device dropouts in the field, which makes it worth getting right at the hardware design stage rather than debugging after volume production.
The abstraction layer: making different protocols look like one thing
Zigbee, Z-Wave, BLE, and Thread each have their own device models, pairing flows, command sets, and ways of representing state — a lock in one protocol doesn't share a data model with a lock in another. The hub's firmware and app-facing software need an abstraction layer that normalizes all of that into a single internal representation of "device capabilities," so the app and any automation logic can treat a Zigbee light and a Z-Wave light the same way without protocol-specific special cases leaking through the whole codebase. This abstraction layer is arguably the core intellectual property of a multi-protocol hub product — get it right and adding support for a new protocol or device type is incremental; get it wrong and every new protocol addition means touching application logic that shouldn't have needed to know about radio-layer details in the first place.
Firmware updates across multiple radio stacks
A hub with several radio stacks typically also has several independently updatable firmware images — the main application firmware plus, depending on the architecture, separate firmware for coprocessors handling specific radio stacks. Update strategy has to account for that: updates need to be sequenced safely (a partial or interrupted multi-image update shouldn't leave the device in a state where one radio stack is newer than another in an incompatible way), and the device needs a reliable rollback path if an update to any one stack fails. This is meaningfully more complex than updating a single-firmware-image device, and it's a design decision that has to be made in the initial architecture — retrofitting safe multi-image OTA updates onto a hub that wasn't built for it is a much harder problem than designing for it from the start.
Practical takeaway
A multi-protocol hub earns its "just works" reputation through unglamorous engineering — radio coexistence at the hardware level, a clean abstraction layer in firmware, and a disciplined multi-image update strategy. See our embedded hardware work for how we approach hub-class product architecture.