Control of Color LEDs

[Michael McSharry]

I have a Sengled Element RGB bulb that has a Zigbee interface. Zigbee2mqtt was used to get HS visibility and control. Resulting from this I have some recommendations on setting it up in mcsMQTT and also have a need to add additional capability of mcsMQTT to handle the color map used by HS vs. used by the Zigbee bulb.

The bulb information is provided in a JSON payload with state, brightness, color x, and color y parameters. Assuming that one desires to control all parameters, yet keep the parameters all grouped in HS screens, then the first step is on General Tab, Inbound (Subscription) Management and select the third JSON Decoding option to create both parent and child keys. This will handle the grouping. Remember to come back when done with the new bulb and change it back to the default first option of decoding into individual devices.

Next step is to accept the parameters of interest so they map into HS devices. This is shown in the second photo attachment. I have selected On/Off control, Brightness control, and Color(x) control. Right now color x and y are not supported by HS so I need to make an update to mcsMQTT to convert it to RGB. I will do it so that only x or y needs to be selected and it will do the transform on either.

Next enter the publish topic in each of the three text boxes. It will be the same topic and it will be the same as the base sub topic with a /set suffix.

Next use Edit tab (click on Ref button on color(x) device) and change the type to be a Color Picker. This will give the desired UI for color selection in HS.

Next use the Edit tab and change the Publish Payload Template for JSON formatting. In this case it will be {"state":"$$STATUS:"}

Next use the Edit tab to similarly change the Publish Payload Template for JSON formatting of brightness as {"brightness":"$$VALUE"}

Next use the HS Device Management for the Brightness device. Status Graphics tab and change the range to 0 to 255. Also change the type to slider.

The Sengled bulb will retain prior parameter settings so when a bulb is turned OFF, for example, it will remember its brightness and color settings so when turned ON it will restore to the same as when turned OFF. Same for all parameters. This is what allows individual HS device for each parameter.

It is also possible to publish all parameters in one MQTT message. To accomplish this the scripting capability of mcsMQTT will need to be used.

As mentioned above the color control from HS to this bulb is not possible because a transformation between RGB and XY still needs to be implemented in mcsMQTT. I will update these instructions once it is done.

[Michael McSharry]

mcsMQTT 3.4.17.0 contains an implementation of XY to RGB color space. http://mcsSprinklers.com/mcsMQTT_3_4_17_0.zip and will be submitted to updater soon.

The zigbee bulb described in this thread reports its color as an X, Y and Brightness value. HS color space uses RGB. With the update to mcsMQTT an artificial device ":color:rgb" is created as companion to the ":color:x" and ":color:y". The rgb device is the one that should be accepted as a HS device. There is also a new device type on the Edit tab called ColorXY. This will result in a Color Picker control in HS and logic to translate between HS RGB and zigbee device XY.

The manual was also updated to reflect this additional capability.

The color space transformations are not perfect because the end point devices have different color range capabilities. What is reflect in HS has a similar color appearance, but the RGB values are not exact to the digit. In essence HS commands a color and the bulb echo's back what it is able to achieve. This echo is reflected back in the color picker device of HS.

[Michael McSharry]

Is there is anybody else who is running zigbee2mqtt and has a color bulb such as Phillips, Sylvania, IKEA etc who is able to evaluate 3.4.17.0 to confirm that mcsMQTT has a sufficiently generic implementation to handle more than just the Sengled one that I have?

[dbmet]

Is there is anybody else who is running zigbee2mqtt and has a color bulb such as Phillips, Sylvania, IKEA etc who is able to evaluate 3.4.17.0 to confirm that mcsMQTT has a sufficiently generic implementation to handle more than just the Sengled one that I have?

I would like to try the Color part of this.. Off to look for how to install this manual on linux system..

[shodge]

Michael,

I know this is a old thread but I have a GL-C-008 zigbee LED RGBW controller which I am attempting to get connected. I have it communicating in Node-Red and now the plug in sees traffic to/from the device. Here is a status response I am getting...
zigbee2mqtt/0x00124b001ba6af71 {"brightness":255,"color":{"x":0.3227,"y":0.329},"color_temp ":6500}

This looks textbook like the example in the manual ver 4.00 on page 22 talking about the control of a colored light. I am expecting to see a virtual (from the plug in) of:

zigbee2mqtt/0x00124b001ba6af71:color:RGB

I do not have this topic showing up. Is there something I need to set somewhere to make this show up?

Thx,
-Stan

