[RELEASE] CoCoHue: Hue Bridge Integration (including scenes!)

Yes, however, as noted, I don't have dedicated drivers for them yet, so all lights (and plugs) will be added as RGBW bulbs. This won't cause any problems except that you should be aware that, of course, nothing will happen if you use setColor on an Ambiance bulb that only supports color temperature (and similar for other devices where the driver will report more capabilities than the device really has).

1 Like

This looks promising. I wish the built in Hue Integration was this feature rich. I've been unable to really use the Hue effects because turning them on and off in the app is tiresome. With this I can actually automate when to use them.

1 Like

Thanks for the app, works very well!

Are you adding Labs? I think someone has done it on ST with hue B.

I'm not sure what those are. If there's a use for something, I could read into it more.

They are within the hue app, below is a Xmas example they have at the min. And there are loads more.

I just looked at a few of these. It appears they create Schedules and Rules on the Bridge. I don't have any integration for those currently, and I'm not as familiar with how those parts of the API work as I am with the ones for lights, groups, and scenes. It may be possible some day. The Christmas ones look pretty cool, but no guarantees I'll get around to it before then :slight_smile: (or possibly ever...haha).

I've just released CoCoHue 1.7, with updates including:

  • Automatically updating group state when any member bulb states are manipulated--this is an extra feature Hubitat's integration does not implement, which I added per user request (Hubitat and CoCoHue both already manipulate bulb states when group states are changed). This improves speed of getting these changes since it no longer needs to wait for a refresh/poll, just as it has already done the other way around. I may add an option to enable/disable this (or both) if anyone doesn't want it and manipulates a bunch of groups at one time and doesn't care to make the hub do the work of finding any affected bulb

  • Added option to show non-group scenes (scenes not associated with room/zone, mostly from third-party apps or older versions of the Hue app)

  • New plug (on/off) driver, which I've tested with the Trådfri outlet on Hue (if anyone has the Hue outlet, I'd be curious--especially to know if it supports the "select" and "lselect" alerts, e.g., flash(), which Trådfri plugs, and I'd imagine most others, don't); I'm still planning on releasing dedicated drivers for RGB, CT, and dimmable-only bulbs in the future, basically as soon as I've received enough feedback on the existing RGBW bulb and most people seem happy with the featureset.

As always, feel free to post any feedback here (especially if you notice problems I should fix). Thanks!

Thanks for the latest updates, just installed and will provide feedback if I find any issues. So far the integration has been flawless for me. Still looking forward to the addition of the non-RGBW drivers when they're ready for release.

I’ve been using your app since I set up my second hub and have not had any issues. Plus, the group dimming works flawlessly! This is especially evident in my kitchen where I have 9 Hue lights and 3 Sylvania rgbw HO recessed lights. The hub dims everything perfectly in sync from a single dimmer. I appreciate your great work on this.

1 Like

I just released a small update, v1.7b, making a small change per user feedback. This modifies the behavior of startLevelChange() in ways that should not change any behavior if it was working correctly for you before but should avoid problems for others.

(If you're curious: this is likely DiyHue-specific and should help if you noticed issues like bulbs turning off instead of just dimming to 1% with an un-stopped startLevelChange(down). My new implementation is similar to how I implemented these commands in earlier versions of CoCoHue and basically un-does the change I introduced in v1.6b to match Hubitat's stock behavior, which I though it might be wise to imitate but it turns out causes problems for some. Again, for most people, the behavior should remain the same.)

1 Like

You mentioned being able to turn off a group for a Group Scene. Is this implemented? I think this would be very useful for motion lighting where the Scene is turned on when there is motion and then off after a period of time where there is no motion. I would like the motion lighting to call different Hue scenes by pressing different switches/buttons depending on the respective mode, but turn off the same group/set of lights after a period of time.

I assume in the scene that is imported as a switch/button, you would reference a Hue group of lights that would then be turned off? I'm not seeing where to do that currently with the latest version.

Right now that doesn't exist. Some scenes are associated with groups. In that case, I could make turning off the scene device turn off the group (this is is not currently how it works). Some scenes are not associated with groups, especially if you created them with third-party apps or still use scenes from v1 (and maybe v2?) of the official Hue app. I'm not sure how I'd handle that difference or expect users to know, but I'm open to ideas. Would you be able to just turn off the associated group device (or bulb devices) as a workaround?

Thanks very much for the quick reply. I could definitely do that as a workaround. Would be nice to have it included as part of the driver since it is another layer in hubitat to keep track of in the motion lighting app. If the group were somehow able to be associated within the driver for the scene, that would be ideal and would keep me from having to go to the 'Additional Switches' to turn off section in the Motion Lighting App.

I use scenes pretty extensively in the Motion lighting apps with Hue-B-Smart and do exactly what you suggested. I got excited when I read your comment about being able to turn a group off by turning off the scene, just because it is a little difficult to keep track of the additional switches/groups to turn off with all of the motion by mode lighting configurations I have across the house.

I have released version 1.8 of CoCoHue. Changes have been made to the bridge child app as well as the RGBW bulb, group, and plug drivers. Notable changes:

  • Colorloop effect will now report the custom attribute, effect: colorloop when in effect or effect: none if not. Previously, CoCoHue attempted to report "EFFECTS" as the value of the colorMode attribute instead as was found in most stock Hubitat drivers. However, this is tricky because Hue does not consider this a separate color mode, and I think this will work better in the long run. (May have caused problems with diyHue, too?)

  • Removed "alert: none" from on() command, which should not affect most users but now means that issuing an on() will not stop an in-progress flash(). The flashOff() command has been added to send this if needed. (May also fix unexpected problem on diyHue). Info logging has also been added to flash commands (Hue doesn't actually tell you if one is in progress and the driver doesn't really report an attribute change for that reason, but I thought it is close enough that most people would want to see it.)

  • Added options to disable bulb-to-group and group-to-bulb state propagation. Previously, both were enabled with no option to disable. The defaults for the new settings are consistent with Hubitat's stock integration behavior: bulb-to-group is off (Hubitat does not support this natively) and group-to-bulb is on. I have noticed that turning on multiple individual bulbs in a row is slightly faster if bulb-to-group propagation is disabled, presumably because it doesn't cause a bunch of iterations through group devices looking for ones where bulbs may be a member. Users who depend on instant group state changes (something I added per user request) will want to re-enable this on bulb devices.

  • Added new community contributed driver (thanks Ryan780!) in drivers/temporary folder for dimmable bulb. I have not tested this one and plan to release one soon (waiting until my RGBW driver is stabilized; I may change the way Bridge information is parsed soon), but you can install it and manually apply it if needed.

2 Likes

You are most welcome, sir! :bowing_man: But you did all the heavy lifting. Pulling stuff out of a driver is the easy part. :wink:

1 Like

I have a question about Turning On & Off imported Hue scenes in the CoCoHue app.

I'm still using the Hubitat built in app "Hue Bridge Integration", because I have a lot of SL and RM rules set up and running.
So right now I only imported my holiday scenes, as well as a few other Hue Scenes into the CoCoHue app to test. Also because I didn't want to duplicate the 49 Hue lights that I already have installed in HE.

The CoCoHue app imported all my Hue scenes just fine as Devices.

I noticed when I turn any of the scenes "On" in the new listed CoCoHue device listing, they turn on just fine.

But I also noticed if I tried clicking "Off" in the device scenes nothing happens.
I have the "Poll bridge every..." setup for 1 minute, and have waited for 5 minutes to click the Off button, but the lights still stay On. Is the "Off" button suppose to turn the lights off, or is it just not used at this time?

Thanks for any information!

IMHO, you can’t really turn off a scene. A scene is defined state that you can recall but you can’t undo the recall. It is the same for the Hue app, you can’t turned a scene off.

What would be your expected result?

Was thinking, since Turning ON a scene in the device cause the light to "turn ON, and change colors" form an off state. So turning Off a scene would a lest turn the lights Off from an On state.

Think of the scene switch more like a button, you can push it to activate but that’s about it. @bertabcd1234 implemented the switch on/off functionality to have more compatibility with apps that only support using switches and not buttons.

@bertabcd1234: I would recommend to automatically turn the switch back to an off state, like a momentary switch as you can’t really turn off a scene. I think that would make it clearer

1 Like

@dan.t
Thanks for that info!