No announcement yet.

Control of Color LEDs

  • Filter
  • Time
  • Show
Clear All
new posts

  • #16

    Jons plugin allows you to set a parent and child nodes which are then grouped together nicely on the web page. See below.

    Typically, I will create a dummy device as I have done here 'Kitchen Lights'. Then using his plugin I can make it the parent and add other devices to it and it looks good. In this case the Kitchen Table Light' is a MQTT device - originally with no parent. The plug in makes device 208 (my dummy device) the parent. When I use the json setting to both, the string for the dummy device which is not a MQTT device gets the json stuff.

    A simple fix would be a option to make the device parent string in this mode = NULL (as a global option in general).

    Click image for larger version  Name:	hs.jpg Views:	0 Size:	65.1 KB ID:	1309241
    This is my LED controller - even it would be more acceptable as a empty string than the json string. Don't get me wrong the json string has value - but only as a debug tool. Any chance of this mod? I'll be happy to test it for you...!

    Click image for larger version  Name:	hs2.jpg Views:	0 Size:	58.8 KB ID:	1309243



    • #17
      I think you are essentially asking that parent/child not be a mcsMQTT requirement to achieve some specific functionality such as ColorXY conversion.

      On the second matter the following is what I have for XY to RGB
       Private Function XY_RGB(ByVal x As Double, ByVal y As Double, nBrightness As Double) As String
              'Return RRGGBB
              'Calculate XYZ values Convert using the following formulas
              Dim exponent As Double = 1.0 / 2.4
              Dim sR As String
              Dim sG As String
              Dim sB As String
              Dim r As Double
              Dim g As Double
              Dim b As Double
              Dim nX As Double
              Dim nY As Double
              Dim nZ As Double
              Dim z As Double = 1.0 - x - y
              nY = nBrightness '/ 25.0 'The given brightness value
              nX = (nY / y) * x
              nZ = (1 - x - y) * (nY / y) '(nY / y) * z
              nX = nX * 0.01 '/ 100.0
              nY = nY * 0.01 '/ 100.0
              nZ = nZ * 0.01 '/ 100.0
              Dim var_R As Double = nX * 1.4628067 - nY * 0.1840623 - nZ * 0.2743606
              Dim var_G As Double = -nX * 0.5217933 + nY * 1.44723809 + nZ * 0.0677227
              Dim var_B As Double = nX * 0.0349342 - nY * 0.096893 + nZ * 1.28841
              If (var_R > 0.0031308) Then
                  var_R = 1.055 * (var_R ^ (exponent)) - 0.055
              Else : var_R = 12.92 * var_R
              End If
              If (var_G > 0.0031308) Then
                  var_G = 1.055 * (var_G ^ (exponent)) - 0.055
                  var_G = 12.92 * var_G
              End If
              If (var_B > 0.0031308) Then
                  var_B = 1.055 * (var_B ^ (exponent)) - 0.055
                  var_B = 12.92 * var_B
              End If
              r = var_R
              g = var_G
              b = var_B
              If r >= 1.0 Then
                  sR = "FF"
              ElseIf r <= 0 Then
                  sR = "00"
                  sR = Right("0" & Hex(CType(r * 255.0, Integer)), 2)
              End If
              If g >= 1.0 Then
                  sG = "FF"
              ElseIf g <= 0 Then
                  sG = "00"
                  sG = Right("0" & Hex(CType(g * 255.0, Integer)), 2)
              End If
              If b >= 1.0 Then
                  sB = "FF"
              ElseIf b <= 0 Then
                  sB = "00"
                  sB = Right("0" & Hex(CType(b * 255.0, Integer)), 2)
              End If
              Return sR & sG & sB
          End Function


      • #18

        I had not considered you were actually using the string in the parent as a source of data. That does make my request as you put it - not using the parent / child relationship. My guess is that this is a larger scope than what I was envisioning for your change. I will see if I can come up with something different.

        The issue I am having with the color picker is the feedback from the controller in terms of xy and brightness is being converted to a hex color which is to represent what the LEDS are showing. Problem case in point. I set the brightness to 255 (max). I open the color picker and select the most saturated blue (0,0,255). I say ok. The LEDs turn bright sat blue as they should (MQTT message confirms 0,0,255). The response I get from the array is:

        zigbee2mqtt/LED_1 {"brightness":255,"color":{"x":0.1355,"y":0.0399},"color_tem p":6500}

        Mapping that onto the CIE chart shows a nice sat blue. When the status message goes through the plugin conversion it comes back as 0,255,255 and of course the hue in the picker icon is wrong correspondingly.

        I am playing with a on-line calc which does the Yxy to RGB conversion and it seems to work well. You have to scale the Y to 0 to 100 (brightness/2.55), but these values it returns make the color picker look correct and scale the RGB outputs relative to the brightness level.

        I'll set up a spreadsheet from your code above and play with it as well and let you know what I find.



        • #19

          After some more reading and modeling the algorithm, your conversion (above code) is using the 'Wide Gamut RGB' matrix. It appears the proper application would be the 'sRGB' matrix. When I adjust your code with those coefficients, I get proper values returned. Here is a web site showing the Yxy -> to XYZ matrix coefficients.

          This effects only three lines:

          Dim var_R As Double = nX * 1.4628067 - nY * 0.1840623 - nZ * 0.2743606
          Dim var_G As Double = -nX * 0.5217933 + nY * 1.44723809 + nZ * 0.0677227
          Dim var_B As Double = nX * 0.0349342 - nY * 0.096893 + nZ * 1.28841

          sRGB Matrix:

          Dim var_R As Double = nX * 3.2404542 - nY * 1.5371385 - nZ * 0.4985314
          Dim var_G As Double = -nX * 0.9692660 + nY * 1.8760108 + nZ * 0.0415560
          Dim var_B As Double = nX * 0.0556434 - nY * 0.2040259 + nZ * 1.0572252

          With a little more math - the color picker could control brightness AND color as well as being able to reflect the actual brightness of the color on feedback. One control for both. The scope of the change would be to scale the nY value (something like nY=Brightness / 4.4) AND sending a calculated brightness value when sending the RGB value for control. Its likely a simple set of math to compute the brightness or Y of the RGB color - its on the control already - i.e. V in the HSV readout. I for one would like this simplicity in dealing with the LEDs...



          • #20
            I can recall from seeing the "25" as a nY value that I was struggling with getting something reasonable at the time I worked on it.

            Going in the other direction the published output from the color picker has no brightness component. Shouldn't the target light control the brightness based upon the RGB value? It would seem to be redundant to send brightness as well. Having independent brightness control, however gives one a control to change intensity without changing color. The problem with this idealized concept that I experienced is that the color/brightness mapping is different for different products and especially at low brightness levels.

            I am not understanding the nY scaling by 4.4. In the ESP8266 when I want brightness from RBG I just look for the max value or R, G and B and scale to a percentage. As for the HS color picker showing a HSV does not help the plugin as what is delivered to the plugin when the color picker value changes is a RGB.

            As a side note the three equations I used for the XY to RGB in the ESP8266 are modified from my mcsMQTT ones and different from those that you proposed. I guess it all depends upon what color model is being used.

            float var_R = nX * 1.612f - nY * 0.203f - nZ * 0.302f; //nX * 1.4628067f - nY * 0.1840623f - nZ * 0.2743606f;
            float var_G = -nX * 0.509f + nY * 1.412f + nZ * 0.066f; //-nX * 0.5217933f + nY * 1.44723809f + nZ * 0.0677227f;
            float var_B = nX * 0.026f - nY * 0.072f + nZ * 0.962f; //nX * 0.0349342f - nY * 0.096893f + nZ * 1.28841f;

            I am open to changes. This color space seems complex to me so I do not have a good intuitive understanding of it. I have been trying to make things work based upon what I find in google searches. Please provide some guidance.


            • #21
              First, it seems that the accepting of RGB in the zigbee2MQTT is a created interface. There is a PR about adding a RGB input method. So the devices really only accept xy and of course Y for brightness. So combining color an intensity in the way I suggested is complex. I'm playing in Node-Red but I'm not hopeful.

              The info I can get on the code you referenced (above) is Wide Gambit with a White reference of D65 (6500K), The code you are using now in the plugin is the Wide Gambit with a D50 (5000K) white center point. [Neither work (provide a correct conversion) for my gl-c-008] I think the issue comes down to the color space which the unit is operating and putting out xy coordinates. The only way I can see to handle it is through a configuration option - to allow the differences in color spaces. "Wide Gamut (D65)" and "sRGB (D65)". [This would be my suggestion as there is some information suggesting HUE uses what you have coded now]

              The problem with RGB as a color space is that brightness it inherent in value. If you really divorce the two, then the nY input does not matter except it needs to be large enough to saturate R or G or B. A static value of 25 does this in the calculations. By making it static - the color will always show - even when the brightness is set to 0.



              • #22
                I implemented your suggestions for change of color space and for including brightness with the set command. The color scheme behaves better and my Sengled bulb likes it. Some variance still on what is reported in XY to what shows in the HS color picker after the bulb reports its status.

                If you provide the sets of equations and the labels I should use for each then I will implement them in the plugin with user settings to select each.

                I was not always getting the final value of the bulb reported via Zigbee2MQTT. I think I saw this before and I think it was the bulb no longer reported a change while it actually did change to the final value. To deal with this I just sent the command again 2 seconds later and the response was just the current status. This allowed the HS device to become updated to match the bulb.

                I also decoupled the Parent/Child associations from the color:rgb topic as well as not putting the full payload in the parent. I will need to update the manual still to reflect these changes. It is at


                • #23
                  Wholly cow man! I''ll dl and try later tonight!



                  • #24
                    Amazing! The colors are now very close and spot on with the feedback from the controller. The integrated brightness works better than I imagined! The removal of the JSON strings have now cleared up all my parents.....

                    The way it sets presently, everything is scaled to a brightness of 100. My controller has a max value of 255. Any way of providing a scaling factor for the brightness in/out?

                    These are wonderful changes - BIG THANKS!



                    • #25
                      I can see where Zigbee2MQTT is returning a brightness in the full 8 bit range. I updated at While the color space is better than with use of the original algorithm, it still has issues. Overall it does do well with matching bulb color with color picker selection but the numbers commanded vs. status returned have variance.


                      • #26
                        Yes - I agree. Much better but the computed RGB returned values, while the correct hue are not numerically correct - at the lower end. I think the answer is still in the modification of the returned brightness value in the calculations. I let you know what I find. [BTW the link above is wrong but I got it anyway...]...

                        Still - we are closer....



                        • #27

                          Sorry I seemed to disappear. I had a home sever crash and only now is it shallow breathing....

                          My research deep dived into how the Zigbee2MQTT worked and specifically the code which changed RGB into Yxy (they throw Y away). From what I can see the device itself ONLY uses xy. Additionally there is NO status I can get from the controller. The status returned through MQTT is just a echo of the data sent.

                          There is ample web sites showing how to convert between color spaces and how to create the inverse calculations to get back to RGB. Unfortunately, using the conversion as it is coded does not work as it does not scale the calculations properly which in turn skews the output. Bottom line is when the server crashed - I had no forward / back math which would work with the coded RGB to Yxy converter.

                          I have not given up.

                          As a separate issue - is there a trick to getting Alexa to see the color devices?



                          • #28
                            This may not be the right place to ask the question, but I'll be beggered if I can find anybody else with the same problem and I haven't the first clue where to start... If this isn't the right place, a pointer to somewhere else that could help would be very much appreciated.

                            I have a couple of 'Gledopto GL-B-001Z' bulbs. They're paired with zigbee2mqtt and I can control white on/off/brightness/temperature from HS with no problems.

                            The problem comes when I try to change the colour. the RGB LEDs are much less bright than the white LED. If I set the bulb to #FF0000, it turns a little pink, but stays bright and mostly white. If I turn the bulb off and then back on again (either through MQTT or by physically switching it), then it does show red correctly and any other colour changes also work correctly. Making any other change - increasing the brightness or changing the colour temperature - turns the white LED on which then drowns out the RGB LEDs.

                            Looking at what other people are doing for other bulbs indicates that there could be separate states for the White and RGB functions. Unfortunately, sending
                            mosquitto_pub -h localhost -t "zigbee2mqtt/0x00124b001b60000/set" -m "{\"state_white\":\"OFF\"}"
                            gives the zigbee2mqtt error
                            "error: No converter available for 'state_white' (OFF)"
                            so it looks like this may not be a valid option for this bulb.

                            There are, as I see it, five explanations:

                            1) This is normal expected behaviour - I doubt this.
                            2) I have made a mistake in configuring the bulb - If I have, I can't see where. Any pointers would be helpful.
                            3) There is a problem in the mcsMQTT implementation - I can't see how this is the case - the bulb does display the correct colours when the white LED is off.
                            4) There is a problem in zigbee2mqtt - Again, I can't see how this is the case.
                            5) There is a problem with the bulb itself - I think this is the most likely.

                            If anybody could comment on the above, I would be very grateful. If there is a way I can disable the White and/or RGB functions that I'm missing, then this could be an acceptable solution.



                            • #29
                              The github site indicates that this bulb is supported with some hints at

                              My guess is that the zigbee2mqtt configuration is for a bulb that does not have the white channel, but I no explicit experience with bulbs of this type.

                              First search the issues and open a new one if the search did not provide resolution at

                              A problem I had with a bulb when making a large change in the brightness or color is that the bulb would get to the desired state after command, but its status would stop reporting as it was transitioning so HS showed a different value than was commanded. I resolved this with mcsMQTT by resending the command after a short delay. The new command did not change the bulb, but it caused the bulb to report its current value which then was used to update HS.