Ugh. I knew that . . not sure why I posted the firmware links.
@Wright100 says he has the current DH, so maybe @kreene1987 can flush out the issue? @Wright100 , maybe post your piston that isn’t working?
@kreene1987 @Bry Sure I can do that. I feel a little dumb posting it as it doesn’t do much lol. All I have it doing is running every minute (for testing). It then turns on the lights as a sanity check and tries to set the color. The lights will turn on, but the color of the LED never changes. I read the problems associated with the led being forced to blue when the switch is activated and nothing changes if I remove the turn on function. The LED still does not change.
As added information I am using the Device Handler dated 5-07-20 (published). I am using the child device handler (not published) that was originally available (as far as I know it has not been updated since pretty much release).
Yesterday I decided to try a difference approach. I thought maybe if I set the color preferences for notifications in smartthings and then triggered the notification from webcore I could get some basic control over the LED. Not ideal but something. However, startNotification(1) also didn’t seem to do anything.
Mine was crazy simple. I installed the DTH dated 2020-05-06:
Then when I went into Webcore, I performed the actions per my screenshot. Essentially before “set color” was not an action, and now it is.
To add to the feedback in this thread for @EricM_Inovelli and @Eric_Inovelli I did find that the command is overwriting the brightness level of the bar to 100% regardless of off/on, so for example when I am in bed the lights are off and the light bars are at 10% per my “off” setting in my bedroom. When I set the color (not a notification) using WebCore overnight, it sends a command to the switch that has 3 components (per my ST log) but when it changes the color it also pushes a level:100 as part of the command (will check logs to find example). It would be nice to have this either leave off the level OR somehow make it pass the current value with the command. I have woken up to bright cyan bars due to my rain alert (which I have proceeded to add an “only while home” statement to eliminate it firing at night).
Check your logs and post them up. I can help troubleshoot, because in theory this should be working (if its not already red, in that case it will not change since it’s already in that state).
@kreene1987 thanks for your help. I will pull those logs soon tonight. There color doesn’t change at all. Just so we are on the same page I’m using the red series switch ( non dimmer).
@kreene1987 I actually got time quicker than I expected. Here is a log from Smartthings. The setColor command is going thorugh. The color is blue beforehand and is blue after. Is there any chance that the switch itself is overwriting my command so fast that I can’t see the change in color?
@Eric_Inovelli Are you able to confirm that the setcolor feature was added to the non dimmer version of the switch. I’m pretty sure everyone who has commented here is using the dimmer. I see it was listed as added in the new notes of the updated device handler but the command is being issued but nothing is happening. I don’t want to keep spinning my wheels here if it is currently still technically infeasible.
The parameter numbers were wrong in the device handler. I just fixed it.
As for the level, isn’t there a way to send the level value with setColor? That is what you do in Hubitat.
Wohoooo!!! Thanks for the quick update! It seems to be working great now. My switches just got even more useful.
Looks like no level with setColor in WebCore on ST:
BUT, I am able to use the setColor HSL command:
But I guess the original point is I don’t want it to CHANGE the level, I want the color to be changed independent of level (keep it’s current state).
@EricM_Inovelli @kreene1987 I’ve been testing this the last few days. I’m 99% sure that the Saturation and Level Commands here don’t do anything. I to wish that the brightness was controllable as it would expand the color options. I’m working on documenting where the Hue values actually produce a noticeable color change. I know there is a tool posted to do this, but I’ve found that in reality the color only changes noticeably every 15 degrees or so or in the case of green about 50. Is the saturation and level doing nothing a bug or a design limitation?
Here this is in case it helps anybody. In my experience (to my eyes) changes between these values produce a essentially indistinguishable change. This felt most pronounced with the greens which seemed like it never changed. Being able to change the brightness/saturation would greatly widen the array of colors available though so this is just a list based on my observation given the current setup.
0 Red
25 Orange
35 Yellow
45 Light Yellow
55 Light Green/Yellow / Highlighter
65 Light Green
85 Medium Green
150 Cyan
225 Blue (medium/dark)
250 Purple (dark)
275 Magenta
300 Pink
Yep, saturation doesn’t do anything. Just hue and level. Hue adjusts the color and level adjusts the intensity. Since level is treated in SmartThings as a range of 1-100 and on the switch it is treated as a range of 1-10, there is a calculation done in the device handler. So set the level to something between 1-100 and it will be scaled correctly. Math.round(value.level/10)
@kreene1987 I think some people will want to adjust the intensity with the color so what I can do is make it so that if level is not sent then it doesn’t change it.
Perfect. This is definitely the ideal solution, in some instances I will want to increase level too!
@EricM_Inovelli I made a test piston setting the level using the hsl setcolor command and I’m pretty sure it’s having no effect. If I clear out the intensity options in the smartthings menu the LED never brightens when you pass it a intensity of 90-100. If I set the intensity level in the Smartthings menu the led will brighten and the color will change when I tell it to, but the intensity never changes whether I pass it 1 or 100.
Is it possible that the settings for the LED in smartthings are taking precedent over what I’m trying to pass in? This would only matter if the default state for the LED is off when no option is chosen. This would explain why I’m getting no change when I choose no option in smartthings and try to set the level via the command.
Hmmm, the preferences setting shouldn’t stop it from working. What device are you using? I tried this on an LZW30-SN and it seemed to work.
I changed the L% to a few different values and it was adjusting the intensity.
I am using that device as well. I will check again in the morning on a completely different switch to make sure nothing weird is going on.
What do you have the settings in smarthome set at? Do you have the intensity selected or not chosen?
Thanks for your help figuring this out.
@EricM_Inovelli Ok I come bearing some new information. I’m fairly certain that when you issue the setcolor command from webcore it is applying the level to the switch only when it is in the on state. Here is some data I grabbed from testing.
UPDATE: See Edit2 for potential identification of the problem and a potential fix.
(Hue/Sat/Level)
Smartthings Settings for Intensity - Not Selected
(Lights OFF) - LED is Off
(Lights OFF) Issued Command (10/0/30%) - LED remained Off
Turned Lights ON - LED turned on to DIM Red
Turned Lights OFF - LED turned back Off
(Lights OFF) Issued Command (10/0/97%) - LED remained OFF
Turned Lights ON - LED turned on to a Bright Red
(Lights ON) Issued Command (10/0/30%) - LED turned to a Dim Red
Turned Lights OFF - LED Turned OFF
Smartthings Settings for Intensity - OFF Intensity set to 100%
Lights are OFF - LED is a Bright Red
(Lights Off) Issued Command (10/0/30%) - LED is a Bright Red
Turned Lights ON - LED is a Dim Red
(Lights ON) Issued Command (10/0/97%) - LED is a Bright Red
Turned Lights OFF - LED is a Bright Red
(Lights OFF) Issued Command (10/0/30%) - LED is a Bright Red
Turned Lights ON - LED is a Dim Red
(Lights ON) Issued Command (180/30%) - LED is a Dim Blue/Green
Turned Lights OFF - Bright Blue/Green
So I’m pretty sure that regardless of the state the lights are in when a command is issued the level portion of the command is only ever issued to the switch for its ON state level. If a OFF level is provided to smartthings that level is reverted to whenever the switch is turned off. If no level is provided the LED turns off. This problem doesn’t seem to exist for the color though I didn’t test that as extensively. For me I think the ultimate goal is to be able to decouple the LED from the switch completely. Personally Id prefer to have the LED never be effected by the state of the switch because generally the information i’m trying to convey has nothing to do with the switch itself. Hopefully this stuff helps. I need to go figure out what trouble my kids got themselves into while I was doing this lol.
Edit:. Modified to indicate that I believe only the level is having this problem
Edit2: Ok so I’m pretty sure I’ve identified at least partially what the problem is. In line 563 of the device handler parameter 6 is being set based on the level value. Parameter 6 correlates to the LED intensity when the switch is on. Parameter 7 is the intensity when the switch is off and I believe is never set. In order for the switch to do what I am requesting we would need to also set Parameter 7 there I believe. This would cause the setcolor command to set both the color and the intensity for both the on and off states when it is issued. Currently it is only setting the color since that is a shared parameter for both the on and off states and the intensity when the switch is on.
I guess the ideal situation would be having setcolor apply to both parameter 6 and 7, but if a value for off is set in the smartthings app that it would default to the dimmer of the two. This would allow people who want to control both to do so (by not choosing a value in the App) and would allow people who don’t want a bright LED in the off state to accomplish that (by setting a essentially max brightness in the App). I haven’t looked into it enough to know if that is even possible. In the absence of that my biased 
opinion is that we should set both 6 and 7 and if a dimmer value is requested it can be accomplished by triggering on the switch off command and re sending setcolor with a lower level. Hopefully this is helpful and hopefully this is my last edit of this post today, though no promises.
This makes complete sense to me. When the switch is off, it uses parameter 14 for LED bar brightness, when on, it uses parameter 13. I’ll look forward to see what EricM comes up with (done enough tagging today 
).
Edit: Line 563 is a bracket, @Wright100 what version of the DTH are you using? I’m looking at 6/2 version and this is lines 585-599.
Edit2: Corrected for Dimmer parameters that I am seeing, which are 14 and 15, not 6 and 7.
Replying to myself, in further looking into this I found that there is in fact ways to send RGB, HSL, or HEX through the setColor value:
All of these send a Hex value though when implemented:
@EricM_Inovelli seems important as you continue to improve the DTH.
Also reading this for some knowledge: https://docs.smartthings.com/en/latest/capabilities-reference.html#color-control