[Michael McSharry]

As a refresher I reviewed the manual and note a dependency that both parent and child devices need to exist and in that brightnes, color:x and color:y are contained in the JSON. You JSON has the content criteria so my best guess is that you were not configured when the message was received to create both parent and child devices. If I am correct then use the Obsolete function (on General or Association) tab to remove this topic, configure General tab to create the parent, and then let it be discovered again. On the second reception there should be a color:rgb availalbe on Association tab. The contol UI should be ColorXY on the Edit tab.

[shodge]

Michael,

I cleared out the old topics, gave the id a better name, and turned on topic processing....

Here is the data sent....

zigbee2mqtt/LED_1/rgb/set {"brightness":255,"color":{"x":0.1355,"y":0.0399}}
zigbee2mqtt/LED_1 {"brightness":255,"state_white":"OFF","color":{"x":0.1355 ,"y ":0.0399},"color_temp":6500,"state_rgb":"ON"}
zigbee2mqtt/LED_1 {"brightness":255,"state_white":"OFF","color":{"x":0.1355 ,"y ":0.0399},"color_temp":6500}

The first one was sourced from Node-Red, the second two are status messages from the LED controller. Again, I agree with your assessment - seems like it meets the criteria but no results.... Here is a shot of what the plug-in sees.... Any other ideas?

[Michael McSharry]

On the general tab fro JSON decoding do you have the bottom radio selected? In the image below the top radio is selected so in this case the rgb would not be created because it has no parent it can be attached. The default is top radio so no parents are created. After discovery of the topic and something being accepted so HS devices are created then the General tab setting can be restored to the default

[shodge]

I thought you had it there..... I did have the default but, I set the the bottom, then cleared out the topics again and ran the same message to the controller.... Still no RGB topic... See pic below....

Could the "state_rgb" be confusing the detector?

[Michael McSharry]

The topic text will not confuse it. It looks to me that you are trying to work with the /set topic which is used to publish from mcsMQTT. You should be working with the subscribe topic. Have you accepted one of the items in the subscribe topic so HS parent/child devices are being created?

[shodge]

I have not associated any of the topics as I was looking to make sure the RGB was there before I started. The LED_1:brightness and LED_1:color:x and LED1:color:y are these from the data. I will add a brightness control and see if anything changes....

-Stan

[Michael McSharry]

You can delete them after the rgb has been created.

[shodge]

Quick Post - it looks like that worked. I now have a RGB topic - its actually lower case - LED_1:rgb .

I have to work other things for awhile - I'll post again with real success / failure....

-Stan

[shodge]

OK,

I got it to work. I had to leave Both the parent nodes AND the JSON parsing in both modes. Yuck.

I got to ask - how do you clean up your page once everything is working? If you hide the root nodes - it messes up the graphics for grouping. (BTW - I was using jons grouping app - fon't try it with the MQTT plugin - they both use the parent field....)

I got the color picker working - the string back to the device is a decimal value? The full intensity point seems to be set around a brightness of 30? If the brightness is higher the other colors start coming up? Is there a scaling factor for this?

I'll end on a positive note - your doc file is tremendous....some great work there and I appreciate your work...

Thx,
-Stan

[Michael McSharry]

The intent is that you only need to have the JSON setting to both until the HS device has been created. All other devices should be able to exist without a parent. Is this not what you experience?

HS does the rendering of devices and their groupings. The provision they make available to users to influence the grouping is singular so it is possible to step on each other. In general a plugin devices properties can only be edited by the plugin with some also able to be modified by HS pages. Apparently the association property has no protections.

It has been some time since I did the design in this area so there may be some constraints that I do not recall. I know I do not want to burn cpu cycles translating color spaces unless a user has actually mapped the device into HS. If you had your preferences how would you design the implementation of this pseudo topic? Now that mcsMQTT does the grouping on the Association tab there may not be a need to have this managed via HS device association property.

I also need to review the color space translation to answer your brightness question. Can you provide some examples of what colors work and which do not? Most recently I have been working with neopixels and need to convert to HSB from RGB to adjust brightness and the HSB back to RGB. At the dim end of the scale the colors tend to wash out and at around 30% equivalent brightness the neopixels remain black. I had previously done XY translation because the Alexa Phillips HUE sometimes used RGB and sometimes XY. Again low brightness levels did not have good behaviors, but I could get light from the LED strip at lower brightness levels than I am able with the neopixels.

Thank you you for the positive feedback. Glad it is able to help others.