I have a couple of GLEDOPTO GL-C-008P RGBCCT LED controller that I use for undercabinet lighting. When they are on in the evenings, they are used for color ambience, but sometimes I want work light.
I also have a GLEDOPTO GL-RC-009 RGB+CCT remote control that uses 2.4Ghz RF "miLight" protocol to talk directly to the RGBCCT controllers (bypassing Hubitat) which is usually used to set the color.
So to enable work lights, I have written a rule to respond to a button press from a zigbee button to store the current color and switch to white light for work lights. On a double-click of the button the color is restored to what it was.
The problem I have found is that it never returns to the color that was set from the remote. It will always return to the color that was last set by the Set Color command from Hubitat.
I do a Refresh before I save the color values, but I traced it down to the refresh also returning the last color set by the Set Color command from Hubitat, rather than the actual color being displayed that was likely set by the Remote.
I suspect his might be a problem with the RGBCCT Controller itself, not returning the actual color being show if it was not configured through Zigbee. The logs seem to indicate as much when I hit refresh I see the values coming back that are the last value set.
Is there any work-around to this to force the controller to return the "actual" color rather than the last programmed color?
Hubitat Version 2.4.3.171
GL-C-008P Version: 11476802
Does "Generic Zigbee RGBW Bulb" work differently for you? (Be sure to hit "Configure" after switching drivers.) If not, it's likely the device either doesn't report this data when set by other means or perhaps only does so in the xy color model (perhaps if that's how the remote sets it), which is not directly compatible with Hubitat's native hue/saturation color model. It looks like a "Refresh" in the "Advanced..." driver just asks the device for its color data, so I'd lean towards some sort of device behavior, like one of those possibilities, here -- but you could at least see if a different driver does anything else in your case.
I have the same lights and remote, and essentially encountered the same issue. What I found was the same as you reported:
- The LED controller doesn’t report back what has been setup by the RF remote control. So because of this, Hubitat doesn’t know what the lights are set to until a « Refresh » command is sent (it is possible that it eventually does sent this information, but I haven’t waited long enough to find out…)
- The refresh only receives the last value in the Colour Temperature (CT) mode it was last set to. It doesn’t get the colour back for some reason…
I’ve tried a bunch of other drivers, but in the end, only the « Advanced Zigbee RGBW Bulb » worked well.
Thanks for the feedback. I did try using the Generic Zigbee RGBW Light driver, but it had the problem where when I set the Color Temperature and Level is would not switch the RGBCCT light to using the White LEDS. In fact it didn't respond at all to a Color Temperature set. So I would agree with @Sebastien that the Advanced Zigbee RGBW Bulb seems to be the best driver to use. Though I have not seen the behavior of the refresh only returning the last values of the CT setting. I see it switching between RGB ColorMode and CT ColorMode, but when in the RGB ColorMode the refresh does return the color values (HSV). It just those color value do NOT represent any values set by the remote. So it is probably safe to conclude the controller is handling color settings from the remote differently than from Zigbee and not attempting to keep those data sources in sync. I might try to see if I can contact the manufacturer to see if they have any solution or can fix it in a firmware update.
1 Like
I’ll also ping @mike.maxwell as I believe he is the author of the driver and might know more about this.
The advanced driver is only designed to work with rgbw devices, strip controllers with RGB and separate white channels aren't ever going to work correctly, particularly for setting color temperatures as the driver has no knowledge on how to mix the values to get the requested ct value.
Thanks for your reply @mike.maxwell. To be clear the controller and strip I'm using GL-C-008P had 5 channels R,G.B, CoolWhite and WarmWhite. When the driver (Advanced Zigbee RGBW Light Driver) sends a SetColorTemperature command the controller seems to obey that, switches it colorMode to CT and figures out the right combination of cool white and warm white to generate the requested colorTemperature.
dev:1022025-12-13 03:33:29.158 PMinfoKitchenUnderCabinet1 colorMode was changed to CT
When a SetColor command is set it likewise expectedly switches the colorMode to RGB
dev:1022025-12-13 03:33:29.355 PMinfoKitchenUnderCabinet1 colorMode was changed to RGB
So that is all working as expected. The question is really about reading color values back from the controllers. Are there any other values the controller might know about that possibly are not exposed currently by the driver. For instance something like 'getCurrentHue', 'getCurrentSaturation', etc that would return the hue/saturation of the color currently being displayed. Currently it doesn't do that if the displayed color was set by an RF remote and not set through Hubitat. The problem being discussed here is probably on the controller side which only returns the last value [Hue|Saturation|Level] set by Hubitat. I opened an inquiry with the controller manufacturer on this as well. I just wanted to be sure it's not something the driver might be able to solve.
1 Like
The advanced driver is not expecting nor setup to support having these values set via another means other than the driver itself, it was written specifically for bulbs where one wouldn't be able to set the values except via hubitat.
So in the advanced drivers the usual attribute reporting isn't enabled like you would find within the standard drivers.
the advanced drivers are looking for command confirmation from the device as the means of verifying the commands success, since these commands are being issued via another controller the command confirmations won't be sent to hubitat.
1 Like
Thanks again @mike.maxwell. I understand what you are saying, but I'm not really expecting the driver to be told the status of changes made to the light from outside of hubitat, nor am I expecting it to issue any events when that happens. Rather my rule has an explicit call to refresh() before it tries to read the hue/saturation/level values from the device. I understand from other threads that I've read here, that the refresh() actually reaches out to the hardware (ie. does an attribute read over zigbee) to fetch its current values. So it was my expectation that what was read back on the refresh() would be the ACTUAL HSV values being displayed regardless of how they were set. But instead I only get the last values sent from Hubitat, not the values that were set by other mean (e.g. via RF remote). I believe IF the values returned on refresh() were the values being displayed, my rule work work as expected. But I think that is a function of the controller and not of the driver. The only thing I was trying to confirm about the driver was whether or not there could be any other attributes it could read from the controller in the refresh() that might return the values I'm looking for - that is the CURRENT HSV.
I have to say that as another user of those controllers and that driver, it would be nice if the refresh command would update the driver to the current setting. I wonder though, does the device actually send back the data that the driver would need?
easy to find out, change to the generic RGBW driver (do not click configure), then try the refresh command and see what it reports
This one?
Resulted in:
So doesn’t look like it reports much back!
From my recent experience, I'm surprised there isn't a help article on GLEDOPTO.
I have GL-C-006, GL-C-007, and GL-C-007P.
It seems to me that the following applies:
GL-C-00n - these products have to use the Generic Zigbee RGBW Light driver. The -006 can simply be used as the white temperature controller only (ignoring RGB) and the -007 can be used as either RGB or white but not both at the same time. I have no experience of other part numbers.
NOTE: these products seem unstable and may require a power cycle every-now-and-then to get them out of sticky states. You can tell them apart because they may or may not have the part number 'GL-C-00n' on the front cover with their other operating information.
GL-C-00nP - these products use the Advanced Zigbee RGBW Bulb driver (but can use the Generic Zigbee RGBW Bulb) for the same functionality of the non-P variants, with the Advanced driver offering more controls.
NOTE: these 'P' products seem to be much more stable and I have not had to reset any for lack of response to automations. These have the part number 'GL-C-00nP' on the front cover with the operating information. They probably have a 'PRO' logo as well.
I have replaced the single GL-C-007 with a ...P unit in my setup and plan to do the same with the -006. Those without the 'P' are a troublesome bunch, from what I have observed, and give GLEDOPTO products a bad reputation.
