Hue Dimmer Integration


#1

This is a port from ST:


Compatible Devices Wiki
Delayed boolean change based on Hue bulb status
#2

Thanks for this! Any idea how they actually work on Hubitat? I was never really sure how they worked on ST either; I have the Hue Bridge and keep mine paired to that since I’m currently using them all with Hue lights anyway, and the Hue app/bridge work great for that. If they stay connected reliably to Hubitat and have response time as good as any other button, I’d certainly considering moving one or so over to control other devices as well.


#3

You’ll need to install the button controller app, ABC app, webCore, or use Rule Machine to specify what you want each button to do.

I don’t know how reliable they are just yet as I just got this working today. So far they’ve been connected for a few hours.

One thing I haven’t figured out yet is how to get them to change color using the Botton controller app or ABC app. It may be that I am just not familiar with those apps yet.

I also have to look at how WebCoRE calls these devices because once I updated them to the hubitat standard, webCoRE lost the ability to control them. It’s probably a minor change, but I haven’t had time to look into it.


#4

My ABC app cannot change bulb colors directly. You would have to set up a virtual switch or something similar to accomplish this. I don’t believe you can do this with the native Button Controller app.

I have a leak detection routine that turns my Lifx bulb blue and flash, then breathe. I use Rule machine and Custom Commands for this. You probably will need to go this route or find a smartApp that can do it for you.


#5

I added the option to change color and color temp to the ABC app. It appears that the built in hue drivers accept color commands differently than ST. I ended up changing my Lifx driver port to be consistent with what the hue bulbs needed to process color commands. I’m not sure if you would need to do the same with your driver.

@bravenel @mike.maxwell even the built in Button Controller app did not send color commands in a way that the hue driver could process so I guess it would also need to be updated as well. Any way for us to get the standards of how we should be coding color commands for ST? I had never tried to code for color and ended up throwing everything at the wall till my existing code worked.

EDIT: I just opened your Hue Dimmer and realized it wasn’t a driver for the bulb but an actual Dimmer button. Mea Culpa.


#6

OK, so are we good here?
The only issue I’m aware of currently is that setColor cannot be invoked from the driver details page in 1.0.4.706 and lesser…
This has been resolved and will be out in the next build.


Lifx Group of Groups Driver (ST port)
#7

Forgive my lack of knowledge @mike.maxwell about how color updates should be done as this was my first attempt and I had a few requests to add tghis to my BC app. I’ve read through the ST documentation and a few posts that you replied to regarding how setColor() setHue() etc should work. All had conflicting information so I just brute forced and tried everything I could think of. This post might be meandering because everything I did was a shot in the dark but I want to give a good picture of what I tried.

I could not get anything to work with my Lifx, so I tried to get it to work with Hue since I figured, these lights were officially supported and if I got them to work I could transpose those settings to my Lifx ported driver.

  • I could not get setColor to work no matter what I tried , hex, HSL, but I don’t have any documentation to follow so I don’t know if I’m doing it wrong or if it’s just not supported)
  • I looked to the button controller app for guidance and realized that it did NOT work with Hue either but it set color by taking hue and saturation values rather than hex, etc)
  • I configured the my ABC app to set color by allowing those inputs as well, one for hue and one for saturation and applied those to the bulb sequentially. It only worked by using a 0-100 range for both. My Lifx bulbs only accepted Hue:0-360 and Sat 0 to 1 (decimal). I ended up changing the Lifx to accept these values instead and now I can control both Hue and Lifx using the same setHue() and setSaturation() commands.

Long story short. Any guidance you can provide with the correct syntax to use when using setColor(), setHue, etc will be greatly appreciated. Even an example of a driver that processes these commands would go a looong way. Otherwise, I’m just shooting in the dark and patching things together and as other color lights are ported over I’ll probably get requests to make it work with theirs as well.


#8

setColor(Map), and that map is [hue:<value>,saturation:<value>,level:<value>]
Apps and drivers currently expect all values to be 0…100, yes we all know that Hue is 0…360, you can blame the other guys for setting that precedence.
setHue(<value>), setSaturation(<value>), again 0..100
If you’re writing drivers to be compatible with other apps ect, then you need to map the currently established norms for the given values into what the actual device needs.

