What does the dim during on/off do? Im not seeing any noticable changes when I toggle this setting. Is it suppsed to do a “ramp on” “ramp off” type thing?
By the way thanks a ton to everyone who worked on this. Much needed! 
That is the intention…The dim during on/off should add the “ramp on” and “ramp off” during on/off commands from ST (not physical on/off). The rate would mirror the rate chosen for Dim Rate. It’s harder to see this transition during ‘On’ commands because the bulb seems to start producing light around 10-15% and the light output is very similar from 50-100% (at least IMO); but it should be noticeable for ‘off’ commands.
Note: This setting gets erased when the bulb loses physical power, so we re-set it during refresh() and poll().
I am not seeing this work on any of my bulbs. I can only get instant on and instant off to work no matter what the toggle setting in on dim on/off. Weird. It works for you?
I just updated to the latest code this morning.
EDIT:
Got it working. May have a small update for the device type 
EDIT 2: Now i cannot get dim on/off to not work… so weird lol
I think I see the issue. Try reverting back to the original code, then change the dim rate option and update. After that, you should see the preferences react appropriately.
(The bug/issue: I read in another thread that when you default a preference, it doesn’t actually populate the variable and leaves it as null. The code checks dimRate and when it is null, it uses the Normal speed for dimRate; but it also assumes dim on/off is null and turns that off. In the else statement, we could add:
if (dimOnOff) { state.dOnOff = “0015”}
after the state.dOnOff = “0000” line so it would check that preference and set it as default dimRate if it’s been updated.)
@johnconstantelo can we make that small change to the primary code?
@Sticks18, no problem. As soon as I can get away from work I’ll get the device type updated and reply back to this thread. Thanks for that snippet! Stay tuned.
So the snippet you wanted added @Sticks18 doesn’t work for me either… So, I think we are having trouble because the dimOnOff is boolean. If i switch it to enum I can then action anything i want based on the value of dimOnOff. I have a few changes in place that allow the dimOnOff rate to be updated when you refresh/poll but cannot figure out how to get it to update on an update. the state.dOnOff value changes fine but the bulb isn’t seeing the update for some reason. I’ll keep y’all posted.
EDIT: STs is so weird sometimes. I had something working. But now its not again… what the heck happened. I changed nothing! lol
Check your GIT I made a commit you can approve / look at. I’m not a pro coder so its a little sloppy and you may be able to do it better then I but maybe this will give you an idea of what i had to do to get it to work.
As it stands my code will update the “rampOn” and “rampOff” when you refresh or a poll command is executed. Again, no offense will be taken if you clean up my code a little and use it to make more quality professional changes lol.
Quick question: were you hitting the “Done” button at the top-right after changing preferences? That should call the updated() function in the device type, which was used to assign the proper state variables. If you just back out of preferences using the back arrow on the top-left, I don’t think that function gets called, which could explain why it wasn’t working for you. Those new selections weren’t being “set” in the code. Going through the whole logic tree in every poll() and refresh() call seems excessive.
lol… yes…
Been around for a little while 
The logs show update is being called but nothing is actually changing.
I agree, this is the only way i could get it to work.
I think what’s happening is the value isn’t being set soon enough and the command is being “set” before you can set the dOnOff value. I was trying to get it to wait to run all that stuff for like 5-10 seconds but apparently STs doesn’t allow the “delay” command in groovy, looks like they walled it off or something… So, looks like its up to refresh and poll to do the heavy lifting.
EDIT:
Did some more testing. I was able to find a way to remove the setting of the dOnOff state from refresh and poll. So now the state is set correctly durring updated() but requires a refresh/poll to get the dimOnOff to set correctly.
Another commit submitted
Sweet! Another teastament again to why this community rocks! If its broke we fix it, if we want it better we make it better! If we want it we make it! Whats better than that!?
4 Likes
@tslagle13, very true. I’ve learned a lot from being part of ST and this community.
Your changes are done and work for me. Thanks for your contributions!
1 Like
So has something changed with the device type? I’ve been using the code since the third and it’s been working great.
@Enitech, code updated how dimming preferences worked/updated:
- dimOnOff is was boolean, and switched to enum
- properly update “rampOn” and “rampOff” when refreshed or a polled (dim transition for On/Off commands)
So the on/off dimming has been working as a binary. It also has been updating with refresh. I’m not sure if it was working on poll though.
Ah, my bad…I guess I was hoping for an easy fix cause I couldn’t replicate the issue in my testing. I’ll try this new version tomorrow. Thanks for the improvement!
Yeah, it was working if you wanted to update the “rate” but If you wanted instant on/off you could not disable it. You now can:)
2 Likes
I have two of these bulbs… Both are using this device type code. However, they act differently in ST.
With one of them, when I turn it off, I see it turn off in the log, and nothing else. Same thing when I turn it on.
With the second one, it constantly shows level changes when I turn it on or off. For example, it the dim level is at 54 and I turn it off, I get a log message that its turning off, another message that the level is changed to 0, and a third message that the level is changed back to 54. (The light stays off.). I get a similar sequence when I turn this one on as well.
Any ideas?
Thanks
Gary
I see. I never tried disabling that function. Thanks for clearing that up.
That is odd. The code is supposed to intentionally ignore those level changes during on/off. Can you uncomment the log tracing in the parse section and post some log examples. Maybe we can see where it’s failing.