Thanks v much for your work on this! Am using this device type with rule machine and the transition time parameter you’ve added for gentle wake up. Perfect.
Can’t work out how to amend the Smartthings Hue smart app to call the transition time parameter though. (I’m new to Smartthings). Just that one extra parameter would make that app really useful and although I can get the app to collect the value, I can’t seem to get it to pass it through. Frustrating!
No I don’t have a hub, the hues are connected directly to ST using the enhanced device type.
The SmartApp I attempted to change is called Hue Mood Lighting - it is one of the options when you create a new SmartApp from a template.
It has the usual section to select triggers and mode filters and, in terms of hue functionality, allows you to choose colour and brightness. I was trying to add transition time as an additional parameter to complete the feature set.
Benefit of Hue Mood Lighting app over rule machine is that it has a ‘play’ button. I have different scenes that can be called either by just hitting play or through triggers or timers. But the gentle wake up ones need transition time… Was enjoying the challenge of trying the change the code - just wish it had ended in success!!
You picked a tough one to change because the level change gets lumped in with the color change. This devicetype takes a lot of action in the setColor() command that might be difficult to manage correctly. What’s your typical use case? Is the bulb off and you want it to slowly turn on, but in a specific color? Is it on and you want it to dim off slowly in a specific color?
I think if this is for a wake up scenario and the bulb is currently off, you could try this (lines 259-262):
def newValue = [hue: hueColor, saturation: saturation, level: null, switch: off]
log.debug "new value = $newValue"
hues*.setColor(newValue, 0)
Than after the setColor() command, you would probably want a small delay to make sure it fires first, followed by (I don’t know the best way to implement a short delay):
hues*.setLevel(lightLevel, transitionVariable)
I believe this would change the color of the bulb but keep it off, then you would use a normal setLevel() command with the slow transition to dim it on.
If this doesn’t work or isn’t as flexible as you’d like, then we could pretty easily add a new custom command to the devicetype that doesn’t do things like turn the bulb on/off, so you would call something like setColorLevel(color[], colorTransition, levelTransition) that will just move the color and then the level.
Thanks for the advice, much appreciated. You got it absolutely right - basically a slow turn on in a particular colour maxing out at a particular level.
In rule machine using 4 custom commands (in 1 rule) I’ve got the hue to do a nice wake up by:-
sethue(1)
setlevel(0)
setcolourtemperature(2000,6000)
setlevel(2000,6000)
So I’m trying to see If I can get the hue app to use the transition times in the same way as rule machine.
Anyway thanks again for your advice. First week messing around with ST code so lots to pick up!
Interesting combination! Looks like you make the bulb Red, then have it dim to a very warm sunrise-ish white. I’m guessing the setLevel(2000,6000) is a typo. Level only goes to 100, haha.
Since you’re doing custom commands anyway, you might want to add a 0 or instant transition for the first two commands. That way you definitely shouldn’t see the bulb accidentally pop on briefly. So:
setHue(1,0)
setLevel(0,0)
Then again if it’s working the way it is, who am I to mess with it! Good luck working on the Hue app! Let me know if I can help further.
Hi Bernie, are you in the US or UK? My “tester” was based in the UK and testing on the Gardenspot lights. It seems like the firmware of the UK versions of Osram devices are ahead of the US versions.
I recently got a set of Gardenspots in the US and got the same result as you. I also bought the Lightify hub to update them, but even after a firmware update they haven’t implemented the color loop feature. I confirmed this with Osram support, and they say the Gardenspot update should be available in the US soon.
I’m not sure what’s available for the RGBW strip at this time. It’s possible that if you updated the firmware with the Lightify Gateway, you’d have color loop functionality; but it’s also possible it wouldn’t do any good yet.
Sticks, Is this the device that is now listed in the available devices in the IDE? I have 4 Phillips bulbs, they are showing as Thing in ST. I have tried changing them to Zigbee Hue, and Well As RGBW and I can select on/off but they never respond. They have never been connected to a hue bridge before. They have bene connected to the osram bridge. I could really use some help getting them working. If I have to end up ditching them im going to be pretty bummed out. If you need any info from me please let me know.
Is this the best code to use for the hue light plus LED strip connected to ST direct? I am familiar with the IDE and custom device handlers, just new to hue and don’t want to buy their bridge.
The stock Zigbee RGBW device handler should work well for the light strips plus. This custom code will give you the extra features detailed in the first post. I expect all of them to work with the light strips plus. You might notice issues with color selection because this code was tested on the A19 bulbs that have a different color gamut. I don’t have light strips to help fine tune the color mapping for them.
A month later probably isn’t helpful, but the US Osram line uses zigbee HA, whereas the EU stuff uses ZLL. The color loop is an extended feature of ZLL, so that’s probably why the color loop doesn’t work at all on US Osram. It’s really frustrating because their tech support keeps saying it’s coming soon for my Gardenspots, but I don’t think they even realize it’s an empty promise. Supposedly you can ask them to push you the EU firmware, but I haven’t tried.