Yes, this is the expected behavior for the reasons I noted above. The poster above is also correct, and this is pretty much the same reason: Hue does not have a way to turn off a scene per se:
Polling is used to retrieve light and group states from the Bridge, useful if changes are made outside Hubitat, though also useful to get new light states when a scene is activated since either those settings have to be retrieved and cached from the scene on the Bridge at some point or the new states just polled for after activation (I don't implement the former at the moment and don't plan to since it's basically different kind of polling, but I might try to think of something better here). But an off() (or on()or really any) command to a bulb or group should be immediately reflected in Hubitat.
I was hoping to move all my lights from the built-in integration over to CoCoHue but haven't been able to get CoCoHue groups to work with the Google Home integration.
I suspect there is an attribute missing from the group device that Google Home is looking for but I can't work out what.
Has any one used CoCoHue together with Google Home successfully?
I'm not sure what "attribute" would be missing--I'm implementing all capabilities, including required commands and attributes, on the RGBW bulb driver and doing the same for groups, as they are nearly identical. I haven't tested this with Google Home. I have a friend with GH who I could test this with (I don't have one myself), but I'm not sure if that would actually help me figure anything out if they just aren't showing up.
That being said, my preference with things like this (I do have mine integrated with Alexa) would just be to use Philips' native GH integration via the Bridge. It's one less thing in the middle, and it already gives you access to Hue lights, scenes, and groups with no extra effort on your part. It does mean you'll need to rely on polling to see these changes in Hubitat (so they won't be instant), but that's the only disadvantage I can think of.
Yes the bulbs integrate fine with Google Home. However since there the only bulb driver and group drivers are RGBW the Google Assistant is expecting to see states for all of the attributes, including color and color temperature. If you are using a White Ambiance or White bulb these won't return these states to the driver. As a result, the integration won't work by default with anything other than a "true" RGBW bulb.
The workaround, until we get drivers specific for the non-RGBW products, is to go into each bulb/group in the device page and select a color and CT manually. This will populate the attributes and fix it.
Ah, so I think I see the issue: Google Home needs all the attribute values populated, which would normally happen during either the first poll or by manual manipulation of the group device. However, that won't happen in a group with no color and CT devices. I don't see a good way around this without either initially populating the attributes with some default value (warm white at 100%? Some vaguely yellow color?), but the best solution would be to have different group drivers with different capabilities (which I also don't have much for in the way of bulbs right now, but consider the contributed one above). I'll consider doing that if possible (not sure the Hue API exposes a "type" for the group like it does for bulbs), as much as I'd like to avoid having a million different drivers.
In the meantime, I'd suggest manually manipulating the group device once so all attributes get a valid value. Apparently they will make GH happy. Thanks for noting this, both of you!
Wouldn't groups always be RGBW in case any of the component devices are RGBW? If the device doesn't support the command, it should be ignored by the Bridge, shouldn't it?
I assume so, but the attribute values will still never get populated (because there won't be any matching states in the JSON returned by the Bridge for the group) if no devices in the group actually support those capabilities, and apparently null attribute values are a problem here (and I know not good practice in general, but something you'd only run into in this case for now). So it's really the other direction, bridge to device, that we're talking about.
I don't know. I'll have to add a new Hue Group from Hubitat's integration to my test hub for a Hue group with only white or CT bulbs and see what they do (my guess is populate something).
I would assume so as well. I don't have all that many Hue lights and don't use them in the hue app...so I only have one group. So I've never used them like that.
I have noticed that the RGBW driver doesn't "hold" the color name correctly in CT mode for some of my lights. It will briefly be correct when I request the CT but then will revert to the last used RGB name shortly thereafter. I am using the latest driver.
Can you verify that Hue still reports colormode: ct from the Bridge (or diyHue) when you see that? My guess is that it might be flipping to colormode: xy, which my driver will interpret as RGB, even though it really only handles (like Hubitat) colormode: hs right now. So the ideal outcomes are:
Bridge colormode: ct -> Hubitat color temperature name reported as color attribute, Hubitat colorMode reported as CT
Bridge colormode: hs -> Hubitat color name reported as color attribute, Hubitat colorMode reported as RGB
but there is a third gray area where:
Bridge colormode: xy -> Hubitat colorMode reported as RGB and Hubitat color behavior is...probably whatever the Bridge reports for hue and saturation but definitely not what it reports for xy (no idea if the Bridge converts the other and adjusts its value when one is changed or just holds on to the last explicit value for either)
Since I'm not really handling that third area at all (some day I hope to figure out XY to HS conversion for the sake of Hubitat), I don't have a good reason to do anything there. I could just set colorMode to RGB if the attribute isn't currently set (likely the first time the bulb is polled after adding), otherwise leave it alone?
In any case, I have a bunch of RGBW bulbs and can do some testing with this...I think. With recent Hue Bridge firmware updates (or at least I think this is what caused it), I have a hard time getting the Bridge to stick in either CT or RGB mode. It seems to favor XY mode regardless of whether I set color or color temperature, often not if I manually manipulate them but now seemingly always if I save and recall a scene set this way. I reported this here but apparently nobody else cares as much as I do.
Thanks for checking! I'll see if I can figure out something here. For the next release, I'm aiming to re-work the way information from the Bridge is parsed (going in a specific order looking for specific "keys" first and ignoring things like hue and sat if the current mode isn't hs, for example), which might be the ... wait for it ... key to solving this issue.
Minor correction on the driver name for On/Off plug/Light.
The instance child app is looking for "CoCoHue On/Off Plug/Light" but the driver name is "CoCoHue On/Off Plug". Changing the driver name and added the device. The plug work great. Thanks for adding this option. Been waiting for a while from HE for this.
2020-01-03 21:00:40.049 errorUnable to create new device for 48: com.hubitat.app.exception.UnknownDeviceTypeException: Device type 'CoCoHue On/Off Plug/Light' in namespace 'RMoRobert' not found
I ch I checked through the attributes for a group and found the rgb colour settings weren't populated (I'm only using CT bulbs). Selecting a colour there then allowed me to add the group into Google Home.
I've now added new Zones via the Hue app for all of my multiple bulb fixtures and am able to control the bulbs in a much more synchronized fashion than with the built in drivers.
I mentioned this in another thread, but the name you see in the error logs (from the Bridge child app) is what I originally planned to name this driver. I renamed it to just "Plug" because I think the difference between a plug and a light is that a light would support flash()-stye commands (in Hue terms, either alert: select or alert: lselect), which I left unimplemented in the plug driver sine the only one I tested with (a Trådfri outlet) did not support this--plus I'm not aware of any on/off-only Zigbee bulbs, with all I'm aware of also supporting dimming, which I'll have a driver for at some point.
If anyone has a Hue Plug feels like confirming that flash() doesn't work, that would be great! (You'd just need to un-comment-out the flash and flashOnce commands in the code and try them to see if either works. My guess is no. Even if they do, I think I might leave it up to people to uncomment those lines if needed, since I already know it definitely doesn't work with everything).
Any chance on the next release you could also considering some kind of link from scenes to groups a user could specify to allow scenes to be turned off? I know you referenced that possibility when you first outlined CoCoHue and based on my own hopes and other questions in thread looking for this functionality, it seems like it would be very useful.
