Zwave Multicast

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.

Thanks for any insight!

2 Likes

really hope you get the help you need to look into this!

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:

  1. Result in immediate execution of commands, and
  2. 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.

Thanks for any insight.

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.

This may be a question for @bcopeland as the resident Z-Wave whisper.

The current controller sdk doesn’t provide a path for multicast.. At least not that I have seen documented..

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