I’m looking at the latest version on github: 2020-06-02.
For me lines 563-564 are:
cmds << setParameter(6, ledLevel, 1)
cmds << getParameter(6)
I’m pretty sure if we just do those commands again for Parameter 7 it would fix my problem, however more elegant solutions may be better in the long.
I also messed around with that selector in Webcore. In my experience there is very little in the way of noticeable color variation with the LED within a specific shade. Now that being said idk when I was testing if the lights were on or off lol. There is a really good chance they were off so the level wasn’t changing which could by why the colors all looked the same. I’m hopeful the fix is as easy as it seems because shades of colors will be very nice for my application.
We must be in different DTH’s, I’m looking at parameters 14 and 15 actually. Inovelli Dimmer Red Series LZW31-SN?
I need to stop editing my posts. I finish and then think of something else.
No I’m using the red series on/off switch. I haven’t looked at the dimmer device handler to see if the problem is the same for that one, but I’m assuming it is most likely.
1 Like
Alright I have a headache now, but I enabled informational logging and did some further testing and I think I have some pertinent information (productive lunch!).
The setColor command looks to be using any or all of the following attributes/options:
I think the confusion here is that the “L” that is “level” is actually mislabeled and should be the “lightness” of the HSL command schema:
The DTH is actually taking a setColor to Red command which is being issued as:
Switch - Master Bedroom: setColor([hex:#FF0000, hue:0, saturation:100, level:50])
And taking the level component of that and dividing by 10 the setting the LED Intensity value to that (in my case 5).
This is incorrect. The L in the HSL is actually a part of defining the color:
If I were to establish HSL as (0, 50, 0) it would be black, and (0, 50, 100) is white.
What we need to do is get another command that is “setLevel” based that will allow independent control of the on/off brightness, parameter 14/15 in the red dimmer DTH.
Hopefully this helps? @Wright100 @EricM_Inovelli
I think technically what you are saying here is correct. HSL is a system by which we should be able to define a massive number of colors. I don’t know the actual number but it is a ton. I think typically its application is used for photoshop/printing etc. I agree that if L is 100% every color shown should be white and if it was 0% every color shown should be black. In our application I don’t think level or saturation are actually being used to determine the color, it is only the hue. I am not an expert on LEDs but I’m pretty sure our led has a red, blue, and green led in it and the hue value we are sending it is getting converted to brightness settings for each of those LEDs by the firmware. I don’t think our LED can be white and it can’t be black (best it can do is off). So level is just a added value that doesn’t do anything. The device handler is re purposing it to determine the intensity of the led (scaled to the blue, green, and red leds) because it is a approximation of what it should be doing. We can produce a dark green by dimming the green color to appear darker. It could be that to prevent confusion a new command to setIntensity could be best, but if we did that level still wouldn’t do anything (same as saturation). We don’t have access to the full spectrum of colors provided by RGB or HSL. We have about 360 colors and then we can scale those colors darker or lighter to make them appear to be different shades but all that is really happening is we are dimming the LED. We can’t choose a dark green color for our LED and then dim the LED as those are not separate actions. Dimming is how we create the dark green. Hopefully this is correct and makes sense. It feels a bit like a haphazard post but to be fair i’m watching my 1 year old between words to make sure she doesn’t eat things off my desk or stick her finger in an outlet lol.
Great, this is good information. So what I did on Hubitat might be the best solution for SmartThings as well. I had the driver create a “LED Color” child device. That device has its own level (which adjusts the LED level) and changing its color adjusts the color of the LED. I had to do a child device because Hubitat had issues when selecting the device since it started categorizing the switch as a color bulb.
Anyway, SmartThings didn’t do this and I thought it was great because then users didn’t have to install another child device handler (one for a RGB device). It seems like I might have to go that route though.
I think that is probably the cleanest route because having 2 levels on a switch is confusing.
I’m confused this seems like a lot of work when you can just pass the level value from setcolor to the intensity parameter. Does doing it the way you describe give any functionality advantages?
Edit:. At least for the on/off switch the led dimming is working as long as the light is on. Passing the level to parameter 7 as well will make it work regardless of the state of the light. The disadvantage I see is you won’t be able to control the level from webcore based on the state of the switch. Any setcolor command will apply to both the on and off led intensity.
Yeah, what if there are two child devices? One for LED Color + Intensity when ON & One for Intensity when OFF?
I know that is extra effort but it allows for the greatest functionality.
That’s exactly what I did with a custom driver (on Hubitat, but same should apply on ST): one RGB-style child for the “default”/on LED, one dimmer-style child for the “off” LED level, and in my case a third RGB plus “LightEffects”-capable child (this exists on Hubitat, don’t think it does on ST–theoretically allows for abolishing the need for any custom command beyond however you might want to set duration, which I haven’t figured out a good “standard” way to do yet) for the Notification LED.
So…I’m biased, but I think it’s a good idea. 
The only thing I’m worried about is the proliferation of devices/child devices this may cause (I’m imagining the fan/light switch like this…).
1 Like
Oh yeah, that is going to get crazy!
Edit: Realized what I said before here was incorrect (it was late). For some reason I was thinking there was a color parameter for on and off. I see why the two child devices makes sense. For my use cases having the ability to set intensity when off doesn’t matter to me but I can see the benefits for others.
The one way I see to sort of get that functionality without the child devices is if my previous thought about using the smartthings app off intensity value as a upper bound is technically possible.
I guess if you are utlizing the switch to the point where you are using commands like this installing a couple extra device handlers is nbd. As a more casual user you can opt to not bother. Maybe it can be presented as an advanced functions thing so the general install/setup is not so daunting.
@EricM_Inovelli Did this request/change die? I am still experiencing the LED bar going to 100% brightness when changing the colors and was going to create the child RGBW devices for my piston but that option still doesn’t exist.
Not dead, just on hold. I will try to do it this week. FYI, in WebCoRE you can use the setColor(hsl) option and use the level. You only need to use the Hue and the Level (saturation won’t do anything).
You can set the hue according to any hue color wheel like this one:
2 Likes
Just bringing this to the top as I rework my child devices (thanks ST!) this would be a good time to get Red’s producing Child LED devices.
I know you guys are REALLY busy, is this something that is still on the short-term list?
@EricM_Inovelli any updates here? I’m starting up automating all of my holidays for the switches and an RGBW child would really clean up this process.
Thanks.
I’ve added the color and intensity child devices to the SmartThings device handlers. Sorry for taking so long, but better late than never!
2 Likes
@EricM_Inovelli @kreene1987
I’m sorry to resurrect this thread from the depths of the forum, but I’m finally circling back around to this. I installed the two child devices in smartthings, however so far at least I haven’t seen any new child device options pop up in the settings of my switch. Maybe its a samsung refresh thing though and they will pop up here soon.
I read through what I missed and I am still unsure if this will address the issue I was originally having, which was that setting the level for the led was only taking effect when the switch was on. There was no way to dynamically set the level when the switch was off. Will this RGBW child device give separate control of level when the switch is on and off?
To use this on a switch I would need to enable the child device and then grant webcore access to that child device. So basically the led becomes its on separate device?
Thanks!
FYI: this is wright100 from above. Had to change accounts cause got locked out of my old one.
I’m an idiot I installed the child devices, but didn’t update the main one… So now the option is there to enable the child device, but when I go to set to true the slider immediately slides back to false. Assuming I’m doing something fundamentally wrong still.
