Question on development process

[jlambert]

I was exploring red-series Inovelli switches for a new build and was looking at the different products available for the different series. Reading through the forum, I got the impression that the development process for the different devices on protocols was completely independent from each other. Having a kindergarten-level knowledge of what goes into making this hardware (and a software development background), I believe I have some inaccurate assumptions of the process - and am just curious why my assumptions are inaccurate.

My assumption was that there were 4 major components that fit together:

a “common” electronic block that is responsible for working with the load itself

• The physical device (excluding electronics) - case, button(s), LEDs - most of the plastic/metal.
• A board/section of a board responsible for managing the load itself, powering the LEDs/sensors/DC for the device itself
• A board/section of a board responsible for the protocol/interface (zwave/zigbee/thread) communications, your firmware, etc
• A common (electrical) contract between the two

If I think about the on/off switch as an example, I would have assumed that the to add one for a new protocol would be to “just” (I know it’s not a 10 minute job, but not sure what other word to use) replace the protocol block with a different one making sure it met the same interface contract.

Similar thing with the multi-button controllers, my assumption would be that the signal from the buttons (as well of the control needs for the LEDs, sensors, whatever else) would all be identical allowing for that portion of the board to be the same “generic block.” Most of the radio/protocol components would be “generic” and a contract for the physical electrical connection between the two, it didn’t seem like it was being developed that way though.

I’m sure there’s lots of incorrect assumptions, lack of knowledge, and kindergarten-level terms in there, and curious what they if you don’t mind sharing. You’ve been doing this a long time and would love to understand more.

[Lance_Inovelli]

@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.

[jlambert]

Thank you - that’s a great answer and one I can understand! I knew you wouldn’t be doing more work than was needed, but didn’t have enough knowledge to really understand why.