I don't see an answer to that question.
That's all you said Bruce. where is the answer to that question? You say it will be changed in Rule Machine. For all devices or only ones with high definition hue? I'm not asking for a dissertation here. 1 word is all i need.
That's what I was referring to. Doing that would be a mistake, and it probably depends on the driver what would happen. I know that some drivers range check the hue value, but I don't know if all do or not. From above:
I feel like a users will figure it out pretty quickly when the light either doesn’t change color and throws an error to the logs, or changes to the wrong color. 
I’ll double check my implementation of this in my drivers. Thanks for the heads up that this will be in an upcoming release.
Tagging users to double check their lighting drivers for 0-360 hue compatibility:
@anon61068208 (Shelly driver) @damon.dinsmore (Tasmota driver) @Robin (Fibaro driver)
Tag others I’ve missed
(Feel free to grab my limit/clamp methods from any of my drivers. I’ve been thinking of how to clean it up, so I’m all ears for ideas)
I have had issues where I do see a error only when setting the colour via a rule or the simple lighting app.
Voice control seems to work though.
My Drivers use the 1 to 100 range of Set Color but if Hue is set above 100 it would not error as it would catch this. It does the conversion to HSL so any number over 100 would be set to 360. So my drivers do the error checking.
FWIW, CoCoHue will (apparently like your driver) set values below the accepted range to the minimum accepted value and values higher than the accepted range to the maximum accepted value. It looks like Hubitat's generic drivers don't do anything to prevent you from sending out-of-range values (but obviously they do correctly scale either 0-100 or 0-360 to the appropriate bulb values--there's just nothing to keep you in that range), so they'll do whatever the bulb does (likely nothing) when it gets an out-of-range value: HubitatPublic/examples/drivers/GenericZigbeeRGBWBulb.groovy at master · hubitat/HubitatPublic · GitHub. The default Hue integration also doesn't do anything in such a case (not sure if it sends something to the Bridge and the Bridge ignores it or if it knows and just doesn't try).
I wasn't sure which direction to go with my drivers but erred on the side of doing something vaguely similar to what the user probably wanted, even though this shouldn't really ever happen. I'm willing to change this (or not) if someone can make a more compelling argument for either behavior. 
But then, if a user is expecting a value between 0-360, anything 0-100 would be rendered unexpectedly, no? Included drivers have an option that parses it down. I’ve got my drivers (I think they still do?) to have an option, but still try to correct for values over 100.
What errors are you seeing?
What error are they throwing?
Seems like a good approach.
It would be out of range and the math would just bring it down to the top of the range. But I agree with you that an attempt to get where the user is looking for would be a good approach. But also thinking that a note to use 1 to 100 scale in RM would be just as useful. It isn't a big deal either way to me personally but users could be confused. The other problem is that if they use a number 100 or below then it will act wrong for the ones using a 360 scale for that range. And since the set color button in the driver doing the 100 scale you have to have a catch for that regardless and there is not really a way to catch which is which.
Would it make sense to have a parameter for setColor—perhaps String: HueResolution: 100 or 360 (which would default to 100). This way, we could adjust the hue based off of what an app is choosing. Drivers that don’t support it would just ignore the parameter, so it wouldn’t break anything, as far as I can think? It would also save a preference for each device.
Of course, it’s an extra layer of management for drivers, which is a downside... but it seems like a lot of us have this built in as a user-preference already, so we would just need to change the verification check from a preference to params.HueResolution == 360 ? ...
I agree adding that adding a preference option to the driver is the best course of action to deal with the proper ranges. And its simple to add.
Yup. That’s the default for HE’s drivers. Dividing values by 3.6 is easy 
I’m just wondering if it makes more sense to change it to a parameter in the setColor map that lets a transmitting app select what range to use.
Adding a parameter would break drivers that expect only three if you pass a fourth, which would be every driver out there right now (and would require a change to the capability as it currently is documented). EDIT: Wait, you mean in the map, not a separate parameter. That I could see...
The proposed RM fix is probably a good compromise. If you turn on high-res hue, just be sure to know what you're doing. If you don't, keep it off and use the drop-down colors (which already don't work for 360-degree hue, again because I'm guessing there's no standard way for an app to know whether a driver has this setting enabled...and I'm guessing most other apps don't work well with this either). It's probably something you should enable only if you have a specific need and know what you're doing. I'm guessing Hubitat added it to a few stock drivers due to specific requests or to experiment with other ideas for a newer, unfinished color capability model.
Aren’t setColor parameters sent as a map, though?
Is it really? Let's say someone enters 1
You do 1/3.6 = 0.2777778
You do a round() on that and get 0
So, did someone enter 1 or 0????? 
Let's get the math majors here to argue about that one.....
Yep. A d'oh moment, which also means my suggestion for a custom command workaround will not work since you can't pass maps.
I’ll just pass it to the device as-is and let it decide 
As you suggested, I set a custom action for my Sengled element color plus bulb, but it doesn't seem to work: 
When I hit "Run Actions" on this rule, the first and third actions work but the action in the middle (setColor(50,98,75) on Sengled Lamp) has no visible effect on the bulb.
Am I doing it wrong?
No, I was wrong--I mentioned this later but forgot that setColor takes a map (a parameter type that RM doesn't let you input), not three separate values.
However...firmware 2.1.7.121 was just released, which lets you use values from 0-360 (under the assumption that you know what you're doing and will only use values your device allows). So...no need for any workaround at all anymore. Yay! 
Do you know ...
Is it correct that the Hubitat color model is HSL and NOT HSB or HSV?
Thanks,
jim
The built-in model is HSV/B.
Download the Hubitat app
