Hi all, Long story short, I have a smart bulb that uses the Zigbee Light-Link protocol, that won’t pair with the Smartthings Hub. I’ve managed to get the Zigbee design documentation from the support team of a bulb manufacturer, which includes the support InClusters, Manufacturer/Model with the Zigbee Cluster Library, etc. They’ve been very helpful!
So in order to try and get this thing paired, i’ve tried creating a device Handler from the Zigbee Dimmer (which the bulb is) template, and entering all the relevant zigbee cluster info into the necessarry boxes, but i’m still having no luck when trying to pair.
I’ve also tried to adapt the “Zigbee Hue White - HC” device handler that Sticks18 posted in another thread (which i’m guessing in theory should work as the bulb is pretty much identical in features) but still no joy.
Is there anyone who can assist? Happy to provide the zigbee info i have on the bulb via PM, the manufacturer requested i not post the info on the forum, that’s all.
Taking a step back, the bulb should pair to our hub even if you don’t have a Device Type Handler to support it. The first step in troubleshooting this issue will be to figure out how to reset the bulb. If the hub is searching for devices during that reset process it should pick the bulb up right away.
Some ZigBee bulbs can be reset using an on-off pattern. Others, like the Philips Hue bulbs, require a special ZLL command that can be sent from remotes like this.
Feel free to shoot me a PM and I’d be happy to look deeper for you.
Hi Tyler, thanks for your quick response. Ahh that’s me misunderstanding how the pairing process works then!
I’ve tried resetting the bulb countless times (you’re right, it’s a standard on/off/on/off… to do this), and although the bulb indicates it connected to the ST hub (a single flash after it’s turned on, while ST is in pairing mode), ST never actually finds it, and just continues “Looking for devices”.
I assumed that by creating a Device Handler with the relevant Zigbee info in it, such as Manufacturer/model, then ST would know exactly what to search for when in pair mode.
I should add that i’ve been able to get this bulb connected to a friends Hue bridge, so i know it’s working ok, just can’t get ST to see it
Do you see anything in the hub logs during the pairing process?
Start here, then click “List events” on your hub page. If the bulb is pairing to the hub you should see a zbjoin event with all the relevant details on the bulb (clusters, manufacturer/model, etc.).
If it didn’t pair up to your existing Device Type Handler, you should also see a device called “Thing”, which you can then Edit to manually retype it to ZLL Dimmer Bulb (not ZigBee Dimmer).
No unfortunately not, the only log entry is “Z-Wave include search started”, which remains the latest log until i stop the search, then it displays “Z-Wave include search ended” (I’ve left it searching for up to 10 mins at times just in case).
I’ve double checked that i don’t have any devices named “thing” and that all devices listed relate to other devices i actually own.
When a ZigBee device joins the network it announces itself (“I’m here!”) which kicks off the discovery process on the hub. Normally this happens once, the hub completes discovery and sends the information up to the cloud in order to fingerprint the device.
This particular device keeps announcing itself over and over again, often every second. Every time this happens the discovery process starts over in case some of the discovery information has changed. If the discovery process restarts 5 times then the hub gives up thinking that something is wrong with the device. If this happens it doesn’t report anything to the cloud.
I suggest asking the manufacturer why the device keeps sending the “Device Announce” over and over again. It doesn’t appear to be leaving and rejoining the network, but it is odd behavior that I haven’t seen with other devices.
I have not seen this behavior in devices using the ZHA profile, but I have seen it in zigbee devices using proprietary encoding which are part of a security system. It’s often the first step in a secure key exchange, and the end device is expecting a particular response from the authorized coordinator. Some of these systems let you define how many devices will be on the network, and by not sending a response, it prevents an unauthorized but compatible device from getting past the first commission step.
Also some devices will send a Match Descriptor request for a particular cluster which we don’t support. Then they leave the network, presumably go look for another network that does support that cluster, and when the don’t find one they come back and join the ST hub again for good.
This device is ZLL so not sure why it’s behaving this way.
Well, somehow i’ve managed to get it connected today. Didn’t do anything differently, just put ST hub in pairing mode, then reset the bulb via the on/off x 6 method, then bingo, it showed in the app almost immediately as a “thing”.
The strange thing is i didn’t see the zbjoin event in the hub logs like i’d expect, instead i just got a “desc” event, with a value of “desc: 02 C05E 1000 02 01 1000 00”, which i assume means it knows it’s a ZLL device (C05E).
I’m just trying the various DTH’s but i’m not having much look with them…
oh btw robin, i don’t have a hue bridge personally, it was at a friends house
I think you just got lucky that the discovery finished once before the device rejoined. However it did rejoin again so no matter what DTH you pick it’s not going to work because the device’s address on the network keeps changing. I wonder if the bulb will only stay on a ZLL network which Hue is but ST is not.
Scott,
Check your Power Meter (from the Electric Company).
If it is a wireless model called OpenWay, this is most likely the culprit.
These machines use the same protocol as your bulb and create interference.
Move your hub away (maybe to the office or a friend’s house that do not have this type of meter) and your bulbs will pair in an instant. Once done, you can come back home and all will work as a charm (no need to re-pair).
