@jlambert that is a fantastic, high-level structural question.
That is a really insightful breakdown. You’re essentially describing a System-on-Module (SoM) approach. While it makes perfect sense from a software architecture perspective decoupling the business logic of the load from the transport layer of the protocol, hardware development for IoT hits a few physical and economic walls that make this tricky.
Here’s a look at why your assumptions, while logical, run into some real world friction. Smart switches are in such a small box it creates some significant physical constraints and can be very difficult to overcome.
In software, adding a layer of abstraction costs some memory and CPU cycles. In a light switch, abstraction costs physical volume.
To have a common contract or an interface between two boards like a header or pins, you need connectors. Connectors take up massive amounts of space in a standard electrical gang box. the solution to keep the switches thin enough to actually fit in a wall, engineers usually opt for a single, integrated PCB (Printed Circuit Board) where the radio and the load controller share the same real estate.
The SOC (System on a Chip)
In your model, the protocol block is separate. In reality, modern chips like those from Silicon Labs or Nordic are designed to be all-in-one.
The same chip that handles the Z-Wave or Zigbee radio also has the GPIO (General Purpose Input/Output) pins that talk to the LEDs and sense the button presses.
If you separated them, you’d often end up needing two microcontrollers one for the load/LEDs and one for the radio, which increases the cost, power consumption, and heat.
Certification, this is the biggest hurdle. Regulatory bodies FCC, UL, Z-Wave Alliance, CSA for Matter don’t certify a process they certify a specific device configuration.
If you swap a Z-Wave module for a Thread module, the internal electromagnetic interference (EMI) changes. Even if the bottom half of the switch is identical, the new top half might reflect heat differently or change the RF profile, meaning you have to go through the $50k–$100k+ testing and certification process all over again from scratch.
The Firmware is the glue, and while the physical buttons are the same, the way a Z-Wave chip handles a central scene command is fundamentally different from how a Zigbee chip handles an on/off cluster. Because the radio chip is usually the brain of the whole device, the firmware has to be rewritten for the specific architecture of that chip. You can’t easily drop in code from a Z-Wave SDK into a Matter/Silicon Labs SDK.
Summary of the Inaccuracies
-
Assumption: The interface is a simple electrical contract.
-
Reality: The interface is often deeply integrated into the silicon of the radio chip itself to save space and money.
-
Assumption: Components are interchangeable like LEGOs.
-
Reality: Each protocol change usually requires a total PCB re-layout to pass safety (UL) and RF (FCC) certifications.
Inovelli does try to keep the look and feel, the plastics and UI identical across all of our devices but under the hood, each protocol is usually a ground-up engineering effort that takes significant work to create a unified look and feel no matter what protocol you choose. I hope I provided an accurate and detailed enough answer to your question while trying to keep in high level but detailed enough to address what you are asking.