How Do You Choose a Zigbee Module or SoC for a Product Design?

Detailed Explanation

Zigbee SoC selection is a decision that compounds across a product's lifetime — the choice affects firmware toolchain, multiprotocol flexibility, certification path, and per-unit cost simultaneously, so it's worth treating as a deliberate evaluation rather than defaulting to whichever chip a reference design happens to use. For Zigbee protocol fundamentals, see What Is Zigbee?; for the practical coordinator-side setup once hardware is chosen, see how do you set up a Zigbee coordinator with Zigbee2MQTT?.

The Three Practical Selection Factors

Multiprotocol needs. Many current-generation Zigbee-capable SoCs also support Thread and/or BLE on the same silicon, either running one protocol at a time (firmware-selected) or concurrently via a dynamic multiprotocol scheduler. If the product roadmap has any realistic chance of needing Thread (for Matter compatibility) or BLE (for a mobile app commissioning flow) alongside Zigbee, choosing multiprotocol-capable silicon up front keeps that door open as a firmware decision rather than a hardware respin. See Thread vs Zigbee: which should you choose for a new product? for the protocol-level version of this same "keep options open" reasoning.

SDK maturity and toolchain fit. Texas Instruments' SimpleLink SDK and Silicon Labs' Simplicity SDK have genuinely different development experiences — different IDE integrations, documentation styles, and community size — that matter more to development velocity than raw chip specifications in most product timelines. If your team already has experience with one vendor's toolchain, that familiarity is a legitimate factor in the decision, not just a specification comparison exercise.

Cost and power targets for the product category. A commercial building-automation sensor with a modest production volume can absorb a higher per-unit silicon cost for better SDK support and multiprotocol flexibility. A mass-market consumer smart plug produced in high volume is far more cost-sensitive, which is why budget consumer devices commonly use lower-cost RISC-V-based silicon instead.

Chip Comparison

The TI and Silicon Labs options dominate where SDK maturity, documentation, and multiprotocol flexibility matter — coordinator dongles used with Zigbee2MQTT and ZHA are almost universally CC2652-based or EFR32-based for exactly this reason. The RISC-V-based budget options dominate mass-market consumer retail devices where per-unit cost at high volume outweighs development convenience, and are typically shipped with closed vendor firmware rather than exposed to product developers as a flexible SDK target.

Module vs Bare SoC

Beyond the SoC itself, most product designs use a pre-certified module — the bare SoC already integrated onto a small PCB with matching antenna, crystal, and RF layout, carrying its own radio certification. This significantly reduces the RF design and certification burden compared to laying out the bare SoC directly on the product's own PCB. The module-vs-bare-chip decision is largely independent of which underlying SoC you choose — both CC2652R and EFR32MG21 are available as pre-certified modules from multiple module vendors, so certification convenience doesn't need to drive the underlying chip selection.

Design Considerations

• Evaluate multiprotocol needs against realistic roadmap scenarios, not hypothetical ones. Paying for multiprotocol flexibility the product will never use adds unnecessary cost; under-provisioning for a genuinely likely future requirement forces a costly hardware respin.
• Weight SDK and toolchain familiarity honestly in the decision. A team experienced with one vendor's SDK will ship faster on that platform even if a competing chip has marginally better raw specifications on paper. Zeus Design selects and integrates Zigbee, Thread, and multiprotocol wireless silicon based on the specific product's certification, cost, and roadmap requirements.
• Confirm production volume expectations before optimising for per-unit silicon cost. The cost-sensitivity calculus that favours budget RISC-V options only pays off at genuinely high production volumes — at low-to-moderate volumes, the SDK maturity and support advantages of CC2652/EFR32-class silicon often outweigh a small per-unit cost saving.
• Default to a pre-certified module unless there's a specific reason to design with the bare SoC, since the RF layout and certification testing burden of a bare-chip design is substantial and rarely justified outside of very high-volume products where module markup meaningfully impacts unit economics.

Common Mistakes

• Choosing a chip based on a reference design's popularity rather than the product's actual multiprotocol, SDK, and cost requirements. A widely-used chip in hobbyist and DIY circles (often chosen for Zigbee2MQTT/Home Assistant compatibility) may not be the right cost or support profile for a different product category.
• Underestimating the SDK learning curve when switching vendors mid-project — evaluate toolchain fit early, not after committing to a chip based on datasheet specifications alone.
• Designing with a bare SoC to save module markup without budgeting the actual RF layout and certification cost and timeline that decision introduces — the module markup is often cheaper than the incremental engineering and certification cost of a bare-chip design at low-to-moderate volumes.
• Assuming vendor SDK closed-source firmware on budget consumer chips (TLSR8258 and similar) offers the same flexibility as an open SDK — these are typically appropriate for high-volume, fixed-function consumer devices, not for products needing custom firmware development flexibility.
• Choosing multiprotocol-capable silicon and then never actually using the multiprotocol capability, paying an unnecessary cost premium for flexibility the product roadmap never exercises.

For MCU and radio platform selection guidance across Zigbee, Thread, and other wireless protocols, see how to choose a microcontroller for your project.