Zigbee vs. Z-Wave Mesh Collisions?

Curious if anyone else has seen this…

I have a “Big Switch” app running so I can use z-wave lightswitch (aeon micro) to control a pair of floor lamps in my living room. The floor lamps were both plugged into SmartThings SmartPower outlets (zigbee devices). About 50% of the time, Big Switch would only trigger one or the other SmartPower outlet. Both SmartPower outlets were within 12 feet of the hub.

I see similar problems in my basement where I’m controlling 6 GE Link bulbs from a motion detector. Occasionally, one or more of the bulbs doesn’t respond to an On or Off command sent to all 6 devices.

Yesterday, because of some reasons I won’t go into, I swapped one of the SmartPower outlets in my living room for an Aeon Energy Metering Smart Switch (a Z-wave device). Since then, the Big Switch app has properly triggered both lamps 100% of the time.

Is there a limitation with how many simultaneous zigbee commands the hub can send reliably? Is there a practical limit to the zigbee protocol that might cause these issues? Or maybe it’s just the RF environment in my home?

2 Likes

Two most common home interference issues for zigbee are cordless phones and wifi. These do not affect zwave. (On the other hand, zwave is affected by baby monitors and zigbee usually isn’t.)

A roku can throw off zigbee also.

Hub placement also matters, the zigbee signal may not be in the direction you think.

There’s a tendency to put all routers in the same room, even on the same shelf. Usually a bad idea. Very strong, very busy so most likely to cause interference.

So definitely, yes, zigbee could be affected by something zwave was not, and vice versa.

I’ve seen similar issues with group commands to my GE Links, and it’s been noted by many other users as well. Lights seem to be the most common target of bulk ST commands. I suspect it has to do with interference or a deficiency in how fast the ST hub can send the commands. Most zigbee device types that I’ve worked with insert a delay of about a two-tenths to half-second between multiple outgoing messages to the same device, so I wonder if a similar delay is needed for multiple commands out to multiple devices.

This is what zigbee Home Automation uses Groups for. The following link is a super technical explanation:

http://www.eetimes.com/document.asp?doc_id=1278207&page_number=1

The thing, I don’t know if ST supports Zigbee groups And groupcasting.

Note that zigbee Groups are very similar to zwave Groups (issue the same command simultaneously to multiple devices), but both are different from zwave Assiciations (let a local controller toggle an associated device without going back to the hub first). Most of the time a Switch should not be in the same Group as the devices it controls by association.

The most common reason for delay is that the end device has to poll its parent before it gets the command even though all the commands were issued at the same time. The devices in the group may have different parents, which is good, or all share the same parent, which is often bad because they can get stuck waiting to talk to the parent even though the hub issued all the commands at once.

And then there’s ZLL. I know very little about its details. In zigbee HA, well designed groups usually fix most of the “one bulb didn’t come on” problems. But that’s because of the way the coordinator works. ZLL installations don’t have to have a coordinator, although they can. My first question would be does ZLL use true groupcasts (no acknowledgement required). If instead every device has to send an acknowledgement, there’s a much bigger potential for collisions. But lije I said, i don’t know.

It helps to think of zigbee groups like all the devices are plugged into one dumb power strip, and now you can just use the power strip switch to turn them all on or turn them all off. Zigbee groups are NOT the same as scenes, because you can’t use them to send DIFFERENT commands with different parameters to each device. Scenes allow a single event to request multiple actions. Groups request all the devices in that group to take the same action at the same time. but synchronicity gets thrown off by how long it takes each device to actually receive the message.

I hope that helps a little.

I’ve oriented my hub to match the directional power output to point towards my zigbee devices, and I’ve separated the hub from my WiFi access point as far as I can within the same cabinet (by about 4 feet… that’s just a real-world limitation of where I have ethernet jacks and where my cable service comes into my home. Since I seem to be having better luck with z-wave devices in my home, I think I’m going to stick with those.

It’s a shame though… I see far less latency with my zigbee devices than with my z-wave devices. Maybe someday we’ll get zigbee groups and that will help. Or maybe ST will get smart on the software side and give us an option to stagger zigbee commands. In my application, even a 2-second spread across my 6 bulbs would be totally fine.

It’d be kinda cool if you could designate the order that they triggered.

Thanks for the info JD! I’ve tested Zigbee groups with ST using GE Link bulbs, and I can use the generic ST zigbee cluster command formats to assign and manage groups and scenes (ie, add a bulb to a group, read the group assignment table, etc…). Unfortunately, I can’t figure out how to groupcast messages to make use of the assignments.

I did find the command “send_multicast” in the Ember zigbee framework, which the ST chip is based on. It is used to multicast pre-buffered zigbee commands as the “send” command is used to send pre-buffered zigbee commands to a single address. The send command is used in ST open/close sensors to send the enroll response as an example. But there is no documentation on how to format the pre-buffered commands and I haven’t been able to decipher that one example; so I haven’t been able to determine if ST can use that command or not, and test it.

Not possible in a zigbee installation unless you unicast one by one and wait for the ACK before unicasting the next one. or use some interim virtual switch flip to trigger the next.

Remember one of the main reasons for having mesh networks in the first place is that individual devices may be randomly offline, like to have batteries changed. Since both zigbee and zwave have the “issue once, try many” architecture you can’t predict how long an action request will bounce around the network before it ultimately executes.