Hub Firmware Release Notes - OTA - 16.9 - V2

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.

1 Like

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

Found it…

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?

1 Like

Like all Osram devices.

1 Like

For now you could use z-way as a node. Not able to alter mesh.

I like Zway as a zwave mapping utility, but you need a 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

I use a raspberry and a gpio pinned z-wave unit yes.
Some kind of compatible z-wave modulet and a distro until ST come up with something.

1 Like

I had similar issues with a couple of RT56 RGBW can lights. Updating them to the latest Osram FW (0492) seems to have fixed it.

I assume there is no way to do that without a osram hub?

At this time, yeah.

And even if you have the Osram hub, if you’re using an android phone, apparently it’s near impossible to do, look at all the complaints on Amazon, the hub has a 2 star rating.

That is strange, I’ve had no issues using either os. The process isn’t fast but it’s the same on either ios or Android as I use both. I actually think the osram gateway is pretty good to be honest. Very quick and strong signal. You get additional features not available without it and also able to multicast commands. Shame we cannot just link to the gateway like the hue bridge. If we could then most of our issues would be solved.