RELEASE: OSRAM Lightify Smart Dimmer Switch (button controller device handler and smart app)

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. :sunglasses:

@jksearles

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. :sunglasses:

1 Like

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.

  1. as a regular zigbee dimmer switch. The information about on/off/dim would be sent to the hub, and again there would be some smartapp or routine that would cause the hub to send the appropriate commands to whatever device you wanted to use. Normally a zigbee dimmer switch would also actually control the current load to a light fixture. Also, unlike a button controller, a switch can be turned on or off by the hub.

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. :sunglasses:

2 Likes

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. :sunglasses:

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 :wink:

1 Like

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.

I’m using a recursive loop on a state, along with a timed brightness value

/**
* 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,int level){   
    Map result 
    log.debug("adjusting brightness" + (up?"up":"down")+ " from current "+ state.brightness)  
    if ( state.dimming ){ 
        //increase or decrease brightness
        if (up){
          state.brightening=true
        } else {
          state.brightening=false
        }
        state.brightness=level
        executeBrightnessAdjustmentUntilButtonReleased()                
    } else {
        log.debug("Final brightness adjusted to "+state.brightness)
    }

    sendEvent(name: "brightness", value: state.brightness)
    return getStatus()
}

/**
* performs a recursive brightness adjustment based on state.brightening while state.dimming is true
*/
def executeBrightnessAdjustmentUntilButtonReleased(){
    if (state.dimming){
        if (state.brightening){
            state.brightness=state.brightness+20
        } else {
            state.brightness=state.brightness-20
        }
        if (state.brightness>100) state.brightness=100 
        if (state.brightness<1) state.brightness=1
        setLevel(1000,state.brightness)
        reportOnState(true) //Manage and report states
        runIn(1, executeBrightnessAdjustmentUntilButtonReleased)
    }
}

So, brightness is set to current state.Brightness+20% with 1000 milisecond time-to-dim each second the button is pressed.

here’s my method to set level

/**
* handle level commands,
* level=desired level
* duration=desired time-to-level
*/
def setLevel(Double level, Double duration) {
    log.info("Brightness commanded to "+level+"%")
    state.brightness=level
    def result=createStCommand(" 8 4 {"+getBrightnessHex()+" "+duration+"}")
    fireCommands(result.command)//send it to the hub for processing
}

I’m also working on getting the in-app controls working properly. I am bad at UI work. I’m working on proper reporting, on-off toggle, level set, and a “special” button. I think everything else is almost in order.

Yes. Both buttons held for 3+ seconds enters the Pairing mode. (This is from the product manual).
I’ve also tested this a couple of weeks ago when a device was not connecting and it worked.

I never said that the device does not send a command when both buttons are pressed, and I’m glad that you’ve find a use for it, but I don’t think the manufacturer original design was to use both buttons pressed as a button command.
Also, I was just trying to help just in case somebody presses both buttons for over 3 seconds and the Blue light starts blinking :wink:

1 Like

Pairing is handled in two stages on Smart Things.

  1. Detection - once the device is on the network it has been detected, any activity detects.
  2. Setup - once the device is configured in-app, commands are sent via configure().

This leaves the pairing button unused for SmartThings.

I’m sorry, I found this confusing. Smartthings uses a certified Zigbee coordinator, and pairing occurs exactly as it does with any other certified Zigbee Coordinator. Configuration is always a separate step.

Putting the device into pairing mode should mean it stays in pairing mode until either the join is complete or the device times out. So if you are manipulating the device such that the firmware goes into pairing mode, then isn’t the device unable to accept any other button presses until it times out? That would be different than using other button patterns.

It might still fit certain use cases, but it’s not just another button pattern.

1 Like

What did you do to get the runIn() to work?