Gledopto GL-C-008-1ID will not switch OFF

Device support
1

Hi guys,

I’ve got (now) 2 Gledopto GL-C-008’s which will not switch off. They stay dimmed. No clue why. I’ve reset them, no luck. I’ve used other PSU doesn’t resolve issue. I’ve just connected to other piece of LED-strip, no luck. I’ve moved both controllers in close proximity from Z2M coordinator, no luck. In MQTT Explorer and Home Assistant a see proper payload passing by. Z2M-logs ;

info  2020-07-12 18:14:45: MQTT publish: topic 'zigbee2mqtt/light_cove_bedroom', payload '{"state":"ON","brightness":254,"color":{"x":0.177,"y":0.655},"color_temp":148}'
debug 2020-07-12 18:14:47: Received MQTT message on 'zigbee2mqtt/light_cove_bedroom/set' with data '{"state": "ON", "color": {"x": 0.52, "y": 0.224}}'
debug 2020-07-12 18:14:47: Skipping state because of Home Assistant
debug 2020-07-12 18:14:47: Publishing 'set' 'color' to 'light_cove_bedroom'
info  2020-07-12 18:14:47: MQTT publish: topic 'zigbee2mqtt/light_cove_bedroom', payload '{"state":"ON","brightness":254,"color":{"x":0.52,"y":0.224},"color_temp":112}'
debug 2020-07-12 18:14:50: Received MQTT message on 'zigbee2mqtt/light_cove_bedroom/set' with data '{"state": "ON", "color": {"x": 0.545, "y": 0.234}}'
debug 2020-07-12 18:14:50: Skipping state because of Home Assistant
debug 2020-07-12 18:14:50: Publishing 'set' 'color' to 'light_cove_bedroom'
info  2020-07-12 18:14:50: MQTT publish: topic 'zigbee2mqtt/light_cove_bedroom', payload '{"state":"ON","brightness":254,"color":{"x":0.545,"y":0.234},"color_temp":44}'
debug 2020-07-12 18:14:50: Received MQTT message on 'zigbee2mqtt/light_cove_bedroom/set' with data '{"state": "ON", "color": {"x": 0.592, "y": 0.25}}'
debug 2020-07-12 18:14:50: Skipping state because of Home Assistant
debug 2020-07-12 18:14:50: Publishing 'set' 'color' to 'light_cove_bedroom'
info  2020-07-12 18:14:50: MQTT publish: topic 'zigbee2mqtt/light_cove_bedroom', payload '{"state":"ON","brightness":254,"color":{"x":0.592,"y":0.25},"color_temp":37}'
debug 2020-07-12 18:14:53: Received MQTT message on 'zigbee2mqtt/light_cove_bedroom/set' with data '{"state": "ON", "color": {"x": 0.484, "y": 0.481}}'
debug 2020-07-12 18:14:53: Skipping state because of Home Assistant
debug 2020-07-12 18:14:53: Publishing 'set' 'color' to 'light_cove_bedroom'
info  2020-07-12 18:14:54: MQTT publish: topic 'zigbee2mqtt/light_cove_bedroom', payload '{"state":"ON","brightness":254,"color":{"x":0.484,"y":0.481},"color_temp":41667}'
debug 2020-07-12 18:14:56: Received MQTT message on 'zigbee2mqtt/light_cove_bedroom/set' with data '{"state": "ON", "color": {"x": 0.19, "y": 0.64}}'
debug 2020-07-12 18:14:56: Skipping state because of Home Assistant
debug 2020-07-12 18:14:56: Publishing 'set' 'color' to 'light_cove_bedroom'
info  2020-07-12 18:14:56: MQTT publish: topic 'zigbee2mqtt/light_cove_bedroom', payload '{"state":"ON","brightness":254,"color":{"x":0.19,"y":0.64},"color_temp":156}'
debug 2020-07-12 18:14:58: Received MQTT message on 'zigbee2mqtt/light_cove_bedroom/set' with data '{"state": "OFF"}'
debug 2020-07-12 18:14:58: Publishing 'set' 'state' to 'light_cove_bedroom'

They will not switch off. What can cause this problem? I’ve got 41 devices hooked up to CC2530+2591 with Firmware DEFAULT_20190608 running Z2M v1.14.1.

2

EDIT; because I used default Firmware and already have 41 Zigbee-devices hooked up I’ve moved to the Source Routing Firmware. The link-quality of various devices improved tremendously. Some from low 30’s to 111. But still suffering the same switch off issue though.

3

Just for the record, I had the same Problem with the Gledopto on deconz. Not tried it with zigbee2mqtt yet.

4

I’m starting hate the guts these Gledopto pieces of sh4t. Today connected a Gledopto driver on kitchen which had the same problems (other LED driver though). Controller hasn’t been in network for months.

