From a “who would buy this” perspective, a dual-radio switch (zigbee + z-wave) could be attractive to companies for which security is a priority, with the idea that z-wave is the primary network, and has strong security, but you also have a second radio for sending commands directly to the widely-available zigbee smart bulbs.
And because zigbee operates on 2.4GHz, the zigbee radio/SoC could potentially also speak bluetooth, allowing for a configuration process using a phone app that wouldn’t necessarily require a hub.
This is still a wild, difficult idea, though. I have no idea if it’s any good or not.
This is the big thing to me. Zwave is theoretically more stable, secure, longer range and whatnot, but who makes
color temperature shifting zwave can lights? PAR38, BR30, GU10, e12? Hue (and other ZigBee manufacturers) does all of these and, until I am 1000% confident in my hub not going down for anything less than a full power outage, I’m going with binding/associations for safety, sanity, and WAF. Today, that means ZigBee.
I should say I have a lot of Red dimmers and bulbs associated to each other, but the lack of bulb types, the popcorn effect, and 5 association limit make it not the future for me. Blue dimmers and hue lights will be the bulk of my house.
Project Update: We just placed the deposit for 10k+ switches (that’s units, not dollars – a small test order).
We’ll be receiving the official timeline shortly. Most of the ground work is completed on this one, so really it’s a matter of writing the firmware and learning the 800 Series SDK. Hopefully there aren’t too many kinks with existing hubs – we’ll really be learning quickly if Z-Wave is truly interoperable!
An association is a relationship between node A and node B which results in node A sending messages to node B when something happens, the details of which are controlled by the firmware in node A. There are a handful of zwave command classes (Association, Association Group Information, Association Command Configuration, Multi Channel Association) which contain commands to be used by the controller to configure which nodes (and endpoints) are associated with which other nodes, and how.
A multicast z-wave message is a zwave message with a sender and multiple recipients. I’m not aware of anything in the zwave spec that says that controllers are the only nodes which can send multicast messages. So my suggestion was that you build a node which sends multicast messages to its associated nodes.
It’s unclear to me whether this would be compliant with the zwave spec. For S2 encryption in particular, sending multicast messages can be quite tricky (this is one reason why zwavejs only supports unencrypted multicast), and AFAIK multicast to S0 devices is totally unsupported.
Fundamentally, the only way I can see to work around the “popcorn” effect is to send one message to multiple recipients, with very low latency.
My instinct is that since the addressing type (multicast vs singlecast vs broadcast) is at the transport layer, not the command class layer, this just might be possible. But AFAIK nobody has done it yet.