The missing command was added to Hubitat with version number 2.3.2 of Hubitat. We are currently on release 2.3.4.127, it seems you Hubitat software is out of date.
Also, if you don't want to update to the latest version of hubitat software, I added a check for hub version, so that color name attribute is not populated unless running a supported hub. This way you aren't forced to update just yet.
If you want to have HPM enforce the restriction you can also set the minimumHEVersion in the manifest to exit any attempt to update with a notice that they aren’t at the required level to run the new version.
I know. I did that, but then I undid it, as I figured it would be stupid of me to force the minimum hub version just for color names. So instead, I decided to let them run older hub software if that is what they want to do, since it doesn't really impede my ability to perform any real operations. The color name computations are just a nice to have.
UPDATE:
I have noticed that my hue API news feed wasn't working and I missed that Hue has finalized the v2 API. As such, all the goodies I have been waiting for to fully convert to version 2 appear to finally be available. Most important is that the v2 event streams now accurately report group state changes when lights within the group change. This means that I have removed the full hub refresh logic that attempts to rectify this old limitation in the v2 API. If you update to my latest code that I just published, you can turn off all the auto-refresh features (recommended) in my hue code, except for the hue hub device. I am recommending the hue hub use a 30 minutes, or 1 hour refresh interval just to keep things in sync, in the event of minor communications outages, but otherwise relying on the event stream from hue to hubitat to capture the state changes.
I have not yet retired the v1 API calls in my code, but I will be working on that now that things are working on v2 (or should be).
And, of course, no sooner i post this, I noticed the groups still are limited to only reporting on/off and dimming level, so for groups, I will have to force a query on the group itself. This will still be better than a full fresh. Another update coming soon.
Worked out a solution that forces a per-group refresh for each affected grouped_lights detected from the event stream. What this means is that instead of updating the entire hue system when any device is changed, only the devices actually affected by the change are refreshed. This should reduce the hub load for this integration, while working around some v2 limitations.
There is a known issue that occurs when mixing v1 and v2 updates. For instance, when I change my office light from white to blue, it may report orange or some other color for several seconds. This is data coming from hue, and there isn't anything I can do about it. I am researching to see if using the v2 device refresh will be more reliable.
Another issue with Hue is that if you use the Hue app to set a color temp on a color bulb/group, the hue app now reports xy colors and translates them the hue/sat, or color temp. the problem with this, is that it never report the color mode as switching to color temp, and so there is no way to know if hue is in color temp or RGB mode at this time. fortunately, if you use something other than the hue app, this problem goes away, so it appears to be another regression bug between hue v2 and v1 API.
Please let me know if you have any issues.
Hi Simon,
Did you ever get a solution to this? I'm seeing exactly this. Have a scene under a room which has some of the lights turned off. All lights activate then the ones that are supposed to be off switch off. Using the Hue app the lights do not activate and the scene works as expected, only the lights that are supposed to activate turn on.
Thanks, Alistair
This sounds different to me. In this case, it sounds like you are turning in the room, and then setting the scene. Please confirm, if the lights are already on or off, how are you activating the scene? The way I intended this to work is that from the off position, simply call the setScene argument, and pass the scene name/if you want turned in. Or if you have a child device for the scene, just turn in the child device only, which in turn should turn on the group when the scene is activated.
In Hue I have created a room with all the lights in it. I have then created a scene in Hue with the lights that I want on turned on and the lights I want off turned off. From Hue if I activate this scene from all lights off only the lights that are turned on activate.
In HE I have a device for the room (AdvancedHueGroup) and under that are some child scenes (AdvancedHueScene). I only activate the child AdvancedHueScene device from a Button Controller. It also happens if I activate it while in the AdvancedHueScene device.
Hue troubleshooting round 2.
I recently added a hue bridge and 3 bulbs to my setup. At first I was having issues with the built in integration missing some events and not turning a bulb on or off.
A month or so ago I switched over to this integration and things seemed much better and more responsive. But I just started seeing the same behavior again.
For example last night one light came on with a motion trigger thru simple automation rules, but never turned back off. In the logs, I can see where it sent the off command, and reflected the switch state was off. However the bulb was still on.
This morning was the inverse, the bulb never came on but I could see in the log it looked like it did. I manually toggled it from the device page and it seems to be working fine.
Does this sound like a hubitat/hue communication issue or more like hue not making a good connection with the bulbs? Hubitat zigbee is on 20, hue 15, and wifi down on channel 1 to try avoiding issues.
I confirmed that when calling the activate scene, I simple send the scene to activate to hue, nothing else. The behavior appears to be in hue bridge, not my code, but I wonder if there is something Incan do to force hue to not do this.
Q: In hue hub, are bulbs official hue bulbs, or third party? If official Hue bulbs, what are the bulbs set for default power on state?
Since they have been migrating to the v2 API, things have been breaking, and I am trying to work around them where possible. One possibility is that might be able to do the scene activation over V2 API and see if that works better. But I need to reproduce the issue and in my home the only bulbs i have that do this are sengled bulbs that are not hue certified.
I have hue on default channel, and Hubitat on default channel and I leave WiFi on whatever channel it chooses. They play well together, and using any WiFi channel other than the middle ones causes WiFi performance to suffer. If you have a 40MHz band on channel 1, you will only get 20MHz. Same if you have it on channel 12. So I think this is going a bit to the extreme to address the issue.
Hue’s documentation limits bulb commands to 10 per seconds, and group commands to three per second. Set hue, and set level as two separate statements is two separate commands sent to hue hub. If you send too many, the hub will stall out. The V2 protocol will increase this a little, but ultimately, hue is having issues right now. I have hue talking direct to home kit, and talking direct to Alexa, as well as my integration for HE, and the behaviors are inconsistent. In HomeKit, I converted over to the matter api, so hue uses matter with HomeKit and things work really well in HomeKit.
I will do what I can to work around these issues, but I suspect until I am able to convert fully to the v2 API (which has a lot of missing features) new issues will continue to creep up on us.
Make sure your refresh is not very aggressive. Rely on the event stream to handle device refreshes. Rely on hue groups over HE groups where possible, and try to limit how many update calls you make (mirror me app, for instance, puts a huge strain on hue)
Yes, all official Hue bulbs. Mixture of GU10, Candle and B22 fixtures. All do the same thing.
Great idea trying the power fail default but that didn't help. Verified I had set it by turning power off and back on for the circuit and they stayed off when power came back unlike previously when they all came on full.
You are right, it is probably a Hue hub issue. If you want I'm happy to test a V2 version.
Thanks, Alistair
I just went to check what the refresh was set to and noticed the parent device show's that the bridge has been offline since Sunday. I know it was working after that.
Anyway I don't see any time refresh options. In the main parent device there is a auto refresh option, but that is disabled.
Click the connect button to reconnect the event stream, and turn on auto refresh, but set to like 1 hr. This way you don’t overload the HE hub. That’s a start. I am looking into things to try here as well.
I just did that. I guess not having the auto refresh on is what led it to showing offline for several days. 
Is there any kind of logging on the hue bridge that can be seen via the API or anything? I found a docker container for hue bridge debugger, but it really doesn't do much besides showing the current states of everything in a sort of xml looking layout.
No, not that I know of. Cannot pull hue logs
Is it possible to fade in scenes. I'm assuming not since the Hue app doesn't appear to offer this.
@armand Is it possible to adjust the sensitivity of the motion sensor through the app? There is an option to do it in the Philips app but only if you tie it to a particular room and lights. I have found that one of my sensors is too sensitive and could benefit from a reduction in sensitivity. Thanks.
I just ran some tests, and it appears yes, I can. I am working on some testing, and reading the documentation, but I will add this to each of the sensors I support. Motion, Temp, Lumens, etc...
Download the Hubitat app