Initially it worked today controlling that thing straight within Home Assistant. So that looked good, let’s add it into flow in Node-RED. The piece of @@#! didn’t want to switch off! One Gledopto driver in same flow works without problem the other don’t. Both are Zigbee LED controller RGB + CCT (1 ID) (GL-C-008-1ID) running on Zigbee2mqtt 1.14.1

When I remove transition: 2 in devices.yaml on device, it will switch off in flow (after calling manual light-services). Then I thought let’s bypass HA. I converted service call into JSON -payload for MQTT-topic with transition-atteribute set in Z2M yaml-file. In a Github Issue about Gledopto GL-B-007Z and GL-B-008Z Koenkk states;

For brightness it is actually supported, send e.g.:

On:

{
  "state": "on",
  "brightness": 255,
  "transition": 3
}
Off

{
  "state": "off",
  "brightness": 0,
  "transition": 3
}

So I did this within a function-node;

const MQTTmessage = {
    "turn_on": {
        "payload": {
            "state": "ON",
            "color": {
                "x": 0.551,
                "y": 0.404
            },
            "color_temp": 356,
            "brightness": 100,
            "transition": 2
        }
    },
    "turn_off": {
        "payload": {
            "state": "OFF",
            "brightness": 0,
            "transition": 2
        }
    }
}

return MQTTmessage[msg.payload.service];

Adding transition will cause Gledopto NOT turning off. Is it a bug?
EDIT: strange thing is the other working Gledopto driver HAS transiition set in yaml-config.

5

Other Gledopto controller same problem. Today I found out when I add transition-property, brightness- and/or brightness_pct-property in payload of Node the Gledopto will not switch off. Can you guys provide me a pointer how to pinpoint this problem

6

Hi @myradon, I am experiencing the same issue. Did you manage to resolve or did you file a bug I can follow?

Thanks.

7

Hi, Nope I didn’t. I found when removing transition in config or just set transistion: 0 within payload light will switch off. Is it a firmware bug? Is it Zigbee2MQTT? I don’t know and I don’t know how to debug that one.

My last resort is just disassemble one controller to see if some hardware reset can be done. All my zigbee stuff has moved to a new, more capable, CC2652 Zigbee2MQTT Coordinator. So every device had to be reset and paired. Still same issues. Also I took a look at Dresden Electronic’s Zigbee LED-drivers. They too expensive to me. Frankly I gave up on these devices. Support from Gledopto is non-existent. I’ve mailed them twice. They have never replied.

Currently I’m in the middle of designing my own PCB’s with MOSFETs, transistors, an ESP01 and i2c PWM-controller supported by ESPHome. Prototype on breadboard already runs several months flawlessly on HA throught Wifi and MQTT.

8

I am using the conbee ii so I think the issue is with the gledopto unit.

I have heard good things about node MCU and wled, so I’m going to try that next.

9

Hi @myradon,

Although my problem was slightly different, I managed to find a solution.

My problem:
When I call turn_on for the light.gledopto entity (via node red and home assistant), the light fades in over ~0.5sec. When I call turn_off, it fades out in a similar manner.

When I call turn on with a brightness or color specified, the lights come on abruptly instead of fading in like they do if no options are set.

Solution:

After playing with the unit and issuing commands directly from HA, I realised that the unit does indeed support transitions, but only after the bulb is on. I feel like it is a bug that it doesn’t fade in if other parameters are set. I’m not that familiar with the unit though so I can’t comment for sure.

In my set up - using nodered - I call the turn on service twice. The first time I set the brightness to the lowest possible value and desired colour.

{"brightness":1, "rgb_color": [255,255,255]}

This causes the LED to turn on abruptly, but be very dim so you don’t really notice it. It switches to the desired colour.

I follow this with a second node which specifies the desired brightness and transition time.

{"brightness":51, "transition":0.2}

I found that 0.2 seconds mimicked the native on/off fade behaviour of the gledopto unit.

As for turning the unit off, I don’t specifiy any parameters and that works fine.

I would love it if the gledopto unit could handle turning on, changing colour and fading up in brightness on its own. I will file a feature request.

Hope this helps someone,

C

10

at the end of the day they are workarounds. Their behaviour doesn’t make sense to me. I’ve got on Gledopto in the hallway. I fiddled with color-transitions of 10 seconds within Node-RED Flow. Half a year ago I threw away that Flow. The default setting of all my lights is transition: 2. That particular Gledopto doesn’t obey by this setting. Take several seconds, might be ten, until it’s in final brightness.

Final thing I could try is to dust off a Hue Bridge and see what happens with the Gledopto driver.

Yesterday I’ve sent a PCB design of a ESP-01 PWM-controlled LED-driver to China. I’m going to ditch these suckers. Wifi, ESP8266 along with MQTT works flawless.