Good idea about removing the capability "Light". Now much easier to use in Google Home! Wonder if it would be worth adding this to device preferences?
Does this bring in 3rd party bulbs connected to the hue bridge?
Yes, it does not distinguish as long as the Hue Bridge can "see" them. (Hubitat's native integration should work this way, too, though last I checked there were some entire device classes, like on/off plugs, that it ignored; mine does not.)
4 Likes
Pretty minor issue (or maybe it's intended?)... I have all logging turned off for this app, but it still prints DEBUG Sending request for Bridge information every couple of minutes or so.
Not really a problem other than it being debug log noise. I noticed while debugging my own driver.
When I wrote it, I meant for it to be intentional since it should only happen when you have the app open to one of the pages for adding or discovering a Bridge. But I see that it can happen any time the hub responds to an SSDP (discovery) request, which anything on your network could technically generate. CoCoHue will only do it if you have that window open or there is a problem communicating with the Bridge and you have discovery enabled (suggesting the IP address may have changed, so it's sending a request to try to find it).
You may want to identify if something on your network keeps sending these requests. Otherwise, I can think of some way to modify the logging so it only appears during initial setup (where I think this is helpful, regardless of logging settings) and not as part of potentially regular use afterwards. Thanks!
1 Like
I've released CoCoHue 3.5.1, which is more or less a minor update that addresses some issues above: SSDP receipts are not logged with debug logging disabled (I figure you can find the same info in System Events, and if something is doing this on your network a lot, I'd probably figure out what); Bridge usernames are now truncated to what might be Hue's maximum, so hopefully fewer/no errors with those requests anymore; and the "Light" capability has been removed from the Scene driver (so Alexa will not group them with lights, which the consensus seems to be is problematic).
Internally, I've also made a big change: I've utilized (internally--no need to add these yourselves) the new "Libraries" feature in Hubitat firmware 2.2.8 to facilitate code re-use among CoCoHue drivers, which should make them easier to maintain going forward (and eliminate copy/paste errors and make it easier to develop new drivers if needed--less-featured Group drivers or RGB-only drivers, for example). By "internally," I mean that everything I'm sharing in the HubitatCommunity repo right now is "precompiled," so you don't need to install the libraries yourself--I'm including them directly in the drivers for now and probably for a while going forward (until 2.2.8 and later become more popular and HPM supports them). So, install as normal and don't worry about it--but let me know if I broke something by doing this. 
As usual, upgrades can be done manually (see first post) or via HPM.
2 Likes
Have you seen this?
New Hue API offers push message instead of pull command
The previous API could not tell you when the status of a light had changed. Instead, it was always necessary to ask whether something had changed. For example, an app previously had to send a request to the bridge every five seconds: “Has the status of the light changed?” The answer used to be “No”, or “Yes, the light in the kitchen is now on.” This method naturally led to certain delays.
2 Likes
Is this how you activate the scene by using a push button in RM?
I've seen unofficial posts about people figuring that out, but nothing offiicial (I started looking after Home Assistant began using it last month). If you have a link there, it isn't working for me, so I'm not sure. I have experimented with this on Hubitat, but it relies on a secure HTTPS EventSocket connection, and even after some changes they made (I asked 
), it still doesn't work for me. I'll keep trying, but I'm hesitant to do much until it's official.
That's how I'd do it, yep!
1 Like
I just stumbled upon this:
Apparently it may not be actually working yet?
I know that my Homekit integration with Hue has been acting up occasionally since the Hue update. Occasional unresponsive devices across both Hue bridges (only in Homekit, not the Hue app or HE) that I wasn’t experiencing before. No problems with your integration though.
The immediate Hue push updates for status are working on Home Assistant. That is why the above is being deprecated.
The last this the dev posted on that thread was:
“You are totally right! it isn't working, apparently” 17 days ago. Which is why I thought it might not be complete. I don’t use HA, so I have no personal experience.
Hello,
With the latest update, whenever I have a command to "set level and color", like this:
I get the following error:
org.codehaus.groovy.runtime.InvokerInvocationException: groovy.lang.MissingMethodException: No signature of method: user_driver_RMoRobert_CoCoHue_Group_303.getScaledRGBTransitionTime() is applicable for argument types: () values: (method setColor)
Anything I can do? Thanks!
I believe I have found and fixed this problem. I have updated the group driver to version 3.5.2, available in HPM or manual install. Thanks for the report! (For future reference, the driver in question would be helpful to know--this is what I found after looking around for a bit, so let me know if it's not right!)
Also, if that is an app like Rule Machine, Button Controller, or SAR (and your bulbs aren't RGB-only like the first-gen Hue Lightstrips or certain Ikea bulbs), I think you will be better off with the "Set Color Temperature" action and specifying a color temperature around 2700. The "Turn On & Set Color" action, despite the fact that it lets you select "Soft White," uses color/RGB values rather than color temperature, and it's a poor approximation on most bulbs.
2 Likes
Pulled the update and the error disappeared. 
Indeed, almost all my Hue devices are groups...
I do have 2 old(er) lightstrips so I'll leave those alone, but I'll try setting color temperature for others.
Thanks again!
My log has loads of this message in: " dev:3042021-07-30 10:54:48.159 warnRefresh CoCoHue Bridge device instead of individual device to update (all) bulbs/groups"
As far as I know I am not directly asking for a refresh anyway - just turning on a light in a rule. What does it mean for me? Shall I just ignore it?
And... I don't believe I did this. I clicked Remove in a lapse of concentration thinking I was deleting a scene, and instead removed the app. I take it I now need to remove ALL the devices that were previously set up before reinstating?
What is device 304? Clicking the "warn" text in the log will take you there. Something is calling "refresh" on this device. It doesn't do anything at all besides log that message, so it should be harmless, but I'd still be curious what is calling that command.
And yeah, you would need to remove any existing devices you want to re-add. The devices get created as "child devices" of the app (there is no way to see this in the UI, but it is how that works), and there would be a conflict of DNIs if you try to use two instances of the app to add the same devices. There is also no way to "take over" a device created by another app as a parent/child.
But...restoring from a recent backup would probably be easiest.
You know I got half way through first removing the rules that used them, then half way through the devices, when I had my DOH!!! moment and restored the backup lol
That warning was just one of the devices that do it. As far as I can tell they're all doing it, and I haven't yet identified what sets off a fit of the warnings. Will let you know if I work it out.
