The small ramp up/fade that occurs when a smartbulb (LifX for me) is turned on/off can’t be accessed? I searched the forums+wiki and could find no answer to this simple task, that IMHO should be a global preference that you set to your liking.
1 Like
It’s not likely to be a global preference as this is usually determined by a parameter saved in the bulb itself and the options available vary by manufacturer.
I would start by contacting LIFX and ask them if the ramp rate is configurable.
Well, the thing is that if I use the LifX app, the lights are turned on/off instantly, while when using the Smartthings app:
“on” has a slight ramp (.3 sec?)
“off” has a noticeable ramp (.7 sec?)
This leads me to believe that ST introduces some additional controls. Not that I don’t like it, I actually want to increase the ramp fade ins to make it a tad easier on the eyes. That, in combination with a staggered on switch approach when one enters the home could lead to quite nice scene build ups 
Pull the DTH from GitHub and customize it.
I think it’s more likely just lag introduced by the cloud to cloud integration.
@JDRoberts Do you mean that the ST app introduces yet another layer of cloud communication? It could be the case but I hold programmers capabilities and integration APIs in higher regard than that
I just tried both apps. Here is a short movie depicting the different scenarios i am experiencing: https://goo.gl/photos/2z62HusFxJzf7K2q9
1.) starting with the LifX app controlling a specific bulb
2.) switching over to the ST app to do the same thing:
The optics/sensors of smartphones aren’t light sensitive enough to accurately portray the event, but the difference should be visible.
If I’m reading this right, you like the slight delay and want to build upon it. You could set up Gentle Wake Up app to bring your lights up to level slowly or fade out slowly as you enter/leave.
You could set up Gentle Wake Up app
Thanks, I thought of that as I’m already using that app, but unfortunately the finest granularity is minutes, not seconds and fractions thereof.
Try CoRE then.
Many SmartThings integrations are “cloud to cloud.” For example back when you could still work with TCP bulbs, you could turn on the switch in your house, the event would go to the SmartThings cloud, The smart things cloud would realize a TCP command was required and send that over to the TCP cloud which would then send it back to the TCP controller in your house which then sent it to the TCP bulb.
The SmartThings/hue bridge integration doesn’t require going cloud to cloud, but it still requires the cloud. You turn on the switch in your house, event goes to the SmartThings cloud, it sends a request back to the hue bridge, which sends it to the hue bulb. This is cloud processing even though it’s not cloud to cloud.
In contrast, if you have harmony control a Hue bulb, The harmony hub sends a local request over your own LAN to the hue bridge. Same number of steps, but you don’t need to have the Internet turned on.
I don’t know how the LIFX/smartthings integration works, but I don’t think it’s all local, but maybe. @tyler would know.
Hi JD… No, I believe @Mario_Fuchs is referring to the “ramp up / ramp down” dim speed configuration available in many dimmable lights (and outlets).
There is actually a second parameter in the setLevel( brightness, duration ) that nobody uses (and isn’t implemented in all the DTHs … but it is in some…).
Z-Wave Dimmers (and perhaps ZigBee?) can store this as a configuration parameter in their firmware, but the DTH can also just send it along with every command when setLevel is called.
That’s why the easiest way to fix this, is probably to just edit the DTH.
@Mario_Fuchs: If you don’t know what I mean by find the source and copy the DTH, then … well, somebody will tell you how, or I’ll give more details when I get some time, or I’m available for affordable tutorial sessions.
1 Like
CoRE seems to cross my path more and more. When time permits I’ll try to get my head around it, but it sure looks like somewhat of a hurdle to conquer. Thanks!
Yes, this seems lo be the likely source. So…
DTH would be the “device type handler” specific to how ST handles LifX bulbs, and one would get it from Github?
Any alteration to this file would mean a global change then I suppose.
Sounds like the way to go, thanks @tgauchat!
I still think it should be a user definable preference exposed in the app, but the beauty of ST is just this: if there is a will, there’s (usually) a way 
That’s correct thinking, but that does require all SmartApp developers to be conscientious about the API available to them.
Then again, the second parameter to “setLevel()” has apparently been deprecated without warning.
The new definition for Capability Switch Level now only has one parameter for the command.
http://docs.smartthings.com/en/latest/capabilities-reference.html#switch-level
Sigh. It is very difficult to do development on a moving target.
Ok, so browsing through this documentation i get this:
setLevel(number, number)
where
The capability is defined to accept two parameters, the level and the rate of dimming
and
Attribute Type Possible Values
level Number A number that represents the current light level, usually 0 - 100 in percent
But how would I know what the value for dimming rate ratio should be (more than trial and error)? a percentage seems a bit strange to use for rate value.
Where do you see an example that still shows the “old” Command setLevel() with two arguments?
Regardless, the way it used to work, is the first number is the brightness level in percent (0 to 100), and the second number, I believe was the duration of ramp time in seconds (i.e., 5 means the brightness would take 5 seconds to ramp from the previous level to the specified level, and/or from off to that level, or from that level to off).
Not all DTH’s implemented this (I’d be surprised if even half of them have implemented the second parameter). But visit the SmartThings Community Public GitHub and look at several Dimmer DTHs and you’ll see if they implement this second (dim rate) parameter.