Interesting. How many zigbee devices?
I’ve got 92 zigbee devices, I’ll bet this is count / hop related…
I just asked Alexa to turn on my led strip, she said “ok” but nothing happened. Opened up the ST app, clicked the “On” button, nothing, unplugged the led strip and plugged it back in, everything is working again.
The LED strip is an OSRAM Lightify rgbw strip sitting 2 metres from the hub. I now have to tell ST Support about this problem too, that’s 4 problem OSRAM devices.
Just counted 98 directly connected zigbee devices. Used to be more but moved most of my osram bulbs off onto the hue bridge.
very possibly hop related, ever since removing my bulbs the number of repeaters in my mesh are much reduced. I only have 12 powered zigbee devices now. Maybe the lack of hops is making it perform more reliably? I do remember smartthing support also mentioning that they’ve reduced the speed of zigbee transactions to help prevent devices like the osram bulbs clogging up. Maybe causing issues where people have a lot of hops?
See the statement about “many of the internal tables used by the ZigBee stack are full or close to full, but the source route table has plenty of room”?
I’m guessing that something between the internal and source route tables has changed, and something isn’t right with how they’re suppose to be working together along with all the other zigbee changes introduced with this last firmware release.
I have 53, so what’s the limit before this manifests? 80-90? I’m not having any of these issues. Is there a technical limit? I thought Zigbee was in the thousands of devices range…
I’m not in disagreement at all. I’m having trouble finding that reference I read about showing zigbee traffic in the last update.
All my directly attached Osrams work just fine - using a mixture of device handlers not sure why really but these are the two:
ZigBee RGBW Bulb - most
ZLL RGBW Bulb - just 2/3
Could this change about increasing the delay between messages be a contributing factor in the issues some of us are seeing?
This change was rolled out in an earlier firmware version before 16.9. It is possible that this is involved with the ongoing issues but I would think it was something in the latest release. I’m guessing health checks are somehow involved (perhaps greater traffic), but since this has not been resolved quickly, I’m guessing it is a combination of multiple things.
While debugging the issues reported here I noticed problems refreshing a SmartSense Open/Close Sensor that was routing through an OSRAM bulb. It turned out that there were a few places in some of the DTHs where the delay was still the old small value. Hitting refresh was causing the OSRAM bulb to be completely overwhelmed by the messages and nothing was getting through to the sensor. This could also cause problems with configuration resulting in devices that are not correctly setup. We have a fix for this and some of the other SmartSense and ZigBee* device type handlers that we plan to release as soon as it gets through QA (not before Monday). If anyone wants to try the updated DTHs you can self publish any of them from this PR:
I also saw an OSRAM bulb turn on all by itself when a bunch of messages were routed through it in a short period of time. This particular bulb had really old firmware (0152) and now I’m trying to recreate the problem on the latest firmware (0492). I’m reporting my findings to OSRAM as well and they are also looking at the problem.
In the meantime, this is what I’d suggest for anyone having ZigBee problems who have OSRAM or GE Link bulbs on the network:
1.) Power off as many of the OSRAM, GE Link and any non-certified devices that can act as routers as you can. Routers are typically outlets, bulbs and other devices that don’t run on batteries.
2.) Wait 15 minutes
3.) Reboot the hub (just a quick power cycle, do not leave it off an extended period of time)
4.) Power on the devices you powered off in step 1
This will force the end devices (sensors, locks, etc…) that were previously connected through one of the powered off routers to find a new connection to the network, either directly to the hub or through one of the routers that is still powered on like certified outlets. This will help to avoid the problems that GE Link and older OSRAM firmware have with routing which can cause all sorts of problems with other devices on the network. It’s not guaranteed to solve every problem but it’s been helpful for some people.
This is really interesting. This probably explains why people like myself who removed most of their osram bulbs from being directly connected to the hub not experiencing some of the issues being described by others.
@tpmanley, it is great to see staff like yourself and others repeatedly share findings on this forum even before they are fully ready for deployment.
Today, I noticed one of my Smartthings motion sensors experienced a lag in reporting motion and inactivity. It’s next to my Osram light strips. I noticed the Osram devices were also was misbehaving. I’m pretty sure the motion sensor was routing through the Osram light strips.
I followed your steps to reset – unplugged Osram devices for 15min and rebooted the hub. We’ll see how it goes.
Is there some command we can execute to get a dump of the routing table?
Just wanted to report that I had Osram garden spots turning themselves on by themselves. ticket 295595
There isn’t currently something user facing that provides that information but it would definitely be useful so it’s something I’m looking at.
Thanks. I added the details from you ticket to the other data I’ve gathered.
Additionally… is there any way to influence the mesh? For example, can users blacklist potentially offending devices from passthrough?
Like all Osram devices.
I like Zway as a zwave mapping utility, but you need a zwave.me controller stick to use it, right? (Or a Razberry)
Z-Way can run on different operating systems and host hardware but it will always require a Z-Wave.Me Z-Wave transceiver hardware connected to it and this hardware must be a valid license key to run Z