Regarding the “established” range for Hue, personally I would just like to settle on 0…360, however this will cause all sorts of issues in legacy apps that are expecting to both set and read values in the 0…100 range…, and that’s the only reason we’re stuck with this.
Several of the RGBX drivers I wrote have a 360 degree hue preference option, but again, any app expecting 0…100 isn’t going to play well with that setting…


#9

I thought I tried this but who knows at this point. I might have been trying the 360 range at that point…like I said I was throwing everything at it. I’ll give it a shot again tonight. Thanks again for the feedback.

Just to confirm, level in the map above will essentially be setting the brightness correct (same as setLevel)?


#10

Ok…so this is really weird and I think I’m forgetting something really stupid.

I set up the app to send setColor with the following and it worked perfectly …the lights turned red as expected:
[hue:100, saturation:100, level:50]
Hue bulb logs looks good as well

I even changed hue to 50 and the lights changed color expected. All good.

Next, I changed the level to 100 to verify this was a brightness setting. This is when things got weird. I got something simliar to the following in the logs

Group Bedroom Overhead Lights Color set to [hue:65535, sat:254, on:true, bri:127, alert:none, transitiontime:4]

and the light does nothing. This is what I was seeing in my previous testing that failed…this is also seen in the built in Button Controller app btw.

So I put the settings back to 100,100,50 that worked before…I get the same kind of return in the logs. Huh?
It just worked with those setting a minute ago. Please tell me I’m doing something foolish because this is frustrating @mike.maxwell


#11

Ha, I missed the part where you were working groups, anyway two bugs were fixed, and will be out in the next release.
setColor did not work if executed from the driver ui, this affected all drivers. setColor did not work with groups in the hue integration.
Yes, level in setColor is the same as setLevel, it should also be an optional parameter, but this will be driver dependent.


#12

Ahh…thought I was going crazy. Still weird that it worked a couple of times but who knows, I probably didn’t save my changes or something stupid on my end.


#13

@mike.maxwell , I tested the following in the setColor command for my Hue bulbs (from the driver page)
[hue:10,saturation:100,level:100]

I entered the same in my custom Lifx driver page and it doesn’t seem to execute at all. No errors, no logs. Just seems like it doesn’t run at all. Any advice? Is the setColor command available for custom drivers?


#14

Here’s the setColor method

def setColor(value) {
	log.error "sdfsdf"
    log("Begin setting groups color to ${value}.", "DEBUG")
    
    def data = [:]
    data.hue = value.hue
    data.saturation = value.saturation
    data.level = device.currentValue("level")
    
    sendLIFXCommand([color: "saturation:${data.saturation / 100} hue:${data.hue * 3.6}"])
    
    sendEvent(name: "hue", value: value.hue, displayed: getUseActivityLogDebug())
    sendEvent(name: "saturation", value: value.saturation, displayed: getUseActivityLogDebug())
    sendEvent(name: "color", value: value.hex, displayed: getUseActivityLogDebug())
    sendEvent(name: "switch", value: "on", displayed: getUseActivityLogDebug())
    sendEvent(name: "level", value: "${state.level}", displayed: getUseActivityLogDebug())
}

#15

Any update on this @mike.maxwell?


#16

its available with any capability “Color Control”
This is how I’ve been implementing it:

def setColor(value){
    def intHue = value.hue.toInteger()
    def hexSat = value.saturation.toInteger()
    def level = value.level.toInteger()
    if (level) do levelStuff
}

#17

Thank you.
I have the capability setup and I will implement similar to your example when I get home.
Still think it’s a bit strange that I get nothing in the event log when setColor is activated.


#18

you invoked it from the device details, and nothing?


#19

Yessir. I added the log.error to confirm. Nada.


#20

Found the issue. While trying in vain a few weeks ago to get it working I added
command "setColor"

removed that unneeded line and I’m good to go.