[OBSOLETE] OSRAM Lightify Smart Dimmer Switch (button controller device handler and smart app)

If you post up the fingerprint, I might be able to add some additional pointers or at least confirm that the Hue Switch is the right template.

This is what you need right? I converted the below logs to the fingerprint line also below.

c16f1a9b-f899-41f5-b234-76a1a79746ee 5:50:55 PM: trace NON-HUE EVENT desc: 01 0104 0001 00 06 0000 0001 0003 0020 0402 0B05 04 0003 0006 0008 0019 c16f1a9b-f899-41f5-b234-76a1a79746ee 5:50:55 PM: trace Location: desc: 01 0104 0001 00 06 0000 0001 0003 0020 0402 0B05 04 0003 0006 0008 0019 c16f1a9b-f899-41f5-b234-76a1a79746ee 5:50:54 PM: trace NON-HUE EVENT ep_cnt:1, ep:01 c16f1a9b-f899-41f5-b234-76a1a79746ee 5:50:54 PM: trace Location: ep_cnt:1, ep:01

fingerprint profileId: “0104”, deviceId: “0001”, inClusters: “0000, 0001, 0003, 0020, 0402, 0B05”, outClusters: “0003, 0006, 0008, 0019”, manufacturer: “OSRAM”, model: “Lightify 2.4GHZZB/SWITCH/LFY”, deviceJoinName: “OSRAM Lightify Dimming Switch”

Seems to be a bit different by looking at the fingerprint you have in your code.

The core functionality will be the same and come from the 0006 and 0008 out clusters which will send the on/off/dim commands. The binding in the Hue configure section should make sure ST gets copied on those commands similar to the Hue.

What’s different and cool is this switch actually has some useful in clusters. Good chance it will stay connected. Only one of the in clusters will be configured. 0402 is temperature measurement, so this switch should have a temp sensor. Check out the Smartsense motion sensor code for examples of incorporating temp reporting and parsing.

I have high hopes for this switch.

Ok, I am currently looking through your example and trying to understand what all is going on, once I do that I will look into the temperature sensor. I would be surprised if it does has a temperature sensor as the docs say nothing about that and there is virtually nothing on the board, I only see 2 very small chips on a mostly blank board (other than the 2 buttons and an LED). I would think if it had temperature they would advertise that.

The one thing I can see different already though is the Hue switch has 4 physical buttons where this one only has 2, the dimming function works by holding either the up or down button, single press of up turns on and single press of down turns off.

@Sticks18, I am trying to understand what is going on and not having a lot of success but i have not given up. I am curious if you can tell me what I need to have in place to see messages that are coming from the switch? I have the device paired and using a device type which is basically a copy of your code with the fingerprint changed but when I click a button I see nothing in the live logging section in the IDE. My initial guess is the commands are not coming in via cluster ids 6 or 8 so the conditionals are not firing and hence no messages are generated.

Also, I have been reading some docs and the commands being used in your code don’t match up with what I am reading, either I am misunderstanding or reading the wrong thing or is your code written for the V1 hub and I have a V2 which is different? Again I am fairly new to the ST hub and especially the custom coding so I appreciate your help.

Good luck with this, I am very interested in this device as well. :sunglasses:

I used to be a network engineer so I understand this type of coding but I am now quadriparetic (use a wheelchair and have limited hand function) so I now rely on text to speech, which means I can’t read most code now. (Trust me, you do not want to do groovy with text to speech!)

Coding for the V1 hub and the V2 is the same, and the same device handlers work on both.

Anyway, since you’re a programmer, you might find the following thread helpful. In it a community member picks up a new 3 button Zigbee key fob and with the community’s help builds a new device handler for it. Although it’s a different device class and so uses different clusters than the Osram switch, it’s the best example I know of for how the process works with SmartThings and Zigbee devices:

Also, here’s the FAQ on the various logs available:

And the FAQ on publishing custom code so you can use it, although you may not need this one once you’ve been through the other two:

They recently changed some of the zigbee coding documentation; however this type of device will need to use the older methods since they didn’t update ZDO Binding and they won’t have these command messages in their zigbee database.

