the below basic rule should make the light red, but it makes it purple instead. other colors work great. but red is purple, for some reason. can someone help?
i like to use this version of the color picker because it simultaneously commands brightness and color in one, rather than doing one than the other (which results in the light pulsing more brightly before it gets commanded to low brightness again)
for those who don't know it, this is the device i'm talking about: THIRDREALITY Multi-Function Night Light, Zigbee Repeater, 3-in-1 Combines a Motion Sensor, a Illumination Sensor and RGB Color Night Light, 1-100% Adjustable Brightness, Zigbee hub Required - Amazon.com
and this is a photo of it showing purple when commanded to be red:
I'd start by looking at the "Events" tab for the device and finding the command where the rule sets the color. What do you see for the parameters? Note that you're looking for the command specifically, not any events it may have generated (this page shows both), so you're looking for things with "command" in the "Type" column, probably a "Name" of "command-setColor."
okay, when i use the preset "red", it sends Hue = 100. this results in purple.
when i pick my own color, the red is Hue = 0. this results in red!
notably, Hue 99 = mostly red and Hue 1 = mostly red... but Hue 100 is purple! i think it should be near-equivalent red to Hue 0?
so, i have:
Hue 099 = red (with a touch of purple)
Hue 100 = purple
Hue 000 = red
Hue 001 = red (with a touch of orange)
the Hue 100 purple is nearly visually equivalent to Hue 87 "Magenta". seems like a bug!
i think there is some kind of rollover error? perhaps it's supposed to go to 99.999999 but never 100 or something?
is this an issue with the device, or the driver, or the hubitat platform?
super helpful, @bertabcd1234 ! thanks so much! now the question is just how to fix this bug.
a long time ago I modded the color table in a driver to get what I needed. If you really want to dive a deep whole - compare google CT vs Amazon CT vs HE Ct.... thats ... interesting too. In my case it was the color name equivalents that I played with... 
Also check if there's a firmware update available. It might be fixed in the latest update. My red comes out red on mine.
I have a number of those nightlights around our house, and can confirm that sending "100" to them as the hue (using the Device page) does indeed result in purple.
The first bigger question to me would be why the Basic Rule is defining "Red" to 100. The second bigger question would be why the Device page (and Hubitat in general) is defining the acceptable range for hue values as "0 to 100"; the Device page will auto-snuff any attempt to send a hue value over 100, but seems to find 100 itself acceptable.
This is Hubitat's standard color model, modeled after that of ST. While it's maybe a bit unusual, the intent was presumably the percent around the color wheel in the same way that you'll more often see degrees (0-360).
0 and 100 should both be reasonable choices, no?
From what I can see, it would just convert 100 to 100*2.54, or 254, and then that to a hex string (the latter being quite common when constructing Zigbee commands). This is in the standard range for "raw" Zigbee hue values (0-254), so I think it's just an oddity of the way the device responds. Perhaps a firmware update as suggested by another user would change something? Otherwise, it could just be something you have to work around.
Note that modifying the reported value for the value of the "colorName" attribute, which I remember you posting about a while back, will not affect any of the above (has there been a different approach since then?) -- just what the device detail page reports for this name, which is essentially calculated from the reported hue and saturation values. It won't change anything the other way around, such as the fact that this device itself apparently treats 100 as purple (and in this case, the driver doesn't even know the user said anything about "red" -- the app does the conversion to an actual hue value before it hits the driver).
Glad you figured out what I was going for! I was curious what it was sending in the first place, but ultimately I was going to suggest a hue value of your choosing to play around with to see if anything was different.
thanks for the thoughtful reply.
perhaps you can help me figure out how to command both the hue and the luminosity at once? that's why i like the "default" color names.
when i "pick" my own color, it doesn't give the intensity option, which then means the device defaults to 100 luminosity and it flashes for a second before the next "action" of low luminosity hits.
maybe the default "red" could be commanded as Hue 0 instead of Hue 100? does someone have the ability to update the app for that change?
i'm open to other bug workarounds if we can't fix this. just trying to find an easy way to have the light switch from red->green->red->green without strobing or flashing
If you are not stuck to Basic Rules you can write the rule in Rule Machine. Then when it is time to turn on the bulb choose the "Toggle Color" setting to activate the light and set the brightness at whatever you want. Then when the bulb is triggered to come on it will bring it on red and the brightness level you chose. I use this step in a lot of rules with these exact lights.
It could help if you posted your current FW version on the night light.
For sure. Sorry I’m totally new to all this and have never done any home automation or Hubitat stuff before so I don’t really know what to call things, what to post, or where to find it. Below is copied from my device page for the nightlight
| Application | 52 |
|---|---|
| Endpoint Id | 01 |
| Firmware MT | 130D-0000-00000052 |
| Manufacturer | Third Reality, Inc |
| Model | 3RSNL02043Z |
| Software Build | v1.00.82 |
No worries, I was actually replying to @wiegout, since he noted that w/his current FW version on his nightlight "Red" was working as expected. But getting your FW version is helpful for the compare! 
hahaha case in point about being new here. i now see that there's the little name in the top right of who you were replying to. noted!
thanks for the rec! i disabled my basic rules and tried the rule machine.
rule machine doesn't seem too fundamentally different, but there are a few subtle differences and indeed i got the automation to work! i used "set color" rather than "toggle color" (what's the difference?) and i used the "custom HSB color" which isn't an option in basic rules. i like this because i can set brightness in the same command as hue!
although i did run into some bugs with the Rule Machine app. where you enter values for hue, sat, or brightness... sometimes the field defaults to "0" and i can't change it to any other value. if i put in a number and press enter or click the arrow or click away, the page thinks for a second and then replaces my number with "0" again.
other times when i load the rule machine action page, the HSB fields are "empty" with a gray background "0..100" inside of it and in that case i can enter a number and it saves it.
weird! but i got it! i think : )
(notably, the Hue=100=purple bug is still present, so in my Rule Machine i used the "default" green but a custom HSB for red)
I am not sure the difference between toggle color and set color commands. Honestly, toggle has just always worked for me so that is all I ever used.
Rule Machine is a powerful tool. This didn't even scratch the surface.
I am glad you were able to get the desired effect you wanted. I have learned over time most things don't work exactly how we want the first time it is how crafty we can get and work around to get there. Sounds like you are well on your way.
"Set" will turn it on (weird prestaging options in the driver excepted...) and set it to the specified color.
"Toggle" will turn it off if it's on, otherwise it will do the above if it's off.
Or at least that's the normal behavior for these actions; this assumes the nightlight reports its "switch" state according to the state of the RGB light, as that is what the app will read to determine what "toggle" would do. If the light is an automatic thing like a normal nightlight or just doesn't report that state for some reason, the actual behavior here might be different.
You can also use “custom commands” (or something similar, it’s been a while) in Rule Machine to send commands individually with a tiny delay between if the light isn’t responding exactly how you want it to. For example, send the setlevel command followed by a 50 ms delay before sending color commands, or vise versa.
That is a good point because in my rules they always end with those night lights being turned off. I use the colors as notifications so the rules end with the lights being in the off state. So the toggle turns them back on and the off command at the end turns them off.
Hey @LearningHubitat , did you ever find any other small simple RGB display devices that could be used for similar purposes?
I’m surprised that this isn’t a more common device. I could only find this Third Reality one.
Alternatives seem to be to use actual 120v smart bulbs and then find a fixture for them, etc. I just want some small simple cute little USB or wall-outlet displays that go green for good things (sunny day, garage door closed, etc) and red for “bad”
Download the Hubitat app
