Not one of the original commenters, but I’m always in.
I was thinking about this and a few other things that frequently get discussed here. And this is more for @EricM_Inovelli to think about for the next generation of stuff. But it’s a possible answer to this question also.
Are you guys familiar with the Z-Uno? It’s a Z-Wave Arduino board, basically a little dev board with a bunch of GPIO pins and a Z-Wave radio. You define in software what command classes it exposes, and what they do, and it then can be included in the Z-Wave network.
That’s not the point though. The point is it’s a Z-Wave chip with two levels of code running on it. One is the base Arduino emulator that includes the ZDK and whatnot, the other is the user-provided Arduino sketch. The base code ensures it stays within Z-Wave specs no matter what the sketch says to do, and prevents a sketch from doing anything ‘bad’ on the Z-Wave side. Apparently both can be updated OTA.
I know from previous threads that Inovelli has considered open sourcing the switch firmware. So what I’m suggesting, is something like the Z-Uno- Inovelli writes a core code that handles the Z-Wave stuff, but then all the switch’s actual behaviors are dictated with a simpler, interpreted, user-editable script.
The switch would then ship with the base code and a userscript that accomplishes all the behaviors the switch does now. But that would be editable by the user.
Result would be if someone wanted a specific behavior- like let’s say they wanted their light to be at 0%, 50%, or 100% and never any other value, they could rip out the parts of that script that do the ramp dimming and replace them. Someone with a smart bulb could make a script that on initialization sets the load to 100%, then delete all the lines that sync the LED bar to the load. Someone with a unique setup could make the switch control one device and the LED bar represent something totally different. And the ramping could be tweaked far more easily to accommodate each bulb- for example if a bulb starts at 4% power, but is 50% bright at 20% power, and then gradually brightens the rest of the way, a customer could make a custom ramp for that bulb that would dim it up/down smoothly and evenly.
etc etc.
Basically, all the cool special use cases Inovelli is famous for supporting, and more, could be supported without Inovelli having to write code for every one of them. It’d take the Inovelli switch and put it customization wise much closer to a high end Crestron/Lutron product.
This is probably not possible with the 500 series chip due to space limits. But it’s something to consider for the next version.