You probably aren’t getting messages because the configure() section hasn’t run. The easiest way to get this to run while the switch is awake and able to receive messages is to reset the switch and pair it back to ST. Now that you have a device handler installed with the fingerprint, it should pick that one automatically and run the configure…

You’ll also want to un-comment the 2nd line in the parse section log.trace description so you can see the full message coming from the device when you press buttons. Press ‘on’ on the switch and see what comes through. Hold ‘on’ on the switch to start “dimming” and see what comes through. Most likely you’ll see one message during the hold and another when you let go. Repeat this for ‘off’ button and you should have all the messages the switch sends.

Then it’s a matter of deciding how you want those messages to be treated to create events in ST. If you can log all those messages and when/how they come through, we can help you come up with the best solution for treating the messages.

Thanks both of you for the additional info, I will work on this more today.

@JDRoberts, I understand the IDE and how to install/use custom code but I will definitely look into the other 2 for more tips, especially the logging since I think that is the biggest part I am missing right now. Once I know the messages that the switch sends I don’t think I will have too much issue figuring out what to do with them. I think trying to use text to speech to decipher any programming language would have some major challenges and interesting side effects. :smile:

I did write a smart app to work with my Fibaro RGBW controller so it is just a matter of figuring out the device type code, in my profession I develop code and manage infrastructure for a configuration management solution called Puppet so I feel confident in the coding space once I figure out what inputs I will be dealing with.

@Sticks18, I did try to reset the switch and re-pair it with the device code in place but for some reason it still associated itself with the “Acceleration Sensor” device type, also when it comes up in the ST app it shows as a presence device and when I click to configure it brings up my already configured mobile phone, if I back out of that configuration then the device shows as an unconfigured device and I can go through the configuration step. In this case since it automatically assigned itself to the “Acceleration Sensor” device type it probably ran the config for that device type. On my next attempt I will validate the the correct device type is associated before I try to configure it so that the correct configure code will run. I believe I have read that you can pair a device but then login to IDE and change the device type before actually configuring it, is that correct?

I have seen this before where a device I am trying to add shows up as a new presence device and then when I back out I can configure the correct device so I suspect this is just a bug in the ST app for Android

Currently I have the log line set to debug (log.debug “Parsing ‘${description}’”). Should I still remove that line or is debug the level I want anyway? If I remove it altogether is debug the default (maybe I will find this out by reading the logging doc that @JDRoberts posted)?

Just wanted to report back what I have found so far. I was finally able to get the switch to start sending output using the code at the Github site below. Please keep in mind this is an early work in progress and is my first attempt at device handler code!

I was able to get the output below from the switch. I am guessing the first to lines returned are the initial return of the configCmds array? The same command seems to come back when you let go of either the up or down dimming button so I assume the first command is a dim up/down command and then the second command is a stop command? The others are obviously the on/off commands. Now to see what I can do to use these commands, will I have to write a smart app to bind the dimmer to specific lights or can that be done in the device handler config? I would assume the latter but maybe not.

`configCmds??
ed5e70cd-04bf-4bed-bf71-13d2e5b50ce2 5:00:45 PM: debug parse description: catchall: 0000 8021 00 00 0040 00 68C9 00 00 0000 00 1B 00
ed5e70cd-04bf-4bed-bf71-13d2e5b50ce2 5:00:45 PM: debug parse description: catchall: 0104 0006 01 01 0140 00 68C9 01 04 104E 03 00

On
ed5e70cd-04bf-4bed-bf71-13d2e5b50ce2 5:03:15 PM: debug parse description: catchall: 0104 0006 01 01 0140 00 68C9 01 00 0000 01 00

Off
ed5e70cd-04bf-4bed-bf71-13d2e5b50ce2 5:03:39 PM: debug parse description: catchall: 0104 0006 01 01 0140 00 68C9 01 00 0000 00 00

Dimmer Up
ed5e70cd-04bf-4bed-bf71-13d2e5b50ce2 5:03:44 PM: debug parse description: catchall: 0104 0008 01 01 0140 00 68C9 01 00 0000 05 00 0032
ed5e70cd-04bf-4bed-bf71-13d2e5b50ce2 5:03:47 PM: debug parse description: catchall: 0104 0008 01 01 0140 00 68C9 01 00 0000 03 00

Dimmer Down
ed5e70cd-04bf-4bed-bf71-13d2e5b50ce2 5:03:50 PM: debug parse description: catchall: 0104 0008 01 01 0140 00 68C9 01 00 0000 01 00 0132
ed5e70cd-04bf-4bed-bf71-13d2e5b50ce2 5:03:53 PM: debug parse description: catchall: 0104 0008 01 01 0140 00 68C9 01 00 0000 03 00`

