WLED/mcsMQTT - HSTouch integration

[Guest]

Hi Michael,
Since HStouch still doesn't have any decent color picker, I had to build something from scratch in order to integrate/control Tasmota based color LED lights in HStouch.
"HSBcolor" topic and its 3 sliders for color control.
"Color" topic for presets (set as text field to save/push presets via script)





Thanks to mcsMQTT I can also integrate and control WLED via HS but not so easily via HStouch.
Any chance, in WLED, to replicate Tasmota "HSBcolor" (or any HSB type sliders ; actually brightness is already there, missing Hue and Saturation sliders)
and "Color"? (tried pushing values to "wled/WLED1/x/col" ; it changes the value but has no actual effect on the device/lights)
This would allow to use the same template/scripts in HStouch to control WLED based lights.

I saw some references to HSB/RGB control/feedback in the http API documentation
https://kno.wled.ge/interfaces/http-api/

Let me know what you think,

Cheers,

Yann

[Michael McSharry]

I am confused as to what you are asking. I do not have any color lights in production use and do not use HSTouch so it is not clear what you are asking. It seems like your are asking for HTTP for &HU and &SA control of WLED. Now only Segment control uses HTTP. Are you asking for another Control/Status UI type in mcsMQTT for another color variant that results in separate devices for H, S and B that would each be sliders? How does WLED report H, S and B?

[Guest]

Are you asking for another Control/Status UI type in mcsMQTT for another color variant that results in separate devices for H, S and B that would each be sliders?

Correct.
Since the HSB controls are available in the user interface (below) I was hoping control/status would be possible via their API.
Brightness is already covered in your integration, Hue and saturation are missing.

As for the API itself, I saw the information below but not familiar enough with the API to assess feasibility / integration efforts

&SS=

0 to 9

Select segment to apply THIS api call to

0.9.0

&HU=	0 to 65535	Hue	0.5.1
&SA=	0 to 255	Saturation (only in conjunction with Hue)	0.5.1

-
I also remember at some point you used RGB-HSB conversion for the Tasmota support, if this can help in any way.

Open to any suggestions, thx

[Michael McSharry]

In essence what you want is to have three sliders for HSB and use of those sliders will result in a change in WLED color/brightness. You want WLED color/brightness to be reflected in three HS devices that have a slider as the UI. This means that when the color or brightness from WLED is delivered via MQTT that a conversion is done into the HSB space and the three corresponding HS Device Features are updated. When one of the three HS Device Features are updated then these are converted to a RGB color and delivered to WLED. While there may be differences in the color model used by WLED and by mcsMQTT they will be close and good enough. The variation between color bulbs will be greater than then variance in color space modeling. Since HS maintains the truth in the HS environment it will have the DeviceValue with the composite RGB/HSB and be controllable via whatever controls are provided by HST. Does this seem like a reasonable approach?

[Guest]

Correct.
This sounds like a reasonable approach, based on the assumption that the WLED API doesn't offer direct Hue/Saturation control/status.


Thanks for the feedback,

[Michael McSharry]

The management of the HSB and color picker already exists for HSB Control/Status UI. It creates both color picker and set of sliders for H, S and B. All I should need to do is accept a RRGGBB input in addition to the existing (H,S,B) and then do a conversion to HSB when RRGGBB is received. Currently if one of the sliders is used, mcsMQTT will convert the updated H, S, and B to RRGGBB to which it sends to WLED. WLED will respond with a color update and mcsMQTT will then update the color picker and slider devices.

[Guest]

Sound good to me. I'll be glad to test
Keep me posted. Thank you Michael.

[Michael McSharry]

I have been playing with this for a day or two and still iterating. What I have learned is that when a RRGGBB color command is provided, WLED does not update the brightness control. It remains constant unless explicitly changed. This means that a color space transformation of HSB <-> RGB is really not honored by WLED. My next step is to use the controls that are referenced above to explicitly command H and S. The problem that I foresee is that WLED does not report anything that I can find in the API to indicate what the actual H and S values that it is using. This means I have no explicit feedback loop for the cases where HS3/4 uses the H and S controls. I am traveling tomorrow but should be able to resume next week.

[Guest]

Thanks Michael,
meanwhile I'll see if I can get some support from the WLED team regarding H and S controls.
cheers,

[Michael McSharry]

I think there is already H and S controls. What I do not recognize is the color reported in H S B format

[Guest]

I guess you've seen this already (and probably use it for the current McsMQTT implementation)

on light change, WLED will publish to 3 topics for MQTT clients to query the state of the light.

• [mqttDeviceTopic]/g
  -> Contains current brightness as ASCII number 0-255
