In the Hue app, I've noticed lately that changing things in the RGB color wheel puts the lights into colormode: xy. It may have used hs in the past; I can't remember. Modifying it in the color temperature wheel puts it in colormode: ct (yay!), but when I save that as a scene and recall it later, it's xy (noooo!). In general, however, my interpretation of the Hue API docs--so probably what diyHue woud want to do--is this:
when you send a hue and/or sat value to the Bridge, the light will update those values and go into colormode: hs (so: what will happen if you send a color, hue, or saturation value from Hubitat)
when you send a ct value to the Bridge, the light will update that value and go into colormode: ct (so: what will happen if you send a color temperature from Hubitat)
when you send a xy value to the Bridge (not sure many humans really do this and Hubitat definitely won't but the Hue app seems to use this behind the scenes of the RGB wheel), the light will update that value and go into colormode: xy
if you send more than one at the same time (no idea why you would), all values will be updated (but I assume not all may be accurate unless you know what you know exactly what you're doing), and Hue will update colormode with xy > hs > ct priority
one ore more of hue, sat, xy, or ct may be returned from the Bridge, but colormode determines which is guaranteed to accurately represent the current state (I have noticed that at least genuine Hue bulbs on the Hue Bridge are good about updating the value of ct even if in xy mode if the light is really in a color temperature space, as might happen if you recall a formerly-CT scene like Concentrate or Read; I assume this behavior varies between bulbs, and gain there are some like Ikea that implement only xy).
But DIY hue is doing all of this today. It's when changes are made on the BRIDGE that there's a problem.
If that's what the Genuine Hue Bridge is doing, why should DIYHue not do it? If they are trying to emulate the Bridge itself? That's the part I'm not understanding.
I see a lot of examples of how to convert from XY to HS online. They solved this problem on HA. And even if it's not 100% accurate, close is better than totally wrong.
It can do it this. However, since color can be represented in either hs or xy, I don't see a reason to prefer one mode versus the other. Either should work (though Hubitat plays a lot better with hs color--and it's a lot easier to visualize--so I prefer that space myself whenever possible). The most important thing is that colormode gets reported so other integrations know how to interpret the rest of the data that are reported.
Right; when a change is set to the Bridge (I assume that's what's happening--something, either the Hue app or another, sending the commands to the diyHue Bridge?), the Bridge should report back a colormode (assuming the bulb is of type Color or Extended Color--and maybe Color Temperature if any of those, for who knows what reason, happen to use xy instead of ct).
If you can summarize the algorithm they used, I would totally do the same as them. Otherwise, I've tried this and similar formulae I can find elsewhere (apparently used to be part of Hue's docs somewhere) with little success. I'll try to come back to this on my own someday, but it's not a big priority for me right now. I'm definitely open to providing options to interpret xy data differently in the meantime.
Oh, me either. The only groups I'm using presently are for CT lights or to shut off a bunch of color lights (so even the level doesn't matter). The only reason I noticed is I brought in a whole bunch of lights to try out something and brought in their group too to reset them for testing. Otherwise I wouldn't have even noticed. So, need to work on it on my account. Just seemed odd to me so I thought I'd run it past you.
Basically, the DIYHue setup also has software for DIY addressable light strips run off a microcontroller. With one board you can break up a length of LEDs into individual Hue Lights so you can control them individually for color and brightness. I was trying to work out an animation for something I'm thinking of doing for my stairs, where it fades up lights in sequence on a delay. Great part...it worked the first time!!! But that also meant that what I was hoping would fill my whole Saturday and Sunday was done in about an hour. I needed to fill all that time somehow, so I started trying to figure out why this wouldn't work.
I've been meaning to try this app / drivers for some time because of the scene support and more advanced status updates for bulbs / groups. I decided earlier today to finallly start to move my accessories off my hue bridge and onto my HE, and I quickly realised cocohue was the way to achieve that.
I just have a few questions, some of which may have already been covered:
I started by movig a dimmer switch. Can you please advise on the best way to configure this along the same lines as the hue bridge? Is it to setup a single rule with a button device trigger and variable to allow for the cycles of scenes using the On button, button 1? Described in an earlier post on this topic. This also leads onto my next question...
When I press the On button I would like to trigger a different scene per mode, at least for the first press, the rest can be a set order of scenes. Is that possible? Or at least just triggering a different scene per mode in general. I will want to do a similar thing when I move over my motion sensors. I achieved this on the hue bridge by overriding (re-capturing) a "Current Scene" each time I went between Day and Night modes, then the Current Scene was what I activated on motion in the bridge rules. I was hoping to remove the need for the Current Scene if possible.
Thanks again for your efforts, both in developing the code and the time taken to help people on this thread.
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.
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.
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?
@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.
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).
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 @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.
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?
"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.
Otherwise, I've tried 