Normally in SmartThings we don’t use single protocol local binds or associations, but rather treat the device as a “button controller” and send all commands to the hub. This allows a Zigbee switch to control a zwave light or a group combining some Zigbee devices and some zwave devices. Or change a mode, run a routine, etc.

This can introduce a small amount of lag, but allows for much more flexibility.

Yeah, I am currently knee deep in groovy docs and other device handler examples and starting to see that. From what I am seeing you parse the commands and create events the the hub can use to trigger other things. I think this means that someone would need something like the Button Controller along with the device handler to map the buttons to a device, is that correct?

I am starting to write some conditionals based on the command being returned and calling some other objects that I still need to define which will create the proper event which can be used by a smart app. Am I on the right track or am I complicating it? The groovy language is very new to me so still stumbling through.

Thanks again for all the tips.

1 Like

Very cool! And you’re spot on with your breakdown of the commands. The on/off commands are pretty easy. 01 is command for ‘on’, and 00 is off from 0006 cluster.

For the dimming (cluster 0008), the 2nd command for each is indeed a stop command 03. For dimming up they’re using 05 which is move with on/off meaning the light will turn on if it’s currently off, then the payload 0032 means the direction 00 is dimming up and each of these will move 32. Dimming down is very similar but they use command 01 which is just move because they don’t want the light to turn off when dimming starts. Payload is similar to dim up, but first two digits are 01, which means down direction. Same 32 step.

It sounds like you’re on the right track by using conditionals and creating events. @JDRoberts is right that configuring it as a button remote gives the most flexibility and is what this community will probably want. But feel free to explore direct device binding too as it will result in a much faster, more natural experience with zigbee bulbs.

1 Like

Yeah, I guess I wasn’t considering binding directly to a device, maybe I didn’t make that statement clear. What I was kind-of expecting was that there would be a way to select the ST devices that you want to control during the config part of the device handler (when you add a new dimmer switch), then unless you re-configure it the switch would always trigger the on/off/dim events to those specific devices.

I have an updated copy of the device handler on the github site previously linked if you wouldn’t mind checking it out and see if I am on the right track. At this point I think I have the logic setup as needed but still trying to understand how to create these events and then what the next step would be. Currently the code has a bunch of debug log statements just so I can see the flow is working correctly, the output I now get when pushing the buttons is below. This is with the conditional logic in place and showing that the correct function is called and the command/data fields were passed which I am guessing is all I need for the event.

