NOTE for 1.x users upgrading to 2.x or newer: If you are an existing 1.x user upgrading to 2.x or newer, 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.) Also, if you are upgrading to v4.x for the first time from 3.x or earlier, open the parent app and press "Done" once.
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:
Scene support! (Creates button/switch device for any scene you add)
Access to Hue bulb "effects" (color loop, select/alert, etc.)
Improved group support ("Change Level" capability-- startLevelChange and stopLevelChange commands implemented; rate is adjustable)
Implementation of Hubitat's new "LevelPreset" capability (presetLevel() command)
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 https://github.com/HubitatCommunity/CoCoHue (most people should use this version) and keep more experimental code in my own, https://github.com/RMoRobert/CoCoHue (this version not recommended for most people). Feel free to use whichever you like, but if you have any problems or questions, let me know which one you're using.
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:
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).
You can do anything you want. 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.
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.
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.
@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?
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).
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.
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.
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...".
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!
@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!
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.
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.
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.
