I renamed "Ceiling (front)" and "Ceiling (back), added the parenthesis. These groups are functioning as expected. The new group is "Ceiling (all)" and is the group missing. All the other groups are actively being used and were present before the issue started.
Anyone have hue play bars? Will they play nice with this integration?
Yes, they work the same as the bulbs. Can't notice any difference in color or CT rendition.
I've released v2.0 Preview 5 (skipped 4 because I forgot I hadn't already used it; oops) with two minor changed from above:
- More logging when retrieving bulb and group lists from Bridge
- Improved handling of SSDP (Bridge discovery) requests that should eliminate errors if non-Bridge devices respond
For the logging (the issue noted by @bbholthome), what would be helpful here is to turn on debug logging for the Bridge device, where the group list logs will originate, and see what is listed there. When you view the "Select Groups" page then, you should get a debug log reading All groups received from Bridge: ..., followed by a list of group IDs and other information, including the Hue names. You can use the ID to match up with the Hubitat device (e.g., the DNI of CCH/abc123/Group/5 should have ID 5 from Hue in this log output) or Hue room/zone names (which should match the name shown for this group in the output). CoCoHue should show you that list, so if not, I can look into what that problem is. Otherwise, the Bridge must just not be returning that as a group for some reason.
1 Like
The new debugging worked like a charm. The problem is similar to:
I deleted a group before I added the new group. Hue reused the the ID of the deleted group for the new group.
The issue seems to be not remembering I did that and not reporting it. My only defense is I did the changes a week before I reported the problem. 
Thank you for the quick response.
Interesting! I've only seen Hue re-use old light IDs if you went over whatever some maximum value was and it wrapped around. I've never paid attention to groups. Glad the new logging helped you match up the IDs and figure it out! (Some day I plan to show both Hue and Hubitat names in the UI to make this easier...somewhere.)
1 Like
Not sure if it's a bug or not, but I seem to be getting two entries in my log whenever a light changes (ignore the unrelated debug logging). Front Door Wall Light and Front Door Right Wall Light are two separate bulbs on my hue bridge.
I assume you're still only getting one event (the "Events" tab/button on the device page) for each of these? If so, I'll see what might be happening that makes the logging happen twice, though I'm not sure I've seen this myself. I assume you're on the latest preview?
Good question, I hadn’t actually looked. Yep only one event showing up. Yep latest version or at least the latest version published via HPM.
Hey everyone - noob here. I installed the CoCoHue app via Hubitat Pkg Manager but am unable to control my bulbs upon switching everything over to the CoCoHue drivers. This is the error message I get:
am [error] Cannot get property 'fullHost' on null object on line 491 (off)
am [error] groovy.lang.MissingMethodException: No signature of method: hueIntegration.getBridgeData() is applicable for argument types: () values: [] on line 490 (getBridgeData)
Any advice?
I am not certain what your process was, but the drivers assume that the devices were created by the CoCoHue - Hue Bridge Integration App. If you are trying to use devices that were created from some other process, they will not work as expected.
1 Like
Hi @bertabcd1234, sorry if this has been asked before but I noticed the state of a group doesn't get refreshed after you turn on a scene, and only the scheduled polling or manual refresh of the bridge makes the changes from the scene update in the devices.
Would it be possible to add an option to automatically refresh the bridge after a scene is triggered?
I'm adding a refresh on my RM rules after each scene trigger, but a global option would sure be nice.
Thank you very much!
I have some changes in an upcoming release that perform better heuristics for on/off on scene devices (activating another scene from the same group can be configured to make the switch state of other scenes in that group turn off, with other options for how to handle this as well). However, I don't have anything for that at the moment. I'll think about how I might be able to add an option to do that. While the Hue API can provide information on the expected bulb states for scenes in specific cases (which could theoretically be retrieved once and then updated without polling in the future--but what if the scene is re-saved differently?), I'm not sure I want to go down that path, so I agree that polling is probably the best option to update the group and light states. Providing an option to perform a poll either immediately or shortly after scene activation seems like it might be a good idea if you don't otherwise just want to increase your polling interval (though your workaround certainly also works with a rule). I'll see what I can come up with! May or may not make my next release that I hope to have out soon.
2 Likes
Yes, that makes sense. I don't want to increase my polling interval because I have 5 Hue Bridges, but the refresh option works fine.
Thanks for the detailed reply 
Greetings, all! I've just released version 2.0 Release Candidate 1, with the following additions compared to the last preview release:
- Improved bulb, group, and scene discovery: shows both Hue and Hubitat names for easier comparison, added links to Hubitat device page for added devices, and "abandoned" Hubitat CoCoHue devices (where corresponding Hue device was removed) are now listed
- Additional option for scene devices: optionally show other scenes in group as off when scene activated or show all other scenes as off (or do nothing, the pre-RC 1 default) [thanks to @tony.fleisher for this idea and the initial implementation, though I ended up allowing different options for users who prefer other behavior]
- Additional option for scene devices: refresh Bridge device after scene activation (on/push) or off command. Technically, these are scheduled for either 1s or 5s after activation (your choice per scene), so multiple successive activations do not risk causing excessive successive polls but only one (if done with in that timeframe) [thanks to @MrPancake for suggesting this idea above; I hope it is what you're looking for! ...but it must be set per-scene at the moment]
- Code cleanup with likely performance improvements
- Improved error handling for unexpected Bridge responses (or non-Bridge devices that still respond as some found above)
Code is available for manual installation from GitHub (see first post) or Hubitat Package Manager. Let me know if you find any problems! At this point, I'm likely to just release 2.0 final soon (I'd already consider this stable and have been using it on my main hub without problems since the previews) if there are no problems and consider a few additional features I had in mind for an upcoming 2.x release.
[EDIT: I had to make HPM use version "2.0.0-rc.6" for this so it thinks this release, RC 1, is newer than the last, Preview 5. It is, in fact, RC 1 and not RC 6 if you happen to have looked this closely and were wondering. I'll probably have to do similar trickery for the final version...]
2 Likes
Thank you so much, that's working perfectly for me.
Greetings, everyone! I've released CoCoHue 2.0 (final), now available both in GitHub (link in first post) or Hubitat Package Manager. This is similar to RC 1 with only a minor bugfix in the app for scene discovery, but I did change the version number in all app and driver files to say "2.0" in the comments at the top for ease of identification, so I'd update everything regardless if you want to be super-sure.
If you've been holding off as 1.x user until 2.x was out of "preview" stage, now is the time! (Though I've considered 2.0 stable for a while--just had a few features I wanted to get out before the final version, while getting it into HPM and not getting new users started with the old 1.x parent/child app structure; see the notes in the readme or first post if you're upgrading from a manual 1.x install.) For those who haven't been following along, other new features and changes in v2.0 from v1.9 include:
- Bridge discovery! I'd still recommend using manual configuration if possible, but by default, CoCoHue will now use SSDP to "discover" Bridges on your network. The Bridge discovery process has also been simplified, with fewer pages to navigate through.
- Improved bulb, group, and scene discovery: shows both Hue and Hubitat names for easier comparison, added links to Hubitat device page for added devices, and "abandoned" Hubitat CoCoHue devices (where corresponding Hue device was removed) are now listed
- Additional options for scene devices: optionally show other scenes in group as off when scene activated or show all other scenes as off (or do nothing; still the default); additional option to refresh Bridge device (and therefore device states) after scene activation (on/push) or off command (default is still not to do this)
- Added ability to add "All Hue Lights" group to Hubitat (note: will sync only on/off states from Bridge; other attributes manipulated only as a result of changes from within Hubitat)
- New "'Start Level Change' rate'" option: all bulb drivers have this option added, which affects the speed of the transition up/down with a "Start Level Change" command. The default is the same, relatively fast speed as before, but two slower options were added. This is something Hubitat has added to a few native drivers recently, and I thought it was good to follow suit.
- Bridge "status" attribute (online or offline) updated according to best guess as determined by Hue Bridge responses when sending commands or polling (or trying to)
- Drivers now do not report device attribute/state changes initiated from the Hubitat device until the driver hears back from the Bridge. In my experience, this is still almost as fast, but in all cases, it should be a more reliable indicator of actual device state
- Code cleanup with likely performance improvements
- Improved logging and error handling (and logging of errors, including showing more from Hue that CoCoHue may have previously "swallowed" without showing user); reduced (eliminated for all but rare core app tasks) logging when debug logging disabled
6 Likes
Thanks @bertabcd1234 for all your hard work on your apps. CoCoHue paired with LOMP (Lights On Motion Plus) have been enjoyed by all in my home.
2 Likes
Hi,
I am a current ST user and have started looking into transferring to Hubitat as the writing appears to be on the wall for the ST platform.
Currently, I use the Hue Sensor (Connect) SmartApp to link my Hue Dimmer Switches paired with my Hue Bridge to my SmartThings Hub - I like the responsiveness of the Hue Switches and they are extremely reliable, and the SmartApp enables WebCoRE to react to the switch being used (e.g. if I press and hold the 'Off' button on the Hue Dimmer Switch ST then turns off all the other non-Hue outlets in the room. Another use case for me is that when the 'Off button is pressed on a particular Hue Dimmer Switch a variable is updated in WebCoRE to avoid the lights being turned on with motion for a number of hours, useful in bedrooms when you turn the lights off and want them to stay off until morning).
Is there any plans for similar functionality to be brought into Hubitat that the Hue Sensor (Connect) SmartApp currently provides in ST please?
I've considered if and how to implement "sensors" (button devices, motion sensors, etc.) from Hue, but the issue--as you can also read in that thread--is that the Hue API does not have a way to "push" changes to third-party integrations; the integration has to poll. This means that even in the best case, there is likely to be at least a few seconds of delay, but in others even up to several minutes or whatever your polling interval is. I see that SmartApp has some tactic to mitigate the effects or this, but it's not clear to me what that is (polling more frequently when a specific ST-connected sensor is active, suggesting you might be using a Hue device in that room?).
In any case, for the Hue Dimmer or Hue Motion Sensor (indoor or outdoor), you can pair those directly to Hubitat. You can do the same with some other Hue-compatible products like the Lutron Aurora. Zigbee Green Power devices like the Hue Tap are notable exceptions, not currently supported. If you want functionality on both Hue and Hubitat, that would be my recommendation--even if this is implemented some day, you're still likely to get better behavior that way. Hubitat also has a variety of natively-supported button devices lilke Pico remotes (my favorite!), the ST Button, Eria Remote/Dimmer, and many of the Hue ones I just mentioned. But I'm guessing you're asking since you already have a bunch of Hue devices.
So while I'm not sure if or when I'll do this, in the meantime, you may still have options. Hope that's helpful!
2 Likes