c56e4422-3682-498e-abce-a9102dedf37d 8:02:40 PM: debug Stopping brightness change. c56e4422-3682-498e-abce-a9102dedf37d 8:02:40 PM: debug Command is 3 and data is [] c56e4422-3682-498e-abce-a9102dedf37d 8:02:40 PM: debug SmartShield(clusterId: 0x0008, command: 0x03, data: [], destinationEndpoint: 0x01, direction: 0x00, isClusterSpecific: true, isManufacturerSpecific: false, manufacturerId: 0x0000, messageType: 0x00, number: null, options: 0x0140, profileId: 0x0104, senderShortId: 0x601d, sourceEndpoint: 0x01, text: null) c56e4422-3682-498e-abce-a9102dedf37d 8:02:40 PM: debug parse description: catchall: 0104 0008 01 01 0140 00 601D 01 00 0000 03 00 c56e4422-3682-498e-abce-a9102dedf37d 8:02:39 PM: debug Decreasing light(s) brightness. c56e4422-3682-498e-abce-a9102dedf37d 8:02:39 PM: debug Command is 5 and data is [0, 50] c56e4422-3682-498e-abce-a9102dedf37d 8:02:39 PM: debug SmartShield(clusterId: 0x0008, command: 0x05, data: [0x00, 0x32], destinationEndpoint: 0x01, direction: 0x00, isClusterSpecific: true, isManufacturerSpecific: false, manufacturerId: 0x0000, messageType: 0x00, number: null, options: 0x0140, profileId: 0x0104, senderShortId: 0x601d, sourceEndpoint: 0x01, text: null) c56e4422-3682-498e-abce-a9102dedf37d 8:02:39 PM: debug parse description: catchall: 0104 0008 01 01 0140 00 601D 01 00 0000 05 00 0032 c56e4422-3682-498e-abce-a9102dedf37d 8:02:37 PM: debug Stopping brightness change. c56e4422-3682-498e-abce-a9102dedf37d 8:02:37 PM: debug Command is 3 and data is [] c56e4422-3682-498e-abce-a9102dedf37d 8:02:37 PM: debug SmartShield(clusterId: 0x0008, command: 0x03, data: [], destinationEndpoint: 0x01, direction: 0x00, isClusterSpecific: true, isManufacturerSpecific: false, manufacturerId: 0x0000, messageType: 0x00, number: null, options: 0x0140, profileId: 0x0104, senderShortId: 0x601d, sourceEndpoint: 0x01, text: null) c56e4422-3682-498e-abce-a9102dedf37d 8:02:37 PM: debug parse description: catchall: 0104 0008 01 01 0140 00 601D 01 00 0000 03 00 c56e4422-3682-498e-abce-a9102dedf37d 8:02:36 PM: debug Increasing light(s) brightness. c56e4422-3682-498e-abce-a9102dedf37d 8:02:36 PM: debug Command is 1 and data is [1, 50] c56e4422-3682-498e-abce-a9102dedf37d 8:02:36 PM: debug SmartShield(clusterId: 0x0008, command: 0x01, data: [0x01, 0x32], destinationEndpoint: 0x01, direction: 0x00, isClusterSpecific: true, isManufacturerSpecific: false, manufacturerId: 0x0000, messageType: 0x00, number: null, options: 0x0140, profileId: 0x0104, senderShortId: 0x601d, sourceEndpoint: 0x01, text: null) c56e4422-3682-498e-abce-a9102dedf37d 8:02:36 PM: debug parse description: catchall: 0104 0008 01 01 0140 00 601D 01 00 0000 01 00 0132 c56e4422-3682-498e-abce-a9102dedf37d 8:02:32 PM: debug Turning light(s) on. c56e4422-3682-498e-abce-a9102dedf37d 8:02:32 PM: debug Command is 1 and data is [] c56e4422-3682-498e-abce-a9102dedf37d 8:02:32 PM: debug SmartShield(clusterId: 0x0006, command: 0x01, data: [], destinationEndpoint: 0x01, direction: 0x00, isClusterSpecific: true, isManufacturerSpecific: false, manufacturerId: 0x0000, messageType: 0x00, number: null, options: 0x0140, profileId: 0x0104, senderShortId: 0x601d, sourceEndpoint: 0x01, text: null) c56e4422-3682-498e-abce-a9102dedf37d 8:02:32 PM: debug parse description: catchall: 0104 0006 01 01 0140 00 601D 01 00 0000 01 00 c56e4422-3682-498e-abce-a9102dedf37d 8:02:29 PM: debug Turning light(s) off. c56e4422-3682-498e-abce-a9102dedf37d 8:02:29 PM: debug Command is 0 and data is [] c56e4422-3682-498e-abce-a9102dedf37d 8:02:29 PM: debug SmartShield(clusterId: 0x0006, command: 0x00, data: [], destinationEndpoint: 0x01, direction: 0x00, isClusterSpecific: true, isManufacturerSpecific: false, manufacturerId: 0x0000, messageType: 0x00, number: null, options: 0x0140, profileId: 0x0104, senderShortId: 0x601d, sourceEndpoint: 0x01, text: null) c56e4422-3682-498e-abce-a9102dedf37d 8:02:29 PM: debug parse description: catchall: 0104 0006 01 01 0140 00 601D 01 00 0000 00 00

Yeah, the device handler usually doesn’t restrict use to a specific binding. (There are a few exceptions.)

Instead, a smartapp like button controller is used to allow each person to specify the devices they want to use for that specific instance.

For example, it’s entirely possible to have a switch control one set of devices during the day time and another set at night. Just as an example, I have a motion sensor in the bedroom at my house.

