Is this something that can be configured within the switch?
I didn’t try anything with the LEDs yet but I’m guessing if this is not built in it is porably doeable with Hubitat?
The idea is something like this:
The indicator still goes up and down but it becomes a lot easier for one the clearly tell the current speed by the colors.
Not sure if it is going to look weird (or too colorful) but this is something that just crossed my mind while at work 
Definitely will be doable with Hubitat. You’re going to use speed low (or level 33), speed medium (or level 66), speed high (or level 100) as the trigger, and then you can either use 3 of the Fan Notification children (easiest) or run custom commands (setConfigParameter with 3 separate numbers for each variable) (more involved) as the action.
I was looking into the device page (Hubitat) and I noticed an option to create an LED child device so I thought it could be as easy as changing the color on that device instead.
Something like this (pseudocode):
if(speed == low)
childDevice.setColor(green)
else if(speed == medium)
childDevice.setColor(orange)
else
childDevice.setColor(red)
end if
It works but with one undesired effect:
Let’s say speed is medium. LED bar is lit about halfway.
When it gets the command to change color it will go to 100% and then come back to the position it was before.
This “flashing” effect does not look ok.
I wondering if I can control the level of the bar (not dim level but the percentage indicated in the bar from bottom up). Maybe this is something I would be able to achieve if I was using the notification parameters instead - as you suggested?
I haven’t actually tested that to confirm, but I know the notifications allow you to set the level %. If you’ve got it color coded and don’t need the level of the bar changing also, maybe just set them all to 100% and it wouldn’t flash up and down, it would end up going up to 100% and just staying there?
I ran an additional test setting the level property of the LED child device and for my surprise it doesn’t control the brightness of the LED, it changes the level (position) of the indicator instead. Good to know.
Anyway… every time I press the button to change speed the LED still have to go the its original color (parameter 20 i guess) before it is changed by the rule, which takes a while and look weird. I don’t think there is a way around this since it is probably a firmware thing. I will drop it but it was a good exercise to learn more about the LED feature.
Interesting, I can confirm that on ST, the LED child device changed LED bar intensity and NOT the level of the load/switch itself.
Are you SURE you have the right child/device? It should allow color and level, both of which are bar specific.
Can you share your larger rule there? It looks like you’re adjusting it as a bulb vs changing the parameters against it or using a notification child with both of those already set? Not sure if that would change the behavior at all but may be worth investigating.
Also just to note, you can change intensity/brightness via parameter 19/21 on the parent if that’s what you want to do?
Yes, it is changing the colors. It just looking weird and flashing some times.
Also, some times there is a delay of almost 3 seconds between the time I turn it on and the led becomes red (default color in parameter 20) and the rule kicking in and turning it green.
Good to know but no but I’m not looking for light intensity/brightness for this so the way it is working is fine.
That is correct. As far as I understood it I can setup up to 5 notifications and if I do that, new child devices will be automatically created for each one of them:
I didn’t do that, instead I used this other option that just creates a single child device for the LED so you can control it directly, without using notifications.
And then I created this rule:
One issue i think is that the levels are not 33, 66 and 100 as I’m setting so we have some flashing there. Another issue is the big delay until the color kicks so at the end it is really funky.
Would be cool if they had this built in tho.
What it looks like so far:
I’m guessing like you’re saying that maybe it doesn’t quite go all the way to the specific threshold before then being moved the rest of the way. If you use the low/medium/high speeds or voice commands to set to those speeds they will use 33/66/100 immediately, so kind of curious if you did that either via Hubitat directly or voice if that eliminates the problem…I’ll have a chance later tonight to maybe give that a shot myself if you don’t.
I tested it with voice command (Google) and didn’t make any difference.
I’m not sure how this translates to Hubitat, or if it even does, so this is FWIW.
The SetColor … hsl property is exposed. I can set it via webCore.
Hue and Saturation dictate the color, Level dictates the LED bar brightness.
Works on a Dimmer. I don’t have a 36.
I rewatched your video with the most recent rules after replicating it myself, and it looks like the brightness of the LED bar is just reflecting when you are increasing or decreasing the speed? It does take a second or two for the rule to trigger and process the color change but that’s about the same amount of time it takes the switch to react from the voice command as well so it’s about what I’d expect?
You are right, I think the delay is the biggest issue here. For whatever reason the switch takes forever to respond and waiting for it to change colors makes it even harder on the brain so I guess I will stick with a single color for now. Thanks all of your for helping.
Do you have the “Disable physical on/off delay” selected? If you’re not using multi-tap functions this might speed up the color transitions.
Yes i do and still the time between pressing the button and getting a response is about 1 second to turn it on and 3 seconds to turn it off (the fan, not the light).