Now why would I ask such a question if I knew explicitly what this translated to...
WELL, since you asked, you asked me to describe the results. The fact that you blew me off tells me you're not interested in dealing with people like me who aren't developers. I can only describe what I observed, and I think I did that pretty well. If there's anything else I can do to help you figure out how to fix this driver, please let me know.
*edited for civility
@kilowatts there are developers here too? and here i thought we were all part time code hackers here 
@mike.maxwell was probably just trying to understand the use case.
here is some code for sunrise ramp i had lying around. is this what you were looking to do?
definition (
name: "rooms test app",
namespace: "bangali",
author: "bangali",
description: "rooms test app",
category: "My Apps",
iconUrl: "https://cdn.rawgit.com/adey/bangali/master/resources/icons/roomOccupancy.png",
iconX2Url: "https://cdn.rawgit.com/adey/bangali/master/resources/icons/roomOccupancy@2x.png",
iconX3Url: "https://cdn.rawgit.com/adey/bangali/master/resources/icons/roomOccupancy@3x.png"
)
preferences {
page(name: "roomsTest", title: "Rooms Test")
}
def roomsTest() {
dynamicPage(name: "roomsTest", title: "Rooms Test", install: true, uninstall: true) {
section("") {
input "roomLight", "capability.switch", title: "Light?", required: true, multiple: false
input "roomMinutes", "number", title: "How many minutes?", required: true, multiple: false
input "roomMinKelvin", "number", title: "Minimum Kelvin?", required: true, multiple: false
input "roomMaxKelvin", "number", title: "Maximum Kelvin?", required: true, multiple: false
}
}
}
def installed() { initialize() }
def updated() {
initialize()
state.inSeconds = ((roomMinutes * 60) / 100f).round(0).toInteger()
state.kelvinIncrease = ((roomMaxKelvin - roomMinKelvin) / 100f).round(0).toInteger()
if (state.inSeconds > 0 && state.kelvinIncrease > 0) {
state.level = 0
state.kelvin = roomMinKelvin - state.kelvinIncrease
runIn(1, rampUpLight)
}
else
log.debug 'number of minutes or difference between max and min kelvin too small.'
}
def initialize() {
unsubscribe()
unschedule()
}
def rampUpLight() {
if (state.level != 99) runIn(state.inSeconds, rampUpLight);
state.level = state.level + 1
roomLight.setLevel(state.level)
state.kelvin = state.kelvin + state.kelvinIncrease
roomLight.setColorTemperature(state.kelvin)
}
3 Likes
Thanks @bangali. So this looks like a verbatim "sunrise" effect, replete with Kelvin changes and all. Awesome. However, I was only referring to a smooth level change, so this only proves Mike's point on the need to use clear terminology. Sooo let's start over.
If @SmartHomePrimer is right about the bulbs themselves not responding to 0% then we're SOL. However the other Sengled bulb models do respond to 0%, so it might be worth having a look at the driver.
I'm having trouble finding where the hub drivers are located. Someone linked to Mike's git in another thread but I only see 4 drivers in there. (Understood if end users are discouraged from tampering)
I checked the setLevel sections of the ct and standard bulb drivers, in both cases we pass whatever value is sent straight to the device, ie both drivers use the same code for level adjustments.
In my limited testing with 0 on bulbs, there is no common standard in the way they respond.
Neither is there a standard on what they do when 0 is accepted, and you turn the bulb on with on, most seem to come up with some default level, but again, non-standard here.
1 Like
So there's a bit of history behind the operation of these bulbs and the driver development that you didn't see. I really encourage you and others that are new to the platform to use search in the forum so you can get a bit of background before posting. I'm guilty of not always doing it myself, but there's no call for a lack of civility.
The Sengled Element Plus bulbs are very unique, due to their ability to be dimmed by a conventional dimmer and via Zigbee. No other bulb that I'm aware of has that capability, and would otherwise sustain damage or act erratically if you tried it. As a result, they don't act like typical Zigbee bulbs and @mike.maxwell worked to create a driver that would control them as smoothly as possible and still encompass other Zigbee bulbs. I think he did a great job. And yes, @mike.maxwell is very much associated with Hubitat. He's one of the founders working tirelessly to create drivers and other software that we're all benefitting from. Much respect is earned and deserved.
Here are some rule machine rules I have been using for quite a long time to fade the Sengled Element Plus bulbs to off and another to allow them to fade on. It works relatively smoothly (most of the time) with these bulbs. They misbehave and sometimes fade on or fade off very unevenly. Occasionally just jumping to full ON or straight to OFF, with no fade. This particular behavior seems to be related to whether or not they were previously controlled conventionally via the dimmer, vs being controlled digitally via the Zigbee radio. It typically takes a cycle on and off again via Zigbee to get them to at least exhibit their normal behavior via Zigbee. They did the exact same thing on SmartThings and Wink, both of which have custom drivers written in cooperation with Sengled for these bulbs. They're just not going to behave like your typical Zigbee bulb. They'll fade to 1%, but it looks the same as 4%, and then they just suddenly turn off. It's just not smooth with these bulbs, but the results I'm able to achieve with separate rules controlling these bulbs is the best I've been able to achieve with any of the three hubs I tried them on to date. I have given up trying to make a silk robe from a sow's ear, The bulb are not standard, don't behave standard, and the evidence would suggest they're never going to. I have a rule for ON in the way I prefer with these bulbs and a rule for OFF. I have resigned myself to the fact that these bulbs are different and must be treated as such.
!
3 Likes
[quote="kilowatts, post:14, topic:1211"]
Thanks @bangali. So this looks like a verbatim "sunrise" effect, replete with Kelvin changes and all. Awesome.
/quote]
sure thing. right. you could remove the kelvin set off course.
there is one other potential here. there is a startLevelChange command for these drivers. this currently only accept an enum … 'up' or 'down'. if you can convince @mike.maxwell to add another parameter duration and handle the level change up or down over that duration … then this command would do exactly what you want.
HE driver code is not publicly shared.
1 Like
there is another way to do this for level only. but dont know if it will run in to issues with a recent guardrail that was put in place.
@mike.maxwell | @bravenel recently there was a 120 second limit put in for long running processes. if the following commands are issued from an app … that will not timeout - yes?
light.setLevel(1)
light.setLevel(100, 180)
thank you.
light.setlevel(100,180) is implemented in the device itself. Software implementations of things similar that use runIn() will not hit the limit either, as the instance runs, calls runIn(), and then finishes in much less than 120 seconds.
cool. think rooms needs a fade down to off over 30 secs setting. 
@kilowatts another way if you wanted to give that a try.
Yea, this isn't an issue, some of these types of delays are handled by the device, some are completed using delayBetween, delayBetween is handeled directly in the hub command queues, so neither of these count against your limits.
Using pause in a driver or an app will count against your 120 second run time.
To be honest, there shouldn't be any need to use pause in an app or driver anyway, when you have runin.
now that you brought it up 
…
… originally rooms didnt use any pausing between issuing setlevel and off commands. what would happen is when there were a group of 2 or more lights … sometimes either the setlevel or the off command would be missed.
introducing a 10 ms pause between issuing those commands fixed the issue. maybe a zigbee network issue more than a HE issue though.
but i have never used long pauses like more than a few ms … thats when i use runin.
1 Like
another question: while there is a long running set level if a new command is issued to the device … does that:
- execute the new command and cancel the set level?
- execute the new command and continue the set level?
- the new command is put in the device queue and waits for the set level to complete first?
thank you.
The second command will cancel the first on the device, that's what I have observed anyway.
I beleive that's what the spec says it should do as well.
In this situation, its possible we may receive to level reports, one of which could be an intermediate value.
1 Like
Thanks for all the insight all, and thanks mike for making the best of a rather unique bulb. @SmartHomePrimer - that is amazing that it can be controlled from an in-wall dimmer, and it just so happens I have mine on a GE dimmer. Automating the on/off of the dimmer incredibly turns this sow's ear into a silk road. 
My goal for this bulb was to use it in combination with andyhawk's circadian lighting piston in a central stairwell to just light the way temporarily as people pass by. 3 different motion sensors fade it on while going up/down the steps, and it fades off about 30 seconds after motion stops. The circadian piston sets the dynamic light level at the bulb, as well as the color temperature throughout the day.
I discovered a better way to do this in case not everyone can put them on an in-wall dimmer.
Use HE's Groups app. Put the Sengled Plus bulbs in as a single group. Then use the group device instead. This allows you to use setLevel 0% = Off. The group device will show an Off state, while the individual bulb device state will appear unchanged. Then just use the group device for all automations.
2 Likes
I'm not able to get the lights to follow the same smooth dimming I get when I use my individual rules that control each bulb vs control via a group. When I use the group, they just jump on to 70% and jump to OFF. I don't get a slow fade up and down.
You are using setLevel and not on/off?
yes - Set level 70, fade 5, same as my rules. Also tried fade 25, but result was unchanged.
That's very strange. I can click setlevel with 100, and, providing the bulbs are in the On state at 0%, they will dim up smoothly to 100%
Do you have any rules that might be interfering?
