One more thing. troubleshooting I have your device set to 10 minimum and max to 99. In the bulbs it is reporting 6 and 60 when I hold them in the logs. Bizarre. Changed the minimum to 19 and in the app it is showing 9 now. Tried to updated the max to 166 and it wont do anything. I’ll put my coding hat on later and see if I can figure it out.
Any help would be appreciated.
Kent - I fixed up the code so the percentages are correct. On sets to 100% correctly and so does whatever dim level you put in. I didn’t realize that ZigBee commands take a Hex value based on an integer of 1-255 for dimming. I put in the code to convert that correctly now.
I have to say though that I quit using my own code 
While it is a lot faster, there are too many problems to overcome. You could spend the rest of your life redesigning my code to work with every single device out there. There is just too many settings and actions defined in the device types for specific devices. I see why things in SmartThings are developed the way they are.
For example, I have GE Link bulbs and couple things don’t work right.
The major thing is that I have come to discover is that the network ID is more like a DHCP IP address. It gets assigned, but could change if a ZigBee devices requests a new one. The more appropriate thing to use would be the Zigbee ID which does not appear to change. However, I cannot figure out how to get a device’s current Network ID from their ZigBee ID in a device type that does not belong to itself. So I had my GE Link bulbs continually want to get new Network IDs thus breaking my Device until I went in there and updated the IDs again. The Network ID is needed in the ZigBee command to turn on/off/dim a device.
Also, the GE Link bulbs refreshed dim level through its own device type to display on your phone. So when I send a command directly to the GE Link bulb from the Osram Dimming Switch device type, it would dim the light correctly but not update your phone. On and Off seemed to work but not the dim level. That might be a simple update to the GE Link device type to have it report back any changes no matter where that change comes from, but that just shows how each Device Type is created differently.
On a good note, I noticed my Osram bulbs never seem to want to change Network IDs and they report the Dim level correctly. So I may use my code with those so they turn on and off faster! For the record, I also think Osram bulbs deliver a much better light then the GE Link or the Cree Connected bulbs do. Much less directional and more pleasant.
Brad
Awesome thanks. I meant to reply asking about Hex because of the percentage off (honestly I did) but have some family health issues I am dealing with.
I have put most of mine back on the lightify hub again.
So they work locally during Internet outages. Not that often but I just had an hour outage in the morning. And had to take the switches off to manually flip the lights…
Firmware updates
Default levels color and brightness
Turning the dimming off/on feature off.
They also are instantaneous on/off when I push the switches via the hub. no delay at all.
And I agree on the light bulbs light level. One of the reasons I went with them.
Wish I had a better coding brain. I’d try and get the smartthings - lightify hub api working. Then we could have the best of both worlds. Local control from the lightify switches. And rule automation from smartthings. Don’t care if a rule takes a second to flip the lights on outside.
Thanks again for all the hard work!
Hi all,
I’m trying to use this device handler and smart app with the SYLVANIA Lightify 73793 bulb (the dimmable and color changing).
it seems that the bulb is not accepting the commands send out by the dimmer switch. I suppose that the mart app needs to be adapted to the new bulb? how can I do that?
Hi, I’m new to SmartThings and Groovy, but I’m pretty good at Java. I took a stab at the Lightify Dimming switch using jkrischt’s code. I rewrote most of it to make it conceptually simpler and less redundant. I suppose I could optimize the code further, but I’m limited on my knowledge of the zigbee protocol and SmartThings resources.
I added the following features to the below code:
The following features were maintained from jkrischt’s code:
I want to improve both the user experience and the functionality. I have plans for future releases… But again I’m limited on my knowledge of the proper SmartThings way of doing things.
I’ve already implemented a sendEvent for button release. Next I will need to register a listener for the device. Then when the button is held, it should instantiate a recursive loop with the runIn method, which will call itself and resend the command to raise the brightness until the button release event is called. Or, would it simply be better to just monitor State/AtomicState? I’m in a decision freeze.
How can I extract the proper EndPointID from a light with capability switch? Is there a way to autodetect this? It seems there should be a way to autodetect it.
I would like to be able to send the commands, usually generated from the physical device, from the app. Is there an easy/generic way to do this? I want to simulate button presses in-app. for example, where do I fire “st cmd 0x${device} 0x${end} 8 4 {FE 0000}” INTO?
I’m really enjoying this community, even though this is my first post, it’s great to see these community-based projects growing.
I just embarked in a similar project, but changed the device type into a dimmer switch that responds to on, off and level commards directly without having a smartapp. You do need to use a smart app to actually have the switch control something. I’m using with Dim with Me to control three smartbulbs in a hanging light fixture.
I was trying, without success, to have a similar process where holding the button would continually increase/decrease the level until you let go. I tried using runIn, which didn’t have any delay in device type. With further testing, I don’t believe my process would have worked as I was using a state variable to determine if the button was released, but I don’t think the state variable will ever get the value change in the current event from a subsequent event. (either that or my code sucked).
Also, I opted for increasing/decreasing by 20, as that seems to be a sufficient difference in level without have a lot of button presses. Also, because the device is a dimmer switch, you can set the level via the smartthings app or smarttiles.
The device type is here:
BTW - thanks for fixing the battery level!!! I added your fix to my device type Thanks!!!
What is the best device type code to use with something like CoRE/Smart Lighting at this point? I just want a switch that can turn a set of lights on or off. Hold to dim/raise would also be useful but it’s not a deal breaker.
I haven’t used Core, but the “Alternate OSRAM Lightify Dimmer Switch Device Type” device type shows up a switch so it should be easy to incorporate into either and can be on or off.
I’m guessing the “original” device type would show up as a button. You would need to test the devices it is controlling for their on/off states. There is definately a level of flexibility with treating the device as 2 separate buttons that have both a push and held event, but I’m not sure if Core and/or SmartLighting would handle those features. @Motley or @adamoutler may be able to assists.
I’m working on Lightify Dimmer this weekend. Still adding Bells and whistles… I wat tap-on, tap-off, persistent and smooth dimmer, and on when dimmer is activated. I’m handling this using persistent states within the switch.
Currently this is the only physical switch that requires no wiring and it is also the cheapest. So, go with this because it’s cheap and it works. Stay with this and you’re going to see new features soon.
The Osram is a good device, but not the only one that requires no wiring. GoControl has a very similar switch cover design (although it’s zwave). Cooper 9500, which looks the most like a regular switch. Hue dimmer switch (a little bit cheaper then the Osram although the Philips doesn’t work with SmartThings, it just works as a parallel means of control). SmartenIT 3 toggle. All have different features and looks.
So just depends on what features you want, and the aesthetics you prefer. 
I believe Core will work with any Device which is set up as a “button controller”, including this device with the original DTH. But @ady624 would know.
Also, just to clarify for those not as familiar with the smartthings architecture:
The SmartThings lightify smart switch can be set up three different ways in SmartThings depending on the device type handler you select. Which one you select will depend on the specifics of your own use case.
One) as a zigbee remote. This is the manufacturer’s intended design. The switch is directly bound to individual ZLL light bulbs, and controls them directly without communicating what it has done to the zigbee Coordinator (in this case, the smart things hub). This can work well, but the status will be out of sync until smart things polls the individual bulbs again. And the device cannot be used to control z wave devices, run routines, change modes, etc.
Two) as what SmartThings calls a “button controller.” The Aeon minimote is probably the most popular of these, but there are a number of devices in this class. A button controller has multiple numbered buttons, each with a value of “held” or “pressed.” ( short and long press)
A button controller can be used in the built-in smart things features like smart lighting and can also be used with routines to change modes, activate an SHM alarm state, etc,
The button press information is sent to the hub and the hub then sends out the appropriate commands based on the smartapp/routine being used, which means a button press can control a device of any protocol that can be controlled by smartthings. So you could have a group that included a Z wave outlet, a zigbee bulb, and a WeMo outlet and they could all turn on and off together with one button press.
The button controller device itself is not turned on or off by SmartThings. Like a handheld television remote, the buttons are used to send commands out, but it does not generally receive commands in.
The original device handler in this thread set up the lightify smart switch cover as a button controller.
Your use case is not my use case
So why would you define this device as a button controller instead of a switch? Well, the technical reason is that this “switch” doesn’t actually control any current load. Consequently, if the hub sends an on command to it, nothing is going to happen. So technically it’s not a switch. It’s a button remote. In fact, I’m not even sure it can receive an off command from the hub.
But if you do define it as a switch there are a few smartapps where you could then just use it directly without needing additional code. Which might Be useful for some cases.
That brings us back to the issue of A persistent hold to set the dimming level. This should work great with the first method, where this device is directly controlling zigbee bulbs.
As has been noted in this thread, it won’t work with the second method, because button controllers typically only have two durations for each button: short and long press.
As to whether you can make it work with the third method, where you’ve defined the device as a zigbee switch, to be honest I just don’t know. It might work. It comes down to the exact information that the device sends to the hub.
Anyway, I just thought that might be helpful to some people who wondered why this device is set up different ways by different people. 
I’m attempting to create a Level Control Cluster. The device has 5 states, 2-pressed, 2-held, 1 released. It should be possible to dim while held until released. The problem I’m having is runaway runIn.
For some reason the runIn command is executing 10-100 times per second. According to documentation, it should be running once every 1 second.
Here is the code in question
`/**
* adjusts brightness up/down depending on the value of the up boolean true is up, false is down
* continues to adjust until state.dimming is changed
*/
def Map adjustBrightness(final boolean up){
Map result
if (state.brightness>99) state.brightness=95
if (state.brightness<1) state.brightness=5
if ( state.dimming ){
log.debug("adjusting brightness" + (up?"up":"down")+ " from current "+ state.brightness)
//increase or decrease brightness
if (up){
state.brightness=state.brightness+1
} else {
state.brightness=state.brightness-1
}
//convert the percentage into a 0-250 hex representation and create commands
result=createStCommand(" 8 4 {"+Integer.toHexString((Integer)Math.round(state.brightness*2.5))+" 0000}")
fireCommands(result.value) //send it to the hub for processing
reportOnState(true) //Manage and report states
runIn(10000,adjustBrightness(up)) //WTF?!?!?!
} else {
log.debug("Final brightness adjusted to "+state.brightness)
}
return result
}`
The runIn command appears to just take off, completely disregarding it’s integer of 10000 which should wait for 10,000 seconds. Any ideas or workarounds?
I was trying to do the same thing in my device handler (Alternate OSRAM Lightify Dimmer Switch Device Type) and got the same results, runIn was completely ignored.
Not sure what is going on here, but it appears the runIn doesn’t work in Device Types.
As a general test of the concept, I used a while loop as a delay (which is a big no-no in the SmartThings docs).
The delay worked but the brightness adjustment either went all the way up or down.
I was using a state variable that changed on the release of the button. Apparently the state variable does not change in the instance of the device type that is running. So the iteration of the device type that it doing the dimming will never see the iteration of the device type that receives the “release” and changes the state variable, since they are running concurrently.
The next time the device type runs, the state variable will be set as expected, but it’s too late.
(I’m pretty sure I found this info about state variable on a community thread, if not it’s buried in the docs)
At that point, I gave up and set my adjustment to 20, so that 5 buttons holds would go from high to low.
I know this doesn’t help, but may save you some time trying to get this to work.
Unless of course, someone in the community can give us some info on how to accomplish this.
FYI - the device type I created (Alternate OSRAM Lightify Dimmer Switch Device Type) treats the dimmer as a dimmer switch which does accept on/off/dim commands, but still requires a smart app to tie the switch to a device(s). I’m using “Dim With Me”.
I’m using to control 3 smart bulbs in an overhead light, which had been tied together using a “Virtual Dimmer” and “Dim with Me”.
The main reason I went with creating the device as a switch is so the Osram switch shows up in the app as a switch showing the on/off/dim states and can be controlled directly n the app and SmartTiles.
If you ask your question in the developer section of the forum, someone should be able to help.
https://community.smartthings.com/c/developers/writing-device-types
I got it working. I also discovered a new button, both pressed and held = button 3 pressed.
Both buttons held for over 3 seconds enters into Pairing mode 
That’s great!!! What did you have to do?
No. Both buttons held for 1+seconds sends command 06 03. Which is actually a hidden button. The Lightify Hub detects that and responds with proper pairing commands. The fact is, you can actually use it to trigger anything you’d like.
def Map handleButtonPress(Map msg){
switch (msg.command){
case "01":
def returnval=on()
return returnval
break
case "03":
bothButtonsPressed()
break
case "00":
def returnval=off()
return returnval
break
default:
log.error("got unknown button press command: "+msg.command)
return "error"
break
}
}
I’m going to use this to call a 5-second delay and then a smart app or routine. EG. all lights on, all lights off, make toast… that sort of thing.