That would be interesting and a game changer for sure.
Sorry for the confusion - I meant, “I hope we can pull off the same awesomeness of Zigbee binding with Z-Wave Associations”
In other words, the fact that we could bind a switch to 13 Hue bulbs was amazing and fast. I’d like to replicate that with Z-Wave somehow (currently, we’ve only been able to associate 5 devices tops and it has a, “popcorn” effect when you turn them on).
Hope that makes sense?
Oh, I see. It seems like the obvious solution to that, from a zwave protocol perspective, is multicast. I don’t think I’ve ever seen a device like a switch implement the ability to send multicast messages, but I don’t see why you couldn’t.
For clarification to a non-tech guy, there are two kinds of zwave messages: unicast and multicast.
A unicast message has one sender and one recipient.
A multicast message has one sender and multiple recipients.
So currently, if I set up my inovelli switch with node id 1 to be associated with nodes 2, 3, 4 and 5, when I do something on the switch, it has to send 4 separate zwave messages, one after the other. Each of the four other nodes “hears” all four messages, but doesn’t “listen” to 3 of them because they’re addressed to someone else.
Sending a single multicast message would allow the switch to send one message with all four nodes listed as recipients, so they’d all “listen” when they “hear” the message, and all turn on/off/whatever.
Analogy:
You’re in a room with your two children, Alice and Bob. You want them to clean up the toys.
Unicast is saying:
“Alice, go clean up the toys.”
“Bob, go clean up the toys.”
Multicast is saying:
“Alice and Bob, go clean up the toys.”
It seems like the bigger challenge to this sort of direct zwave control is availability of zwave smart bulbs. Yours is pretty much the only one I’m aware of on the market, while zigbee bulbs are widespread.
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.
If my memory serves me well (usually doesn’t) - I think there was an Iris product that was like this. Let me try to find it.
Edit: here it is - [OBSOLETE] Iris Smart Plug (3210-L) Zigbee Plug with Z-wave Repeater - Community Created Device Types - SmartThings Community
Associations are the equivalent to zigbee bindings, not multicast. Multicast is from the hub to many switches, associations are between mesh devices.
Do we know you can’t use multicast for associations? I don’t see why the two would necessarily be mutually exclusive.
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!
Exactly what I’m thinking.
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.
Home Assistant ppl – question for you guys.
What instances would you like us to write instructions for (ie: Z-Wave JS, Z-Wave JS to MQTT, etc)?
I’m starting to write the manual and with the Blue Series we had instructions for both ZHA and Zigbee2MQTT, but I’m not as familiar with the Z-Wave portion of HA.
Thanks in advance!
I’m pretty sure everyone is using the zwave2mqtt module at this point, even if they’re not using MQTT, since it reportedly works better.
FYI zwavejs2mqtt was just renamed to zwave-js-ui
Zwavejstomqtt seems to be the preferred Z-Wave integration in the HA community these days…
Awesome thanks – I knew I saw that somewhere, but couldn’t remember. Thanks for confirming!
So, just so I’m clear, there is Z-Wave JS (the built-in instance) and Z-Wave JS UI (formerly Z-Wave JS to MQTT)?
You got it.
They really went crazy with the naming convention, didn’t they 
Z-Wave JS integration - Part of HA Core
Z-Wave JS addon - This is what actually talks to your zwave network and communicates status to the integration
Z-Wave JS UI - GUI on top of ZWave JS addon
if you think that’s crazy, just wait a few more days and see them change it all over again!
Rule #1 of HA is to never screenshot anything, because it will all be rearranged in the next monthly release…
Should’ve used Eric’s face
