ZigBee Gledopto 5 in 1 LED Controller "Node has not completed discovery"

I have a new ZigBee device that does not discover properly: 5 in 1 Smart LED Strip Controller from Amazon.

The device has 5 different modes, and I have set it to RGB mode before joining.
I’m using Ember (POPP ZB-STICK) on RPi4 and OH 3.3.0 Release build.

I have attached a log file: ZigBee-log.log (661.3 KB)

The discover is at 12:34:35.488 and the Device ID is 385B44FFFE42A7AE. I’ve tried 3 times with the same result.

Here is a fingerprint:

openhab> zigbee fingerprint 385B44FFFE42A7AE
|>| Node Descriptor
| |> Not Set
|>| Power Descriptor
| |> Not Set
|>| ZDO
| |> ManagementBindRequest      TIMEOUT
| |> IeeeAddressRequest         TIMEOUT
| |> ManagementLqiRequest       TIMEOUT
| |> ManagementRoutingRequest   TIMEOUT

Can it be made to work? @chris

I don’t know this specific device but I have 2 devices that require multiple attempts when pairing. The other devices are perfectly fine.

The log shows that the device is not responding, so possibly it has not joined properly. What version of the dongle are you using (ie firmware version)? One possible explanation could be if you have an old firmware that doesn’t support Z3.0 - in this case devices join the network, and if they find the coordinator doesn’t support Z3.0, they will leave again.

1 Like

@chris Firmware is I can’t tell if this is the latest or not, nor if it supports Z3.0.
The downloadable fw file contains “610”.

Seems to be a strange device:


The Gledopto GL-C-001P is a 5 in 1 smart LED controller which can identify itself as one of the 5 different Gledopto controllers (the indicator light colour matches the model):

[White] RGB+CCT: GL-C-008P
[Yellow] RGBW: GL-C-007P
[Blue] RGB: GL-C-003P
[Green] CCT: GL-C-006P
[Red] Dimmer: GL-C-009P

You can switch between the modes using the Opt button on the device. After switching modes Zigbee2MQTT will automatically detect the new mode. Note that during the pairing process the log message identified as: Gledopto Zigbee LED Controller XXX might state model that differs from currently selected one. You should wait for the log message Detected Gledopto device mode change that should follow shortly afterwards meaning that Zigbee2MQTT has recognized the currently selected mode.

Also worth mentioning: The device doesn’t seem to be certified by the csa.

That’s the one. Does this suggest that you need Zigbee2MQTT to use it, and that installing that alongside the openhab ZigBee binding might work? I know very little about that. Or is it irrelevant, because it doesn’t connect to the ZigBee controller properly in any case?

If this is the end of it, someone could add it to the “incompatible list”, and I’ll return it. It seemed like a plenty powerful device, as opposed to many others that I’ve tried, where the small ones burned up, and the larger ones had too few colors.

So this is the version reported by the binding, and is actually the one on the stick - or are you just getting this from the file you linked from?

If it is 6.10, then it should be fine with Z3.0.


I don’t think that’s the issue. As I said, it is not responding to data on the network - the binding is sending requests, and the device isn’t responding. So the issue is unlikely to be an issue with the compatibility - at least given what I see in the log.

I would suggest to remove it from the network, reset it completely, and rejoin. Get a debug log of this and I’ll take a look at that.

1 Like

@chris is the version reported by the binding.

New log file whereby I delete the thing, do a factory reset on the device, switch to RBG mode, then Scan for new items, and add it again and wait for a minute. Same result, discovery incomplete.
ZigBee.log (175.7 KB)

This log seems to show limited communications with devices (ie none). The binding appears to be trying to communicate with a few devices, but it never receives any response to any command that is sent. The communications with the dongle is fine, but the dongle always returns that it doesn’t get a response from the devices.

Below is part of the log -:

So maybe there’s a more general communication issue?

1 Like

Wild speculation:
The device switches between several IEEE addresses.
...A7AE is only the initial(?) IEEE address.

Checking the Zigbee2MQTT source code could give some hints, e.g. zigbee-herdsman-converters/gledopto.js at master · Koenkk/zigbee-herdsman-converters · GitHub .

You were right @chris. Issue found and solved: Poor reception (4 meters away, blocked by furniture; repeater functionality questionable).
Moved the device closer to ZigBee controller and now discovery and LED control works fine.

I wish I had thought of that earlier and spared us all the trouble.

Maybe it could be suggested to the user or in the docs, regarding the error “Node has not completed discovery”, that you should ensure good communication, and ZB3 fw support?

Somebody could also add this device to supported/tested devices.
I like it because it supports much more than 3 colors between yellow and red, unlike other china devices I’ve tested.

Regarding comm failures; yes I am joining many devices, and because they don’t work properly, or for other reasons, I disconnect them, often without deleting them in UI. If the controller tries to contact them, they wouldn’t respond for that reason. There are several ZigBee devices which do work. That could account for some of the failures.

Thanks to all that chipped in!

Someone (or a neural network …) should read all the problem desciptions and all corresponding solutions and compile a list of the most common pitfalls for each technology (Zigbee, Z-Wave, Wifi, …) :slight_smile: