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

⚙️ Custom Apps and Drivers Custom Apps
1

Introducing...

CoCoHue:
The Community Collection of Hue Bridge Integration Apps and Drivers

Manual installation instructions and code to install can be found in the GitHub repo:

or you can install via Hubitat Package Manager (search for "CoCoHue" or browse the "Integrations" category)

or you can install by importing the "Bundles" ZIP file: https://github.com/HubitatCommunity/CoCoHue/raw/master/CoCoHue-Latest-Bundle.zip

NOTE for 4.x users upgrading to 5.x or newer: No matter how you upgrade (HPM, bundle, or entirely manual), you must open the CoCoHue app and hit Done after upgrading (if you are using the V2 Hue API, though doing it regardless is a good idea). Additionally, if you are using version 3.x or newer, you must upgrade to 4.x or newer before upgrading to 5.x, as direct upgrades are not possible. Finally, if you are an existing 1.x user upgrading to 4.x (or older), pay special attention to the notes in the readme. The parent app is deprecated, but existing users can continue using this parent/child setup with minor changes. (New users will have only one app.)

I've tried to make this integration as Hubitat-like as possible, working nearly identically to the native integration except when extra features are used and using standard capabilities whenever possible for new features. This is part of the reason I started over with writing an integration from scratch instead of modifying an existing integration like Hue B Smart or porting a different app/driver like Hue Advanced. To my knowledge, this integration currently implements everything Hubitat does, plus these often-requested features:

  1. Scene support! (Creates button/switch device for any scene you add)
  2. Access to Hue bulb "effects" (color loop, select/alert, etc.)
  3. Improved group support ("Change Level" capability-- startLevelChange and stopLevelChange commands implemented; rate is adjustable)
  4. Implementation of Hubitat's new "LevelPreset" capability (presetLevel() command)
  5. It's open source! Customize the code to suit your requirements if you so desire.

More documentation can be found in the Readme on Github. My plan is to keep stable releases in the Hubitat Community repo at GitHub - HubitatCommunity/CoCoHue: Open-source community-created Hue Bridge integration for Hubitat (most people should use this version) and keep more experimental code in my own, GitHub - RMoRobert/CoCoHue: CoCoHue: Open-source Hue Bridge Integration for Hubitat (this version not recommended for most people).

Feel free to post any feedback here!

Here are a couple screenshots from a Hue group device in CoCoHue in case you're curious about commands and preferences:

Screenshot: CoCoHue RGBW Group device commands
Screenshot: CoCoHue RGBW Group device commands2218×1412 210 KB

Screenshot: CoCoHue RGBW Group device preferences
Screenshot: CoCoHue RGBW Group device preferences1870×900 94.7 KB

Changelog

Version 5.1

  • Removed "Switch" capability from scene devices. To activate a scene, do a "Push" on button 1, or a push(1) command. The "On" and "Off" commands and "switch" status (attribute/event) are no longer available. See this post for more details.
  • See below for all 5.0 changes as well if you have not yet upgraded! Remember to back up your hub before upgrading.
  • Version 5.1.1: Fix for motion sensor ID migration for new upgrades (existing users with problems, see this post)

Version 5.0

  • Increased use of V2 API for compatible Hue Bridges
    • Most device DNIs on Hubitat will change as a result if the V2 Hue API is enabled, preventing downgrading to 4.x without restoring a corresponding hub backup (or manually editing all DNIs back to previous values...)
    • Will allow easier transition to 100% V2 API use in future (V1 API is still used for commands and polling by default, V2 for instant status updates)
  • Addition of RGB-only driver (supports devices like original Hue Lightstrip)
  • Removal of deprecated features, including prestaging preferences and commands and Hue Labs activators (these will no longer work in 5.x)
  • Motion sensors are now only supported on V2 API (they were supported in polling-only configuration on V1 in 4.x), as are button devices (always available only on V2)
  • NOTE: Version 4.2 is still available (for manual or bundle install) and should continue to meet your needs if you do not want to upgrade. Suggested installation method is the CoCoHue 4.2 Bundle (CoCoHue-Bundle-Latest.zip) in the cocohue-4.2 branch of the CoCoHue repo. Version 4.x has been around for over 2.5 years at this point and should be considered a stable choice for existing setups if it is already working well for you, while new enhancements will be added to 5.0 and later only.
  • Version 5.0.1: Fix for missing or delayed Hue V1 device ID data on lights, groups, and scenes when using V2 API (NullPointerException errors in Logs for getHueDeviceIdV1())
  • Version 5.0.2: Add additional data for V2 API scenes (existing users: run "Fetch Scene Data" command on each scene if already upgraded from 5.x; will not cause problems until V2 API used for activation, but this will avoid problems in future)
  • Version 5.03: Use V2 for scene activation if possible; automatically migrate 4.x device and app logging settings to 5.x (existing users can use Preference Manager if want to bulk re-enable any; all disabled by default after upgrade unless "Save Device" used)

Version 4.2

  • Adds support for on/off events from scenes
  • Tweaks to the setLevel() command to work better with the current/new Hubitat mobile app
  • Minor changes and preparation for additional v2 API use in the future.
  • If you want to upgrade to v5.x in the future and are currently using version 3.x or older, you will need to upgrade to version 4.x in between. (I am making some changes in 5.x that will not be compatible with direct upgrades from 3.x and older versions. Version 4.x has been out for quite some time, and I suspect this is unlikely to affect many users at this point.)

Older Versions

  • See posts later in this topic for specific releases
32 Likes
2

Excellent, I was really missing this on the stock Hubitat integration! Helps speed up dimming with picos

2 Likes
3

Greetings, all. I've released CoCoHue 1.5 with updates to all drivers plus a new driver for scenes and introduced (surprise) scene support! Scenes are named as "Room Name - Scene Name" (works well for Bridge scenes that are created per room/zone and otherwise have the same name) and are exposed as both Pushable Button and Switch devices, so either a push(1) (or really any push() command--the button number is ignored) or an on() command will activate the scene. An off() command does nothing since Hue doesn't support turning off scenes (closest I could do is turn off a group for a GroupScene if anyone would find that useful).

Let me know if you run into any problems! I've switched all my Hue bulb/group integrations over to this and added several scenes, and it's working well for me.

EDIT: Minor update v1.5b for group, RGBW bulb, and scene drivers with minor fixes (one of which is that the scene driver had the wrong importUrl, so please copy that one from Github again or grab the correct raw URL before you try that one).

EDIT 2: Another minor update to v1.5 for some drivers to fix duplicate colorName events from RGBW bulbs and group devices from getting logged (logs only; no new events were actually generated from this artifact of parsing bridge info).

EDIT 3: I've updated the scene driver again because I still had importUrl wrong. Updating manually from GitHub or the raw URL will work (I had the wrong capitalization, so the "Import" button won't do anything at all here, so you'll notice if you try to do it that way--but this should work going forward).

1 Like
4

Can I use ur integration for some bulbs and the native one for others?

5

You can do anything you want. :slight_smile: But I'm not sure why you'd want to unless you gradually plan to transition everything to one or the other (I did when I was testing this)--two apps polling your Hue Bridge isn't bad, but one is better.

6

Yea. Just asking for the transition. Don't have time to do it all.

So does this work for groups as well as zones? Zones is a so called beta feature in hue app but I use it alot. Thx

7

Yes, zones should show up as groups (which I'm pretty sure they also should for Hubitat's native integration, but I never tested that). They're pretty much identical to groups in the Hue API.

8

@bertabcd1234

Just started playing with this integration. I was previously using the Hue-B-Smart port. Besides specific drivers for CT bulbs and White Bulbs which I understand your working on, I was wondering if you could implement a "flash" command with the ability to adjust the duration/number of flashes? It's one feature that I like in Hue-B-Smart since it allows a compromise between a single flash and the full length sequence. In Hue-B-Smart this was called "flash-Notify".

Edit: I do realize that I can achieve something similar by executing multiple "flashOnce" commands with short delays in between, but the method Hue-B-Smart used is more user friendly and bit more consistent.

9

@bertabcd1234, I ended up putting my Hue bulbs back on the Hue bridge (the functionality on HE is not great) and I’m using your integration. I love it so far and the group dimming is awesome, but I’m having trouble getting scenes to activate with RM and ML. I use per mode settings and created HE scenes to turn on the scene device and also to push the scene button, but it still doesn’t activate the scene. Any idea how I can get this working?

10

The Hue Bridge provides only two options ("alerts") via the API: the "select" command that flashes once, and the "lselect" command that does 15 flashes. I looked at the Hue B Smart bulb code, and it appears their "flash notify" command just starts the "lselect" and then sends a command to stop it after a certain number of seconds. Their default is 5, but what it doesn't look like it tells you is that it will stop after 15 regardless of what you choose.

EDIT: As of v1.8, I have added a flashOff() command to manually send an "alert: none" to Hue, the use of which would basically be to cancel an in-progress flash(). Other ways to stop this include sending a flashOnce() (which will do one more then stop) or sending an off() (if that is your desired end state, of course) which on the Hue side appears to also stop the alert on any bulb I tried.

And I do indeed plan to provide dedicated drivers for bulbs with fewer capabilities than the RGBW ones. Just wanted to see how these work for people first so I don't have to change code in multiple places if things like the above are something people want (or there are any big problems). :slight_smile:

11

I hear you: I tried a Hubitat hub dedicated to Hue bulbs, but eventually gave up and went back to the Bridge. No more worries about addressing too many bulbs at once or with bulbs missing color or level commands after an on()...

Anyway, for the scene device, I'm certainly interested in fixing this problem. Do I understand correctly that you created a Hubitat scene that simply activates the CoCoHue scene device? If so, I'd first try eliminating Hubitat Groups and Scenes from the picture first. Does the CoCoHue scene device itself work if you activate it directly? (As you know, either an on() or a push(1)--or really, any push command since I just make it ignore the number--should work.) If not, there's a CoCoHue problem I can look into (I can tell you what logs would be helpful for me to track that down).

If the problem only exists via Groups and Scenes, I'm less sure but can say on/off optimization would probably need to be turned off if that's an option anywhere (Hue scenes can't be turned off, though you can turn off the CoCoHue scene device itself with no effect; what I'm getting at is that the scene will respond to repeated on() commands, but it's possible Hubitat won't send that the scene device, a Switch-capability device, reports as already being on). I can't see why a push would have this problem.

12

Thanks! Sending the "flashOnce" command after a delay did the trick. Sending an ON/OFF wouldn't be desirable as it would override the current state of the light.

So far the RGBW driver seems to be working well with all of my bulbs, including the CT and White Only, but having a less "featured" driver will likely make things a little less confusing when setting up rules.

Thanks again!

1 Like
13

Yes

Yes

Me neither. I tried the switch on and then added the push as well. I’ll see if I can figure out something else later today.

14

Interesting. I'll try setting up a Hubitat scene myself when I'm at home to see if I can replicate the problem. Turning on logging for the scene device may help you figure out whether the on or push commands actually get called. You won't see anything for push() (so I'll probably add a debug log there when I test); an on should log "Turning on scene...".

15

I figured it out. I had set up the scenes, but not captured them. I didn’t realize the mistake until I looked at it again today. Sooo, never mind. Everything works great!

1 Like
16

@bertabcd1234 I was going to test this in a rather limited way so as not cause issues with WAF. However it appears to be working so well I went ahead and converted all of my rules and have removed the stock integration completely.

All I can say is "WOW" performance seems to be as good or better than the stock integration and the addition of the scenes and flash commands are a hugely welcome addition that I've been waiting for since I got my C-4 last year.

Congrats on your hard work, it sure seems to have paid off!

2 Likes
17

Thanks for the kind words! My whole house (and my first lucky victim's) has been running on this for a while now, too, without problem. I wish I could take credit for introducing scenes or flash, but Hue B Smart got there first. I just decided to write one from the ground-up specifically for Hubitat instead due to some un-Hubitat-like behavior I found (like no Change Level capability on the bulbs--a step back from Hubitat's own integration--and odd behavior like setLevel(0) turning on the bulb), and it was easier to write something on my own that I fully understood than to try to modify or port something else. :slight_smile:

18

I was a long time user of hue-b-smart and the work that @xap did on the port to HE is excellent, yet for whatever reason I was finding it's performance inconsistent on HE. Your code seems to be very HE friendly as I haven't seen anything to complain about yet.

Looking forward to further development!

19

This is awesome. Works great, Really great.

Now I just wish I could get my inovelli dimmer LED bars to sync to this and it would be perfect.

Thanks so much for this

20

Does this work for white hue ambience bulbs?