Does Hubitat natively support Zwave multicast? If not directly, could I handle this myself within a groovy app using direct Zwave classes?
Use case: I am developing an application which uses the LED strips on Inovelli LZW31-SN as a user feedback mechanism. While most updates to the LED strips are targeted to 1-3 switches (ie, specifical rooms), I have certain updates that are made simultaneously to all 40+ switches. As you can imagine, doing this as unicast creates a ton of Zwave traffic, and the end result is that it takes a couple of seconds to complete.
While experimenting with my secondary Zwave controller (Zstick + PC controller), I discovered that I could select multiple nodes to direct CONFIGURATION_SET commands towards, and PC Controller would send them as Zwave multicast. When targeting all 41 switches with Zwave multicast messages, the result is observed on all switches immediately & simultaneously rather than taking ~3 seconds.
So with that in mind, are there any mechanisms to do this natively within Hubitat? If no, perhaps I could generate the multicast Zwave frame myself, and send it that way from within a Groovy app? I used a Zniffer to observe the makeup of the multicast frames, and other than needing to reverse engineer the "mask" that is apparently used to declare the destinations in as few bytes as possible, I think I could make that approach work as well.
Expanding on this in a [transparent] attempt to generate a little more interest:
I've found that spewing out 40+ CONFIGURATION_SETs at nearly the same time not only takes a couple of seconds to complete, but it also tends to freeze up Hubitat's ability to send Zwave commands for a period of time. As seems to be typical when I have Zwave pains, the hub can still receive Zwave commands -- just not send. When this occurs it is immediately noticeable in my environment, because I wrote and implemented a motoin lighting app. My motion detectors and switches are Zwave, but the lights are a handful of Philips Hue (Zigbee) hubs via CoCoHue integrations. So when I end up stuck in this behavior the lights will still turn on/off based on motion or switch interaction, but the follow-up attempt to change the LED strip on the Inovelli switch will be significantly delayed or potentially fail altogether.
I've made things a little better by extending the parent app to implement a queueing system for the child app CONFIGURATION_SETs and purposefully adding some time between the Zwave commands. But of course, I'd still like to migrate to using multicast Zwave rather than unicase as that would solve both issues:
Result in immediate execution of commands, and
Avoiding what appears to be an overrun of a buffer somewhere when interacting with Zwave
Perhaps this could be done in a Hubitat driver? I also bought an SiLabs Z-Wave 700 Starter Kit to kick the tires on what options might be available there. Perhaps I could whip something external up to handle sending the Zwave multicast messages, and simply integrate Hubitat to that via an app integration.
I don't necessarily need a pre-baked solution (seems like there may not be one at this time) but I certainly welcome any pointers on what has already been researched, tried, or what might/might not be possible within Hubitat.
I've found that spewing out 40+ CONFIGURATION_SETs at nearly the same time not only takes a couple of seconds to complete, but it also tends to freeze up Hubitat's ability to send Zwave commands for a period of time.
What you've just described is what happens to me occasionally. I don't know why the Google Assistant does this, but sometimes when it mishears what light I want on, it will turn on everything. For example, over the holidays I had some Christmas lights strung up around my son's room connected to a plug. I could say "okay google, turn on Joel's Christmas lights," and they would turn on. Sometimes, it would think I said "turn on troll's Christmas lights" and for some reason interpreted this as "turn on everything" and would say "Okay, turning on 15 lights". If this happened when our other toddler was asleep, that was bad because it would turn on the bedroom lamps, and I couldn't turn anything off for 30 seconds at least.
I don't believe Z-Wave multicast is currently possible, at least with 500 series platform. @mike.maxwell switched to Zigbee for group messaging capability.
I've got a lot of Leviton Z-Wave DZ6HD dimmers and needed some more. I bought the new Zigbee version DG6HD to test them out. I like them so far.
@waterboysh
Back when ST controlled my smart devices, executing the Google routine “close Tom’s shades” confused Google because of the double s in “Tom’s shades”. A Very helpful and knowledgable user in the ST forums (JD Roberts - waiting for him to be ported to HE) suggested renaming the routine “close shades of Tom” which worked great. Perhaps HE is confusing “Joel” with “all”.
@bcopeland and I had a 1:1 conversation as follow-up of sorts to my interest in Zwave multicast, and I wanted to float this out there to the Hubitat Community at large:
The background:
And to the community at large:
Perhaps rather than cracking open the devkit, I'll dig a little deeper in to ZwaveJS, first:
I'm getting the impression it is fairly new and replacing Openzwave in the HomeAssistant community. Regardless, they appear to have a working multicast implementation -- using a serial Zstick integration like @bcopeland suggested would be necessary. Looks like I'd simply spin up ZwaveJS in node.js and then do a typical MQTT integration in order to get it to send multicast Zwave commands. They don't do S2 yet, but I ditched S2 a number of months ago based on the suggestions of this forum so I don't see any potential roadblocks in my environment (yet).
I was able to get a proof of concept working. I spun up a Raspberry Pi 4B and kicked the tires on node-zwave-js zwavejs2mqtt. They have multicast Zwave support already, but we found out it does not work for Configuration Set commands (which I need to set certain parameters).
After a little back and forth, they were able to get support for this working, and I'm now successfully multicast'ing to 35+ switches using the zwavejs2mqtt MQTT interface.
Currently I'm triggering this proof-of-concept functionality manually using MQTT Explorer. I intend to next interface with the zwavejs2mqtt MQTT interface from Hubitat, then I'll update my app to publish to the appropriate topics to trigger the various behavior I'll need.
Thanks a ton for anyone who helped point me in the right direction on this.
Have you figured out a way to trigger multicast commands from Hubitat?
Ezlo has figured out how to do this in their hub that they released several months ago. The feature is called EzloCast. Despite the beefy hardware and impressive features (also supporting Z-wave Long Range) the hub is very limited in it's utility without support for plugins and the web interface that the Vera devices have.
I tried their multicast feature and it works really well, the synchrony and response of the lights very much like Lutron. I've always thought that Z-wave support was subpar on Hubitat but Ezlo's hub made me realize how bad it was. Where previously in a difficult commercial building it took literally 10 seconds for Hubitat to register the state of a single switch after a change the Ezlo Secure hub did it instantaneously.
Although this is completely off topic, how does ezlo handle it when end nodes don't have direct connectivity to the hub?
As far as I know (and I could be wrong...), Z-Wave multicast isn't routable so normally only works on devices the hub has direct communication with. That's normally why Z-Wave multicast isn't used very often in practice - as it gets complicated handling/understanding direct vs routed devices.
I'm not sure. I think you are probably correct that that they need to be connected directly to the hub. But the Ezlo hub supports Z-wave long range so it can send a signal to devices which would normally be a few hops out.
While this is forward looking, and I have not looked specifically at how multicast will work in zwave lr, I do think that if multicast is supported on zwave lr devices that it would be very attractive to have as it wouldn't suffer from the same issues and limitations as the non-LR implementation does.
I guess only time will tell. It will be forever before I have enough lr devices for that to be useful in any case.
I admittingly don't know much about Z-wave LR. I was under the impression that it worked in the same frequency and that the hub had both a higher wattage output and higher gain antenna to support the longer range. That is why I assumed that the long range capability would enable it to multi cast to devices far away from the normal Z-wave range. Please correct me if I am wrong.