During the day, the motion sensor is ignored.

In the evening, triggering that motion sensor turns on the overhead light.

At night after I’ve gone to bed, the exact same motion sensor does not turn on the overhead light. Instead it turns on a soft nightlight.

If I did those associations in the device handler, I wouldn’t be able to use the same motion sensor to control different sets of lights. The device handler does not have conditional filters.

By moving those selections to the smartapp level, which do have conditional filters, I can control just what happens when.

So depending on the use case, yes, it’s pretty common to create both a custom device handler and a smartapp to go with it. :sunglasses:

But that doesn’t mean you have to.

1 Like

Looks like you have the dimming up and down flipped, but your conditionals are all working.

Unfortunately you would need a SmartApp to accomplish what you’re thinking with selecting devices because you can’t trigger zigbee commands from parse() of a device. I tried exactly this with the Hue remote as an “alternate” control method for people wanting to control zigbee bulbs and found out it didn’t work. I ended up writing a small SmartApp that acted as a pass through. When I’m not on my phone, I’ll try to share it with you if you want.

1 Like

Yes, I did notice the flipped log statements which I have fixed as well as (just for curiosity) I added a binding to the inbound cluster for the temperature as you mentioned but either I did not do that part right or it just does not work, I see no messages coming in but not sure if I need to “poll” for them or what. I have not pushed these recent changes to Github yet.

I am interested in anything you want to share to help with this, as far as the device type once I figure out how to create the events is that pretty much it? as long as the events are created they can be used by a SmartApp?

If it was me, I would treat this switch as a two button remote with both pushed and held variants like:

On command = button 1, pushed
Dim up = button 1, held
Off command = button 2, pushed
Dim down = button 2, held

You can use the Hue remote code to see how to create button events. Once the device is creating/sending those events, you’re done with the device handler. SmartApps can then subscribe to the events and take action.

1 Like

Ok, so the latest version is up on the Github site, any input appreciated. I am guessing the events are being created as I see no errors and I see the log messages like below. I am not sure if I can pass an array of button numbers with the event like I am doing for the release event but it could be either button released so not sure how to handle that one, maybe it is good as is. I do think the conditionals could probably use some cleanup and I would not be surprised if there is some other changes needed but I see no errors so not sure what else would be needed.

68df2dc6-c59a-4c17-8a88-db44a3b1096e 9:14:59 PM: debug Parse returned Dining Room Dimmer button 1 was pushed 68df2dc6-c59a-4c17-8a88-db44a3b1096e 9:15:01 PM: debug Parse returned Dining Room Dimmer button 2 was pushed 68df2dc6-c59a-4c17-8a88-db44a3b1096e 9:15:03 PM: debug Parse returned Dining Room Dimmer button 1 was held 68df2dc6-c59a-4c17-8a88-db44a3b1096e 9:15:04 PM: debug Parse returned Dining Room Dimmer button 1 or 2 was released 68df2dc6-c59a-4c17-8a88-db44a3b1096e 9:15:06 PM: debug Parse returned Dining Room Dimmer button 2 was held 68df2dc6-c59a-4c17-8a88-db44a3b1096e 9:15:07 PM: debug Parse returned Dining Room Dimmer button 1 or 2 was released

Hmmm, very interesting. I just went back to look at the logs and saw the below, does this mean there is a temperature sensor? Would there be some conversion/calibration needed? I can assure you the temperature in my house is not 124.15 (F or C) :neutral_face:

If I keep this inbound cluster enabled I am guessing I would need to add code to handle that message to avoid the error reported.

68df2dc6-c59a-4c17-8a88-db44a3b1096e 9:25:43 PM: error java.lang.NullPointerException: Cannot get property ‘command’ on null object @ line 52
68df2dc6-c59a-4c17-8a88-db44a3b1096e 9:25:43 PM: debug null
68df2dc6-c59a-4c17-8a88-db44a3b1096e 9:25:43 PM: debug parse description: temperature: 124.15

That is interesting. You could try adding a refresh() command and use:
zigbee.readAttribute(0x0402, 0x0000)

That will read the temp value, so you can see if the 124.15 is definitely what the device is sending. That 124 is probably ST conversion from C to F. Not sure why the device would send something so high. Maybe Osram is using it for internal device temp?