• [mqttDeviceTopic]/c
  -> Contains current color as HEX (#RRGGBB if white is 0, else #WWRRGGBB

So my understanding would be that Brightness is "/g" And Saturation/Brightness should be derived from "/c"
but can this be done accurately/efficiently without combining all 3 elements...


Other interesting links:

with references to the Tasmota implementation:
https://github.com/Aircoookie/WLED/issues/207

Direct reference to WLED HSB status/control (via Nodered however)
https://community.openhab.org/t/solv...nodered/121848

[Michael McSharry]

You are correct as to what I am using and doing. I still need to play more. Right now I can change WLED GUI controls for color space and H, S, B values in HS are updated. I expected B to remain constant. If I change B on WLED then the /g is updated in HS to track, but the computed B from the /c does not change. I likely have some element in the loop not being done correctly yet.

[Michael McSharry]

I took detailed notes as I went through various test cases. I know my HSB/RGB conversions are correct in both directions. I confirmed these with online calculator. The problem looks to be how WLED manages the color space. I believe it does good with providing the desired intensity and color effects using the color picker and brightness controls. The issue is that it does not report its true color space so doing delta changes in color are hit and miss.

When using the WLED GUI of a color wheel and H S and B sliders there is no change in the B slider when any of the other controls are used. This implies that B must first be set.
When the H slider is used the S slider first goes to 100% saturation. This may imply that changes in Hue are only made with a 100% saturation.
Once the desired Hue is obtained then the Saturation can be modified.

When observing at the LAN interface there are no H and S. Only RGB and B. The problem is that when B is changed there is no corresponding change in RGB. This means that the HSB color space cannot be determined. If a RGB command is given, WLED will respond showing the color being the commanded RGB, but since the brightness does not change the color is not a real color that can be represented in the HSB space. I thought, perhaps, that HSB could be computed based upon color, but then discard the B and replace it with the WLED Brightness value. The color will not be correct, but it may be functional. It turns out that this approach also is not reliable.

Consider the following sequence where steps 1 to 4 establish a consistent RGB/HSB color space with LEDs at a dim green
Steps 5 through 10 attempt to mimic WLED color logic, but the color space moves from green to blue.

1. Set WLED brightness GUI slider at 15% (38/255)
2. HS Command Color 0B4C00
3. WLED responds with color 0B4C00 (LEDs are low intensity green)
4. HS Updates HSB with 111 100 15

5. Set WLED brightness GUI slider at 50% LEDs increase intensity of green
6. WLED reports brightness of 128/255 = 50%, WLED continues to report color as 0B4C00 (740352)
7. HS Command B (of HSB sliders) to 50% to match WLED Brightness slider
8. HS Sends color 158C00
9. WLED responds with 00009E and LED are blue
10. HS Updates RGB 00009E (158) HSB 240, 100, 31

There is a limited set of colors that can be commanded by HS as it is easy for WLED to interpret them at being white. Likely due to it's sequence-depending calculations exceeding a color space parameter.

I did not research the WLED discussion threads, but it seems like this subject should have been discussed before and perhaps there exists a disclosure that would shed some light on methods for integration/sync.

There does exist the JSON commands that could be used to command H and S, but since there is no status reported in the HSB color space any status shown in HS would, at best, reflect the commanded color and likely would not be the WLED-computed color. I did not try to use the JSON commands primarily because of the lack of status in the HSB color space.

I am open to suggestions and guidance as how to proceed.

[Guest]

I think I'm on to something :

Observations (WLED UI - Color tab) see image below.

- The slider/brightness control over the color wheel is the "global" brightness control
- The color wheel controls Hue and Saturation
- The slider under the color wheel is the current segment(s) Brightness, which is reflected in the small circle within the color wheel.

Which seem to confirm it is indeed an HSB color space. (+ the API references)
And unless there is something flawed with the API, control/status "should" work....

however....
in you test above #4 the conversion is done in the HSL color space (111 100 15) (vs HSB: 111 100 30);
see great conversion/testing tool here: http://colorizer.org/
in #10 the conversion from 00009E to 240,100,31 is again in the HSL color space.

However what puzzles me is WLED interpreting 158C00 as 00009E, I can't seem to find a rationale to this conversion, other than the typical B-G channel reversal but it is a little off so... I went form 0B4C00, doubled brightness (+50% relative) and inverted B-G, result is 248,100,30 in the HSLcolor space, very close to the conversion above.

Probably worth investigating the HSB-HSL lead + the B-G channel inversion.

Let me know what you think.

[Guest]

Something else: under config-led preferences, you can select "color order" (RGB-BRG-GRB, etc)
I actually use it here (1 controller, 2 physical outputs, 3 segments) as one strip is BRG and and some downlights are GRB (again Green and Blue inverted).
So I guess this could have some impact on how the API translates a segment's color request...but the more I think about it, it's probably done in some post processing at the application level;
anyways, food for thought.