After reading this thread, did the newest HE firmware release accomplish the original purpose of this app?
No, that's completely unrelated. That appears to be related to whether the group device in Hubitat shows as on or off based on states of individual group members. This is an app meant to facilitate the use of button devices to control lights, individually or, to some extent, as party of groups or scenes--basically an easier way than using Rule Machine or Button Controller where you have to keep specifying the devices for each button when you want it the same for all of them.
1 Like
I've released a small update, v1.9, to the child app as well as an optional (cosmetic-only) update to the parent app. The most notable change in the child app is that I've now added the ability to activate Hue Bridge scenes if you're using my CoCoHue app as a Hue Bridge integration. This is as an alternative to manually specifying bulb/group settings or using Hubitat scenes, both of which are already (and still remain) options in the app. I find activating Hue scenes via the Bridge is much faster than specifying settings through this app (or Hubitat scenes) for each bulb/group.
You can just use CoCoHue for scenes if you want (there's no requirement to integrate bulbs or groups if you don't want to, and you could leave CoCoHue polling disabled in that case). However, there are other benefits to using this, like being able to use a Hue Bridge group in Dimmer Button Controller and having startLevelChange and stopLevelChange available to you, which Hubitat's integration implements only for Bridge bulbs. This makes the "dim/brighten while held" options work for Hue groups, so you can leave individual bulbs out of the equation entirely here with Hue scenes and Hue groups.
Fair warning, I will probably re-write the app sometime soon, and I'm not sure existing instances will be able to be upgraded (I won't break this app, but it might be like Rule Machine where you can see and modify old rules but not create new ones under old versions, and if you're obsessive about having everything the same version, this may bother you). I might implement Hue scenes directly into the app without the need to create a Hubitat device for them (open to suggestions if anyone would find that useful). My main goal would be to revamp the UI or at least the (messy) code that currently creates it. No timeline, just a heads-up. I'm going to re-create as much as I can on this version though, now that I've got all my Hue lights, groups, and (some) scenes set up via CoCoHue. 
Noob here with a quick question........
I have a pico and am setting it up to control a set of Hue lights.
On/Off/Scenes (buttons 1,3,5) work when I create a rule for the GROUP of lights
dimming does not (and startlevelchange isn't supported by a GROUP name)
Alternatively, I changed the rule to control the 4 individual bulbs rather than the group name
This works relatively well, but a couple of things I haven't worked out
-
Lights on turns them on individually with a slight delay in between each light.
I think I can probably address this by setting up two rules under Dimmer Button Controller and having buttons 1/3/5 operate against the GROUP in one rule and remove 1/3/5 from the existing rule that works against the 4 BULBS instead of a group name.
(Update: this worked, if there's a more elegant way to solve it LMK please) -
dimmer is a) SLOOOOOOWWWW and b) doesn't work when lights are off. Ie you cant turn off lights then dim up slightly, you have to turn them on full blast, then dim them down. Haven't figured out how to solve this.
(Update: just tested brighten while off with a Hue controller and what I'm trying to do doesn't work with that either, so I can live with it as)
I guess that leaves my only question, is there a way to speed up dim/brighten?
Thanks for putting this together, before I found this I was tediously working through rule machine.
Also fyi everything seems to work fine but I get an error in the debug log when I turn off the lights
app:592019-12-31 07:38:02.900 pm warnError when running turn-off action: java.lang.NullPointerException: Cannot invoke method off() on null object
dev:412019-12-31 07:38:02.885 pm infoExtended color light 3 switch is off
dev:422019-12-31 07:38:02.843 pm infoExtended color light 4 switch is off
dev:432019-12-31 07:38:02.802 pm infoExtended color light 5 switch is off
dev:442019-12-31 07:38:02.708 pm infoExtended color light 6 switch is off
dev:452019-12-31 07:38:02.614 pm inforyan switch is off
dev:382019-12-31 07:38:02.379 pm infoRyan Pico button 5 was pushed
Honestly, my incredibly biased recommendation would be to use my custom Hue Bridge integration, which supports startLevelChange and stopLevelChange on groups:
Then you wouldn't need to use individual bulbs at all (and you'd get the ability to cycle through real Hue scenes like the Hue Dimmer can without emulating this in Hubitat). But I used this app for a long time as you are now before that, using inidividual bulbs with Hubitat's stock integration. The delay between bulbs is inevitable--Hubitat has to send them one by one, then the Hue Bridge likely does the same. I noticed a small "popcorn effect" as you do but nothing too severe.
Hue bulbs do not respond to startLevelChange(up) (to dim up) when off. As it looks like you've figured out, they have to be on for any of the "level change" commands to work. (A setLevel would turn it on, but you can't do that in one fell swoop with my app; you'd need a separate action for that.) I'm not sure about the other half your point 2, the slowness. With four bulbs, you may again notice a "popcorn effect" with all bulbs needing to get the start and then stop commands individually, but beyond that, it should be the same that you see by manually initiating the same commands (startLevelChange with up/down and stopLevelChange) on the device page. The only other thing I can think of is that if your hub is slowed down for any other reason (e.g., runaway custom app or driver or general sluggishness for any reason), this problem would be exacerbated.
But again, I think using a group in CoCoHue would solve most of this. 
For the error: I need to add a check in the off actions for that, but the error is harmless (just means you haven't selected additional "off-only" bulbs, just the regular ones).
1 Like
I am using CoCoHue, in fact it's required for Dimmer Button Controller (i think, at least the docs says so). The nice part about Dimmer Button Controller is it's all set up to easily handle Picos. I deleted the stock Hubitat Hue integration and replaced it with yours. If it's designed to handle startLevelChange up/down on a group, not sure why it doesn't work when selecting a CoCoHue exposed group with Dimmer Button Controller.
CoCoHue isn't required for Dimmer Button Controller (I wrote both apps) unless you want to use it to activate CoCoHue scenes, but I think it works better with it regardless.
Dimmer Button Controller should work with startLevelChange on CoCoHue groups. It will not work with Hubitat groups (nothing will because they don't implement these commands since they could contain a variety of devices that wouldn't all consistently respond). This is true even if that Hubitat group contains CoCoHue bulbs. Can you verify that you're using a CoCoHue Group (created through the CoCoHue app)?
If not, that's the problem; if so, feel free to turn on debug logging or and send me a screenshot of your logs, or at least see if there are any errors. Sorry for the troubles--I'm definitely interested in finding the source of this problem. I have several automations like this set up that work for me.
I will double check later today, I may have inadvertently used the Hue group instead of CoCoHue group as they create the same group names for obvious reasons. I've since deleted the Hue app and the duplicate names are gone so that mistake can't be made in the future.
I am also using Dimmer button controller for my lifx bulbs due to how simple it is to get my picos working. I have this turn off error like @robr as well. Anything easy I can do since I have many instances for dimmer button controller and hope to see no error in my log?
Again, it's not really a problem, just trying to send off() to nothing, but I understand the concern. I think you could fix it by modifying this snippet:
def turnOff(devices) {
logDebug "Running turnOff for $devices..."
devices.off()
}
to this:
def turnOff(devices) {
logDebug "Running turnOff for $devices..."
devices?.off()
}
I'll actually test this and release a small fix at some point.
You are awesome. Thank you!
I'd LOVE to use this app, but a huge need I have is to allow buttons to do more then just turn on lights on/off. In particular to set "modes" as I have modes (home, sleep, away, vacation) dictate a lot of actions and scenes as many scenes overlapp for my modes.
I could imagine controlling HSM (disarming alerts for example) could also be super useful!
Thanks for the consideration.
You can have more than one automation associated with a device or even the same event on the same device. Why not consider using this app for lights and HSM, RM/Button Controller, or (third-party but great) Advanced Button Controller for other things? You could also do everything in one of those, but I mostly wrote this because I was tired of selecting the exact same lights for every button on a single device.
1 Like
Got it, thank you for the tips, that makes sense.
I have updated the child app to v1.9a, which has a small fix for this issue.
FWIW, it is a warning, not an error. (Or really it's an error that is handled by my app, not the platform throwing its own from an unhandled exception, which are the kind I'd be concerned about...just defending myself a little here. Haha.)
@bertabcd1234, have some consistently odd behavior going on with DBC and Pico remotes with hue lights. On and off is rock solid but the brighten and dim do not work consistently. I enabled debug logging and found that after I press on all Brighten or Dim are ignored until I see a basic get request for all the hue bulbs. I assume this is coming from CoCo Hue. After that request both dimmers are rock solid.
I haven't seen that before, but if you provide the logs (here or PM if you want), I might be able to figure something out. Thanks!
Will do. Heading out but will do later today. Is there a preferred method of providing logs?
Screenshot or text fine with me, as long as the text is cleaned up if you go that way.
