Happy to help! So, first, my recommendation would be that if you don't need the Hue Dimmer paired to Hubitat, I'd keep it paired to Hue. You can easily configure it to do most of what you want in the Hue app, and the bulb states will (eventually) get back to Hubitat if you leave polling enabled. Reasons you might need it in Hubitat include needing bulb states immediately (e.g., to trigger other apps/rules if needed in real time) or to do things Hue can't do (which your example of "first press sets scene per mode" would probably be).
So: to do what you want with the Dimmer (or really any similar device) on Hubitat, you'll have to use an app on Hubitat, and there are a few options. Natively, Rule Machine with a "Button Device" trigger would be the best choice. This will split out all the button numbers and events (1 pushed, 2 held, etc.) into separate sets of actions you can perform for each. A logical choice would be turning on a light or activating a scene for 1 pushed, stepping the lights up by something like 10-20% for 2 pushed, doing a "Start raising dimmer level" on 2 held, a "Stop raising/lowering level" on 2 released, etc. would be logical choices. When the Button Controller app comes back in hub firmware 2.2.0 (or if you already have it installed), it could also do this. However, do cycle through scenes with multiple pushes of button 1, you'd need to track it somehow, e.g., with a numeric local variable. (There are a couple examples of this elsewhere on the forum.)
A popular third-party app is Advanced Button Controller. It can cycle through Hubitat scenes but, last time I tried, wouldn't be able to do what you want with CoCoHue scenes (or button devices or switch devices in general). I wrote Dimmer Button Controller to do exactly what you're describing in general, and it's a bit less clicking than general "button" apps because you only have to specify the lights you have to control once (not once for each button number and event), then assign actions to each button. However, I'm still not sure of a good way to do "per mode" actions here without a bit of work--you can restrict the app to only run in certain modes, so you could create multiple child apps for different modes.
1 Like
Thanks @bertabcd1234. I think the tip on the dimming up and down will come in particularly useful. I've just started looking at this again now, so can play with your suggestions and see how I go.
I think I will still try to move my dimmers onto HE. I would prefer to have my lighting rules all in one spot, either HE or the hue bridge. It sounds like there is a way, I just need to try a few things out from what you have suggested. In the end your CoCoHue app gives me the best of both worlds, allowing me to define scenes, rooms and zones on Hue, whilst having those mirrored in HE for my rules, obviously the addition of scenes being the main advance.
Simon
One quick question, is it just me or does the hue dimmer driver not support detection of the off button (button 4) being held, or even released for that matter?
Not just you--you're correct. The Hue Dimmer supports pushed events on all buttons, but held and released on buttons 2 and 3 only.
1 Like
Hmmm, annoying. Thankyou for confirming.
@bertabcd1234 - I was having problems with loading some of my lights, and after looking in the logs I just noticed the Readme.MD in Git doesn't include a link to the recent CT driver. Found it in the drivers folder in the Git repo, so no issue, just thought I'd let you know.
Oops, pushed that change to my dev repo but not the production one. Fixed. Thanks for catching that! (And nicely done on figuring out the cause of your problem!)
No worries, not sure if it would be possible to include anything in the app code to prompt the user that it could not find the driver, but was easy enough to work out once I looked in the logs.
One request / question...
I love the fact you went to the trouble to do the bulb / group state change detection. From what I can see, if I activate a room/zone based scene, the group state does not change until the periodic polling, e.g. the 1 minute polling interval in my case. Given you flag the scenes as type of "GroupScene", would you / have you considered refreshing the group state when the scene is activated? Which could in turn refresh the bulb states for that group (room / zone).
Thanks,
Simon
Hmm, I'd never thought about "pseudo-polling" where activating a GroupScene causes the group to get refreshed (and whatever else you have configured to happen along with that), but that does sound like a decent compromise for people who don't want to wait for the next "full" poll (and I'd only recommend it if you really need instant status changes for some reason). The only alternative I've considered is that the /scenes API can return the configured light states and the Hubitat device could remember those and update the devices accordingly without needing HTTP for that particular task, but then those states would also have to get periodically polled from the Bridge (no guarantee the scene can't be changed).
Either way also still leaves the limitation that there's no way to tell when a different scene was activated (from Hubitat or Hue--and of course the same would apply to any change made outside Hubitat), so there's no guarantee to tell that all lights are at the correct state even after that. It will make the rest a little faster to get, though, I guess.
Also, I'm not aware of any easy way for an app to tell whether a specific driver is installed--if there was, I'd love to show something in the UI beforehand. (I haven't see any apps do this.) The note in the logs is the best way I can think of at the moment. There's another dev out there piloting a "package manager"-type app for Hubitat, which if successful is one way I plan to suggest CoCoHue installations in the future (which would eliminate this as a possible problem since it would do everything for you beforehand). Otherwise, hopefully fixing the docs helps at the moment.
Thanks for the ideas!
1 Like
Thanks @bertabcd1234. I can understand your point around the potential for changes outside of HE. That was one of the reasons I have hung on so long keeping my accessories and rules inside the hue bridge, I didn't want to tie myself to only using HE. I think now, along with your app, I am in a position to make the move. But you are right, in order to keep the status' maintained, I would need to limit changes from outside HE.
One reason I want the status to be as up to date as possible is that I intend to adopt similar logic to my hue rules that rely on state, e.g.:
- If any of the lights in a group are on, then I won't want to trump this with a motion activated rule adjusting the lighting. Similar to hue's do not disturb my scene option.
- Overriding of timers to turn lights off after being motion activated, e.g. by hitting the On button on a dimmer lights will stay on until they are turned off maually.
I think one quick way I could implement what I suggested would be to use RM to refresh a group based on a scene switch being activated. There doesn't appear to be a refresh command for the hue group devices, would the "Configure" command achieve the same outcome?
Bulbs and groups both either don't have the refresh() command implemented or (and this is how I have it implemented in the version I'm currently working on) sort of do but log a warning that you need to refresh the Bridge device instead. Right now, that's all you could do: refresh the Bridge device, which will do the same thing that polling does and update all the bulbs and groups accordingly. I've considered implementing this for individual devices too, but if you're refreshing more than a couple bulbs or groups at a time, it's probably better to just refresh the Bridge. I haven't profiled anything here (not that we have good tools to do this anyway), but my guess is that the bulk of the work comes from the HTTP calls and callbacks themselves, and the JSON processing (that happens inside the callback) for the entire Bridge would probably be less work for everything than doing all of this multiple times for individual devices...but mostly speculating at this point. 
1 Like
That make's sense. I might trial a few ideas and see how they go.
Hi @bertabcd1234,
I was trying to initiate a refresh of the bridge in an RM rule and it doesn't appear to have a capability available when running a custom command, it only has refresh. Do you have any ideas on how best to initiate a refresh in a rule?
Thanks,
Simon
"Refresh" is a standard command and one that Rule Machine should let you run without resorting to custom:
That being said, I don't see any capabilities that the Bridge implements that RM allows you to choose from if you did want to use "Custom Action" for some reason, so I'll add the "Actuator" capability (a sort of catchall capability you can use on devices that take commands) to a future version.
1 Like
Hi @bertabcd1234
I use CoCoHue rater successfully. There is just one problem. I can't integrate CT-Bulb-Groups with Google Home.
Is this a known problem with CoCoHue or is there a problem on my side I should investigate (maybe you have encountered this problem from other users)?
thanks
I'm not sure where to say the problem lies, but I'll probably add something to CoCoHue in the future to work around this issue. The problem (as other people discovered above--I can't take credit for that) is that the Google Home integration rejects bulb-type devices that don't have all attributes set, or at least specific ones that aren't getting set here because the group device implements RGB+CT capabilities, but a group of CT (or less) bulbs is never going to report some of these values. (FWIW, I checked Hubitat's native integration, and it looks to also leave these empty, so I think it would have the same problem.)
The solution: set the group to an arbitrary color value using the "Set Color" command on the device page, just to get these values set to something, before adding them to the GH integration. (A different solution would be to have separate "CT group" or "dimmable-only group" drivers, but I don't see an good way to get that information from the Hue API without iterating over every individual bulb, and then the user would also have the manually change drivers if the group device members' capabilities change on the Hue side.)
1 Like
All,
I've released CoCoHue 2.0 Preview 1. This is a substantial re-work of version 1.x behind the scenes with a few new features you'll notice on the front:
- Bridge discovery! While I'd still recommend using manual configuration and a static IP, this option achieves parity with the Hubitat integration and Hue's recommendations for such integrations. Some simplification (fewer pages to navigate through) has also been done for the process of either automatic or manual Bridge addition.
- 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 now updates with "Online" or "Offline" if CoCoHue fails to (or succeeds in) communicating with the Bridge; this is an easy attribute to monitor for possible problems
- Bulb/plug drivers now do not report attribute/state changes (i.e., no events) initiated from the Hubitat device until the driver hears back from the Bridge. In my experience, the attributes still update almost as fast, but in all cases, it should be a more reliable indicator of actual device state and has no effect on how long the lights themselves actually take to change
- HTTP errors and Bridge errors should now be more clearly logged (in "Logs"); CoCoHue may have "swallowed" many of these before (may help with troubleshooting problems; in my testing, I was only able to get these if I did something intentionally wrong, like unplug my Bridge or delete a Hue device and try to control it from Hubitat)
- Added ability to install via Hubitat Package Manager instead of manually if preferred
- Deprecated "parent" app (new users have only one app to install; 1.x users upgrading should see README on GitHub, the first post, or the note below for upgrade instructions)
NOTE FOR 1.x USERS: As noted above, the parent/child app structure is deprecated. New users will install only one app, more or less what the "old" child app was. Existing users can upgrade without problem if they follow the instructions in the readme on GitHub. This is fairly simple--just update the parent app (now in the /deprecated folder), install the "new" app code over the "old" child app, and uncomment the parent: line in the app as directed. This will be necessary every time you upgrade the app. (In my testing, it was actually still fine if you didn't do this unless you tried to add another child app instance. I'd recommend doing it anyway. You could also uninstall, remove all CoCoHue devices, and reinstall using the "new" structure, keeping in mind the obvious inconveniences you may run into with that approach.)
Let me know if you upgrade and notice any problems! I plan to work on a few more features (and possibly another preview or two) before releasing 2.0 "final," but thought I'd get this out there ASAP after some testing (I swear I tested this and had someone else do so, too ) so that new users would be able to start without the 1.x parent/child structure and so that I could get this same app and structure into Hubitat Package Manager to make installation/upgrading easy for those who choose to use it--and release some features (many behind the scenes) I've been working on the last few months.
2 Likes
