I've seen many different posts about the popcorn effect for both zwave and zigbee. I have that issue with many devices in my house. My shades look like a modern art mosaic in motion every morning and evening, but surprisingly, or not, in the same exact sequence and timing. I have a couple of wiz zigbee lights that come on at different times and at different colors but eventually sync up thanks to the group/scene app.
This topic is more for those much more experienced than I. I have not programmed for many years, but still have an understanding of the logic. The popcorn effect with zwave and zigbee should be correctable. Hubitat sends commands in sequence to each device which creates the popcorn effect. Could hubitat, or an app, send out a delay to each device increasing the the millisecond delay for each device in the rule? The first device in the sequence would have the longest delay and the subsequent devices would each be less based on hubitat's internal clock speed. This would basically allow hubitat to send out a command for all devices to react at the same time. Then it's up to the individual device to handle the command in a timely fashion. Is this possible from a programming standpoint within Hubitat or an app within Hubitat?
I use a Zigbee group with 3 bulbs, and I never experienced the popcorn effect. Hub sends only one command, all group members receive it in the same time.
Zigbee Group Messaging is not a 'routine' that Hubitat created. It is part of the Zigbee Home Automation specification. As such, devices that want to pass Zigbee HA certification have to include features like this. Hubitat simply sends a configuration message to all of the user selected Zigbee devices, telling them they are part of a Zigbee Group. When Hubitat sends a Zigbee Group broadcast message, the Zigbee devices that are part of that particular group respond and act accordingly. The cool part about this is that only one Zigbee message is sent, causing all devices in the group to respond at the same time.
I am not familiar enough with Z-Wave to know if such a feature exists as part of the Z-Wave specification. Perhaps someone like @jtp10181 or @bcopeland would know?
I do not believe that Z-Wave allows for a 'delayed action' as part of a command. However, I am no Z-Wave expert.
Z-Wave shades are FLIRS, and I think getting them all to react at once will be a challenge. This is because in order to wake each one a special beam message has to be sent out, I think one at a time. Each beam cam clog up the z-wave traffic for up to 60 seconds.
Thank you for the background on Zigbee Groups, the communication between the devices make sense. I used some of the first Zwave devices, that were associated with a leviton remote, yes back at the wheel was invented. It was stable and all seemed to work instantly once the routes were burned in. The zigbee grouping seems similar to an association in zwave..
Z-wave multicast sounds promising, but wouldn't there have to be limits on number of devices it could signal at one time since you'd still me sending multiple signals at once? Would it possible to create multiple associations between zwave devices and have Hubitat just signal the one controlling device in the association?
My shades are Smartwing z-wave. I have all the shades go up and down at the same time, which I need to change. As you pointed out, all those signals are creating a lot of traffic, enough that some shades are often missed, and I have to re-fire the action.
I would try staggering them by 30-60 seconds if you can tolerate it. That will allow for each one to be woke up and the command sent one at a time. Z-wave locks have the same issue.
If you think about this your realize it would act the same if you had a delay or not, on any wireless system only one message can be sent at a time delaying that just gives a delay.
As @ogiewon alludes too the delay would have to be in the packet command and the device itself would have to wait before it acted. I know systems that do this but never seen anything in z-wave or zigbee that would suggest it's possible. However I have also never looked for that particularly.
The difficulty would be the hub would need to know the full transaction speed for each device. That I would assume would be easier with z-wave rather than Zigbee because the hub maintains the mesh in z-wave.
My thought for this was that you could use an app to multi-fire commands in sequence requesting the z-wave devices to slightly delay a little less for each of the devices until the rule completed. The anticipated result would be the delays would more closely sync up the device actions. But I can see your point that you are relying on the device to respond immediately.
That is not how z-wave multicast works. A single z-wave message is sent to a select group of devices. An unacknowledged multicast frame is followed by a singlecast frame to each device that did not acknowledge the multicast frame.
Not to get folks off track, but there is also GroupCast within the Matter Spec as of V1.3. - I don't believe HE supports this yet, but I'm guessing it will come eventually..
That said, I realize your looking for a Z-Wave solution on shades. And I do own SmartWings Z-wave shades. - I only have 4 to move in "one block" at a time. - And while my solution with a virual shade is a bit complex, the bottom line, is that I do a refresh on each of the device members - to get them "awake" with FLIRs messages. Wait a second on two, then hit a 4 shades with a message a part of a HE group, with retries on each device enabled. That seems to work, and they effectively move within 100ms or so. (even though this is actually 4 seperate position commands sent out sequentially) - It also helps to have things paired with LR, or not hops thru repeaters, if the mesh path is vairable for these devices, then obviously the timing will be variabile for the various hops as well
The key is getting them all awake at once with the "FLIRs" refresh message, and wait for that to clear - Then they all respond quickly after that - I'm sure if you get into large numbers of devices, that breaks down - But 3-4 devices seem to move effectively at the same time. The trick is some are sleeping, and FLIRs has to wake things up, then your going to have visible delays
Thanks Mike, I did see this, but had not implemented it yet. It's probably a marriage saver..lol
I'll have to do more research in to the multicast, to better understand so when it's time comes to Hubitat, I'll better grasp the concept.
Thanks for this. I've had to refresh my zigbee Somfy curtain device each time so I can get accurate status before the next rule runs. This makes sense. I know the rule is typically to use the KISS principle on creating rules, but adding the wake-up sound like it will make the operations much smoother and at least closer timing. Thanks.
It sounds like you might not have enough repeaters for a solid Zigbee mesh if you’re having to regularly refresh a Zigbee device to get the status to update. This sounds like it’s having trouble communicating with the hub.
You are correct, when I first installed the somfy curtain controller, it did seem to struggle with the connection. It did connect , but I could not get it to refresh unless forced, so the rules would not work. Hubitat reported week zigbee signal, so I changed the channel and increased the strength and the message went away. I don't have that issue with my other zigbee devices.
Increasing the Zigbee transmission strength will help the device hear the hub’s commands, but won’t necessarily help the hub hear the device. You need to add some good mains powered devices to act as repeaters, or dedicated Zigbee repeaters. I have the best results with repeaters that are somewhat closer to the hub than they are to the device I want it them to repeat for, but it does depend on the repeater.
Because of this, I am an advocate for turning the hub transmit power down as far as it can go, and letting the repeaters do the work to form a strong mesh. I am using power level 4 without any issues.
