Osram 4 button zigbee remote. Can we get it working?

I recently came into possession of a osram 4 button remote. (https://www.amazon.com/dp/B01M3OK6J7/ref=cm_sw_r_cp_awdb_t1_OD5PDbPZM7PAQ ) It connects over zigbee and openhab will find it but it does not actually have any ability to use it.
I am willing to test things and provide info if someone who knows how to set up things wants to help me get this working in openhab. Being how cheap these remotes can be had for I think it would be a great benefit to the community for this option to be available.
As far as I can tell each button press sends only one command - at one point while testing I got it to change one switch to on but never could get further. In trying I changed settings and now can’t even get that to happen again. Anybody interested in getting this running?

This remote has come up before and I think I remember @chris saying that it doesn’t work with the zigbee binding as osram does something outside of the normal standard here but I might be wrong. But @chris is definitely the expert here.
I had it once in combination with the actual hub and app from osram/Sylvania. The Osram app actually Programms the scenes You can create in the app into the remote. That way it actually works even when the hub is offline and communicates with the devices directly if I’m correct.
Best regards Johannes

Have a look here in this thread about the lightify marketplace binding that communicates directly with the vendor hub:


They have the problem I described. So it doesn’t look too good unfortunately.
Best regards Johannes

Just a minor word of caution that this link is not the ZigBee binding, so it’s possible that the remote itself may work at the ZigBee level. It’s not one that I remember, but if you can see commands in the log, then maybe it’s possible to define a configuration that allows these buttons to work.

The openHAB ZigBee binding, in principle, supports remotes, but (unlike for most other ZigBee devices) each remote model needs to be added explicitly in the binding.

“Adding” includes two things:

  • Adding a thing type here. The thing type basically maps the ZigBee commands emitted by the device on a button press to trigger channels.
  • Specifying for which devices this thing type shall be used here, by mapping the thing type ID to a list of properties provided by the ZigBee device (usually something like model ID and vendor ID).

A thing type for one Osram four-button remote is already included in the binding here. But that thing type will only be used for remotes with model ID “Switch 4x EU-LIGHTIFY” and vendor “OSRAM”. As far as I know, Osram built multiple versions of the remote, which work the same (at least concerning the ZigBee commands emitted on button presses), but with different model IDs. I guess that the Osram Sylvania remote (which looks just the same as the Osram ones I know) might yet have another model ID (or even another vendor ID). In that case, to get the remote work with the ZigBee binding, one could add support for that remote along the lines of the Osram four-button remote that is already integrated in the binding.

1 Like

So if the Sylvania one uses the same commands it may be possible to support it if a modified xml can be created with the proper vendor and model id? If this is the case what would be needed from my end? Logs and attributes? Model num? I’m out of my house right now but can get those this afternoon if it would help.

I think we should first understand what the device is sending. My preference is not to add XML files to configure devices if it can be avoided since this is a maintenance nightmare. I recently found we’d done this for the Hue remote, and it is totally unnecessary and causes a bunch of issues since it only works on some versions of this remote and didn’t work for all buttons.

My feeling is that this should not be required for this device, but as I don’t have one, it’s hard to tell. If someone wants to donate a few £€$ I could purchase one for testing. Alternatively I need to see the commands that are received in a debug log.

Are you in Europe? Because I have two in a box somewhere I could send you. They are the Osram version.

Edit: just saw it says United Kingdom in you profile @chris if you send me a postage adress as a pm I can send one to you.

Best regards Johannes

1 Like

Just in case that this piece of information avoids additional work:

For the Osram version (at least for that version of the Osram remote already supported by the ZigBee binding), the thing type XML for the Osram version contains the information about which commands are sent by the remote when one presses the buttons on the remote.

For example, one can see that on a short press on the button on the bottom right the remote emits command 0x01 on cluster 0x0006 on endpoint 1, on a long press on that button it emits command 0x05 on cluster 0x0008, on release of the long press it emits command 0x03 on cluster 0x0008, and so forth (all visible in the thing type XML).

Here is the attributes for the Sylvania model I have.
model number printed on case : E21265
IC: 22089-LDV74099
FCC ID : 2AJRH-LDV74099


Im sending one of mine out to Chris next week. So he will have a look himself to get it integrated.
Best regards Johannes

Just to report
As of the latest release (2.5m4) i can reliably get button 1 to turn its switch to the on state from off and button 3 to the off state from on. The reverse is not true and no other button seems to do anything.

Also everthing now shows as a level control and has to be set as a switch.

It’s going to be worked on soon by @chris as he now has one of its own :slightly_smiling_face:

Can someone point me at some instructions for this?

From my initial look at this, it will take a little bit of work to add support - before I do too much I want to try and understand the device so finding the instructions would be useful, but I’ve not managed to find a set…

Basic users manual.

It for some reason does not mention that pairing mode needs to be manually entered by pressing the opposite buttons to the reset mode.

1 Like

Thanks.

Yep - I found that elsewhere and have got the device included into the network just fine :slight_smile:

1 Like

I’m going to need to have a play with this to see how to configure it to do different things. Currently the device I have here sends color temperature commands. I can guess that by configuring different ZigBee bindings that this might prompt it to work differently, although that’s a guess and some experimentation will be required to confirm this.

The device does have a manufacturer specific cluster, so it’s also possible that the configuration is done through this cluster instead and if that’s the case, it’s going to be a lot more difficult to integrate as we would need to work out what that cluster does. I saw that Conbee are having trouble integrating this (github issue below for my reference).

SmartThings are also having problems with it - they appear to have buttons 1 and 2 working (although I’ve not read enough to work out what the buttons do!).

I will have a bit of a play at the weekend to see if I can change what the device here does at least. If I can do that, then I’ll have a think about how to integrate it into the binding.

Further information (mostly for my records). The device doesn’t support the ZigBee methods to identify what functions it supports, and I can’t see how the keys are being reprogrammed to the different functions.

My guess is that it is using the manufacturer specific cluster to program the functions, so this is not documented anywhere (and I’ve not found it on the web).

This is currently all extracted from my debug system and I’ve not tried to hook this up with the binding yet. I would have expected the two left buttons to work as On (on the top) and Off (with the bottom button), but maybe this doesn’t work for some reason. The Color/Hue commands should also work - assuming that the configuration I see here with the switch I have is the default for all switches! It may be though that the lack of support for the commands to detect the features the device supports stops the binding from providing these channels.

I will have a play with the binding at some point over the weekend to see how tht works with the device.

Endpoint configuration -:

            1    : Profile     0104 ZIGBEE_HOME_AUTOMATION
                 : Device Type 0810 COLOR_SCENE_CONTROLLER
                   -> BASIC
                   -> POLL_CONTROL
                   -> 0x1000
                   -> 0xFD00
                   -> POWER_CONFIGURATION
                   <- COLOR_CONTROL
                   <- 0x1000
                   <- IDENTIFY
                   <- GROUPS
                   <- SCENES
                   <- ON_OFF
                   <- LEVEL_CONTROL
                   <- OTA_UPGRADE
            2    : Profile     0104 ZIGBEE_HOME_AUTOMATION
                 : Device Type 0810 COLOR_SCENE_CONTROLLER
                   -> 0x1000
                   -> 0xFD00
                   <- COLOR_CONTROL
                   <- 0x1000
                   <- IDENTIFY
                   <- GROUPS
                   <- SCENES
                   <- ON_OFF
                   <- LEVEL_CONTROL
            3    : Profile     0104 ZIGBEE_HOME_AUTOMATION
                 : Device Type 0810 COLOR_SCENE_CONTROLLER
                   -> 0x1000
                   -> 0xFD00
                   <- COLOR_CONTROL
                   <- 0x1000
                   <- IDENTIFY
                   <- GROUPS
                   <- SCENES
                   <- ON_OFF
                   <- LEVEL_CONTROL
            4    : Profile     0104 ZIGBEE_HOME_AUTOMATION
                 : Device Type 0810 COLOR_SCENE_CONTROLLER
                   -> 0x1000
                   -> 0xFD00
                   <- COLOR_CONTROL
                   <- 0x1000
                   <- IDENTIFY
                   <- GROUPS
                   <- SCENES
                   <- ON_OFF
                   <- LEVEL_CONTROL
            5    : Profile     0104 ZIGBEE_HOME_AUTOMATION
                 : Device Type 0810 COLOR_SCENE_CONTROLLER
                   -> 0x1000
                   -> 0xFD00
                   <- COLOR_CONTROL
                   <- 0x1000
                   <- IDENTIFY
                   <- GROUPS
                   <- SCENES
                   <- ON_OFF
                   <- LEVEL_CONTROL
            6    : Profile     0104 ZIGBEE_HOME_AUTOMATION
                 : Device Type 0810 COLOR_SCENE_CONTROLLER
                   -> 0x1000
                   -> 0xFD00
                   <- COLOR_CONTROL
                   <- 0x1000
                   <- IDENTIFY
                   <- GROUPS
                   <- SCENES
                   <- ON_OFF
                   <- LEVEL_CONTROL

Short press -:

Top Left
21:27:03.872  DEBUG  RX CMD: OnCommand [On/Off: D299/1 -> 0000/255, cluster=0006, TID=51]


Top Right
21:25:59.932  DEBUG  RX CMD: StepColorTemperatureCommand [Color Control: D299/2 -> 0000/255, cluster=0300, TID=50, stepMode=1, stepSize=25, transitionTime=10, colorTemperatureMinimum=0, colorTemperatureMaximum=0]


Bottom Left
21:27:24.116  DEBUG  RX CMD: OffCommand [On/Off: D299/3 -> 0000/255, cluster=0006, TID=52]


Bottom Right
21:27:49.216  DEBUG  RX CMD: StepColorTemperatureCommand [Color Control: D299/4 -> 0000/255, cluster=0300, TID=53, stepMode=3, stepSize=25, transitionTime=10, colorTemperatureMinimum=0, colorTemperatureMaximum=0]

Hold and Release -:

Top Left
21:29:25.410  DEBUG  RX CMD: MoveWithOnOffCommand [Level Control: D299/1 -> 0000/255, cluster=0008, TID=5A, moveMode=0, rate=25]
21:29:27.933  DEBUG  RX CMD: StopCommand [Level Control: D299/1 -> 0000/255, cluster=0008, TID=5B]


Top Right
21:28:38.127  DEBUG  RX CMD: MoveHueCommand [Color Control: D299/2 -> 0000/255, cluster=0300, TID=58, moveMode=1, rate=25]
21:28:41.128  DEBUG  RX CMD: StopMoveStepCommand [Color Control: D299/2 -> 0000/255, cluster=0300, TID=59]


Bottom Left
21:30:39.263  DEBUG  RX CMD: MoveCommand [Level Control: D299/3 -> 0000/255, cluster=0008, TID=5E, moveMode=1, rate=25]
21:30:41.705  DEBUG  RX CMD: StopCommand [Level Control: D299/3 -> 0000/255, cluster=0008, TID=5F]


Bottom Right
21:30:05.226  DEBUG  RX CMD: MoveHueCommand [Color Control: D299/2 -> 0000/255, cluster=0300, TID=5C, moveMode=1, rate=25]
21:30:07.305  DEBUG  RX CMD: StopMoveStepCommand [Color Control: D299/2 -> 0000/255, cluster=0300, TID=5D]

I meant to add that if the reprogramming of the controller uses the manufacturer specific cluster, then the only way to work this out would be to sniff the commands that are sent from the Lightify gateway to a switch and reverse engineer what is being sent. This may not be too hard - if someone has the gateway and a sniffer, then it would be good to see if we can get a log of what happens when the device is reprogrammed through the Lightify app.

I can send you a gateway but it has a German plug. It’s in a box somewhere.

1 Like