Xiaomi Opple 6 button remote

Received my 6 button Xiaomi Zigbee 3.0 remote. It's been an odd experience so far, from receiving my package from Canada Post on Sunday (Canada Post doesn't normally deliver on the weekend at all), to the seemingly dead on arrival device, with no instructions on how to change the battery, and it's strange pairing result.

Despite all this, I will say that its physical design is very nice. The branding is very subtle, and the device feels very solid. I learned some important facts about this device that will hopefully help others that want to try it, and hopefully a driver can be created. It does look and feel worth the effort.


Even though it was packed in an unpadded poly mailer, the device itself was completely unharmed on arrival.


The controller is an eggshell white plastic that feels tough and seems very flexible as you'll understand from my experience trying to open it without a clue how.

Two neodymium magnets secure the controller to its base, which has two anti-slip strips on the back and comes with three adhesive strips and two screws, probably for direct attachment to a Chinese electrical box.

Opening for battery changes

As mentioned, I was surprised to find the device not showing any signs of life on arrival. Like all Xiaomi devices, it has the battery already installed and there is no pull tab for activation. I thought for a bit that maybe it was a piezo device and I had missed something in the description. Using Google Translate, I was reassured, but puzzled that they wouldn't include any instruction on how to change the battery, especially since there is no obvious way to open it. In China, these devices come with installation help and on-site service, so that must be their reasoning.

I began prying at the small gap between the buttons and the back housing, when I discovered two points on the top and bottom of the back housing that seemed to be holding the front to the back. A little more aggressive prying and one side broke free, then the other, and finally the entire front assembly released from its housing. As you can see in the center, there was actually a small screw also holding the assembly together. I'm lucky that I only slightly stripped the hole, and didn't crack the housing or the post in the center.

The problem:

There's a couple of things to unpack here. First I find it difficult to believe that two companies with so much experience building these type of devices could get this one wrong, but the battery holder does seem to be an issue with this device.

I pulled the battery and measured it with my ZTS MBT-1 and it was full strength. It was quite obvious that the battery had corrosion on the negative terminal, so I figured a simple cleaning with 2000 grit emery cloth would resolve that, but it did not. I replaced the battery, but found that it still wouldn't work. Only when the battery is placed lower in the holder than what looks to be the recommended position screened on the circuit board, did the device begin to work.

How to properly open the controller

  1. Press on one of the two middle buttons to raise one side and allow a plastic spudger to be inserted.

  1. Once you get the spudger in the gap underneath the button, push forward along the width of the two buttons. The thickness of the spudger will cause the middle button to release. As you can see in this photo, the back of the button has four tiny, yet very pliable tabs that hold it in.

  1. Remove the tiny philips head screw in the center

  1. Again use the spudger to pry between the housing back and the top assembly. Start in the middle since this is where the back housing flexes the most, then work the spudger right and left to release the clips. Ensure you are prying downward, into the bottom case, not up on the button itself. There are two clips on the bottom and two on the top which can be seen in the photo above that shows the inside of the back housing with the magnets. With the screw out, it may only be necessary to pop the clips on either the top or bottom, not both.

Disassembly of the holder for screw mounting

Unlike the controller itself, the holder has two very obvious places to insert a spudger so it can be disassembled. This is necessary if you want to mount the holder using screws. You will need to use a sharp knife to cut out the plastic where the screws go.


This was not easy, and the results are a bit odd on both Hubitat and the Aqara HomeKit Gateway. The device is slow to pair. In fact I had to start the pairing over a few times, since it wouldn't finish before the time ran out. When it did pair to my home hub on channel 13, it was discovered as a Xiaomi leak sensor. This makes some sense because I do have that driver loaded. However when I attempted paired it to my test hub on channel 20, it failed to join multiple times before finally succeeding. However, once it paired, it was found as an Orbit 12 unit sprinkler controller !? Not only that, but in all cases, HE hub and Aqara HomeKit Gateway, the device is discovered twice, but one of the two are unresponsive and can be deleted.

Although pairing with the Aqara HomeKit hub also took an unusually long time, it works fine with HomeKit when all is said and done. Oddly it also created two devices. One was not responsive, and deleting it from HomeKit caused no harm.


@veeceeoh, here is the device fingerprint if you'd like to take a shot at a driver for this. It seems to respond with the Xiaomi button controller driver, but not at all how I expected.

**Manufacturer:**  LUMI

**Product Name:**

**Model Number:**  lumi.remote.b686opcn01

**deviceTypeId:**  90


manufacturer : LUMI

idAsInt : 1

inClusters : 0000,0003,0001

endpointId : 01

profileId : 0104

application : 11

outClusters : 0003,0006,0008,0300

initialized : true

model : lumi.remote.b686opcn01

stage : 4

manufacturer :

idAsInt : 2

inClusters : 

endpointId : 02

profileId :

application :

outClusters :

initialized : false

model :

stage : 0

manufacturer : 

idAsInt : 3

inClusters : 

endpointId : 03

profileId : 

application : 

outClusters : 

initialized : false

model : 

stage : 0

manufacturer : 

idAsInt : 4

inClusters : 

endpointId : 04

profileId : 

application : 

outClusters : 

initialized : false

model : 

stage : 0

manufacturer : 

idAsInt : 5

inClusters : 

endpointId : 05

profileId :

application : 

outClusters :

initialized : false

model :

stage : 0

manufacturer : 

idAsInt : 6

inClusters :

endpointId : 06

profileId : 

application :

outClusters :

initialized : false


As I mentioned, the result with the Xiaomi button controller driver and this Xiaomi Opple Zigbee 3.0 button is strange to say the least. Without any rules or other configuration, when I pressed button 2, all my Zigbee 3.0 switches (an Aqara dual relay, and two Trådfri plugs) simultaneously turned on. This was kind of a problem at 1:30am, since the Aqara relay triggers the alarm on the Aqara HomeKit Gateway. Pressing button 1 turned all three off. I thought this was a fluke, so I unpaired and repaired the device, but the results were the same.


This is a really small and well made controller, that I wouldn't have a problem displaying anywhere in my home. I do hope for the sake of the community, that a driver for HE can be developed. In the mean time, I'm using it with my Aqara HomeKit Gateway and it's working perfectly. It was necessary to update the Aqara Gateway to version 1.6.7 to get it to pair, and this is only available when the country region is set to Mainland China. Although it appears as an available device to add to the Gateway in the HomeKit only region for Europe, it will not pair. This may be related to the Gateway firmware, since each time I switched to a region other than Mainland China, the Gateway said it needed updating again after switching the region back to Mainland China.


Many thanks for the (as usual) super-thorough overview and details on disassembly (dissection?!)

You have echoed the same disappointing findings about the really difficult-to-replace battery as I read in the Homekit News review:

Based on that, and also the current lack of information about the Aqara+Opple Smart Switch buttons' adherence to ZigBee 3.0 specifications, I am opting to wait to invest in a unit to see about putting together a driver (if I ever find time!)

That said, if these new switches are actually fully following ZigBee 3.0 specs, then using a generic multi-button driver may yield better luck in bringing out at least partial "normal" functionality. There's only one way to find out...

I got mine the other day and have got it to pair with my hub and have the same button results that 2 turns all zigbee devices on and 1 turns them off.
I then tried connecting it to my hue hub and had the same results but it turn out button 3 dims bulbs and 4 brightens them. I gather this would be the same on my hubitat hub but I don't have any bulbs on it to test .

It was also interesting to see that button 1 & 2 only seemed to send the same instruction to the hub regardless of whether the push, double tap or they were held.
The other 4 buttons do send a different instructions but the "double tap" sends the same same as held but then sends a release instruction after it. I'm not going to pretend that I know if this is normal but seemed odd to me.
Held works by holding the button down for 5 seconds and then doesn't send anything else after this.
I forgot to screenshot the logs but it looked to me (after a bit of googling about zigbee) that it was using the endpoint 0xffff for groupcasting which explains effecting all zigbee devices but I'm not going to pretend I know anything about this.

Have this setup with HomeKit on the Aqara Gateway, and despite the weird design for the battery, I really like it. Since HomeKit doesn’t support toggle, I created a simple RM rule and when I want to toggle a device, I just add a virtual switch that flips on for 500ms and toggles the device. Works great.

This is for sure one of my favorite controllers now.

Another very strange product design decision. I have to assume the Aqara hub / ZigBee mesh ignores the groupcast messages, but without any documentation on the ZigBee implementation of these Aqara-Opple switches, I'm not sure there's any way to disable groupcast so that the switch simply sends messages to the hub alone.

On further reading, I found out that messages to endpoint 0xFFFF are broadcast to all nodes (every device) on the ZigBee mesh network. This even includes "sleepy" end-devices which will be forced to wake and receive the message.

My guess is that this is an intentional feature, either to be changed by sending a command to the switch in order to set the desired endpoint, or an intentional method to make these switches incompatible when used with anything besides Xiaomi / Aqara gateways. But this is just a guess. Otherwise, sending every message as a broadcast to every device makes absolutely no sense whatsoever.

1 Like

Interesting. May have nothing to do with it, but I’ve noticed that on occasion, after the remote has been unused for a while, pressing one of the buttons (not button 1) will need to be pressed twice. Like the remote went to sleep. But pressing button 1 never does this. The Insteon lamp on that button always responds immediately. Whereas the Insteon lamp in button 2 doesn’t always respond on first press.

It’s not an issue with my Insteon integration, because if I use a Pico to control them, they always respond in first press (unless the Pico isn’t responding that is :stuck_out_tongue_winking_eye:)

I agree that it must be by design to stop compatibility with other devices.
For reference here is what the logs record for each single press for 1 to 6 top to bottom.

I still haven't been able to get the held and double tap to work for 1 &2 but if it was possbile to stop broadcasting to every device it wouldn't be too hard to create a driver.

@SmartHomePrimer does the held and double tap work on the Aqara Gateway?

Yes it does, as that’s part of HomeKit and when paired with the Aqara HomeKit Gateway, this becomes HomeKit compatible.

There’s no toggle in HomeKit, but I solved that with a virtual switch that toggles off after 500ms for each device need that on and a simple RM rule.

Has anyone been able to figure this out as I’ve jumped the gun and got one of each for around the house a 2 , 4 and a 6 button before looking to see if this would work
If I can assist in any way let me know

Don’t think you’re going to be able to do anything directly with HE. If you purchased that many, then the only way today you’ll be able to use them with HE is via the Aqara hub and a sync back to HE via Homebridge/HomeKit.

You might be able to use them with the Mijia hub and this method, but not certain about that one as that’s a very specific hub needed.

1 Like

I tried it with the Mija hub and the buttons are not compatible.

1 Like

Unfortunately there are two other threads referring to the Aqara-Opple button "switches", so it's hard to know where to post my findings on whether they can be used with the Hubitat Hub, but since this this thread refers to them by name, I'm going to post here:

I have gleaned the best information on how the Aqara-Opple button "switches" work from a technical standpoint from this DeCONZ Rest Plugin comment thread on GitHub:

Here are some choice quotes from that thread to explain how they work, and the potential issues as a result:

Technically, no, the switch does not communicate with the gateway; it sends broadcast (groupcast) messages, which are also picked up by the gateway. The gateway eavesdrops on the messages from the switch to the group.

Note that these OPPLE switches work very differently from the other Xiaomi switches, which indeed send reports straight to the coordinator, and cannot control lights directly.

I concur it controls all the lights: 2 top buttons are on and off, the middle buttons are dim up or down and the 2 lower buttons are more yellow or less yellow color.

It would seem the Opple is a hybrid, just like the Hue dimmer switch: it sends both commands to control the lights directly as well as reports to inform the coordinator.

is there a way to make it control only specific lights?

Normally, I’d suggest to create a group, add a light to it and bind the switch’s client clusters to that group. Not sure if that’ll work for Xiaomi, though. Might be enough to bind only one cluster, but could also you need to bind all three ( On/Off , Level Control , and Color Control ).

well - its kinda working now, with lots of limitations. you can use it to control on/off, dimming and color as long as your lamps are also controlled by conbee - you can create a group of lamps in phoscon and connect the switches using the bind option in deCONZ (you can bind to a group or to a single light). but thats about it.

To stop the Opple from sending broadcasts, you need to create bindings from the On/Off and Level Control clusters. Best practice is to a group. The switch doesn’t know nor care wether any lights listen to that group.

So, based on all of that, as I've mentioned here, it sounds like these Aqara-Opple button "switch" devices operate much like the IKEA 5-button "steering wheel" remote that Hubitat has stated they will not be supporting.

However, if it's possible via a device driver to configure the Aqara-Opple buttons with bindings from the relevant clusters to a non-existent group (i.e., with no members), then perhaps it could be made to work with Hubitat. However, there are other peculiarities discussed on the above-linked thread which will probably make it a real challenge to build a driver that accesses the full functionality of the buttons.

The first thing to settle before even deciding to spend any time working on a driver is whether these devices' need to send messages to a group in addition to reports to the coordinator will work on the Hubitat platform at all.

I think only @mike.maxwell would be able to answer that (and I imagine he would be able to correct me on any misuse of terminology or misguided explanations I've given here as well! :rofl:)


If any of you are Apple haters, well then I feel sorry for your loss, because this works really well and you get a 100% reliable connection to a lot of really inexpensive and solid performing sensors and buttons.

Here it is for reference. I can lead a horse to water...

1 Like

@veeceeoh Thank you for getting all the information into one place! Well researched and very good to know!
The news could be better though, this doesn't sound great... I'll eagerly await the input from @mike.maxwell :slight_smile:

@SmartHomePrimer, thank you for sharing, I would be very interested in knowing if that hub works with this:

I'll buy a hub and try, if it works or can be made to work with some modifications, it could be worth implementing in Groovy. What would need to be determined first is if the required crypto libraries are available on HE and if zeroconf can be used with the available network calls.

An intermediate step in the evolution of solutions for this could also be the Python HomeKit Controller + Homebridge to keep the number of devices involved down... It is probably MUCH harder to get working properly than your way, but still, less devices...

Input regarding what?

what @veeceeoh is writing about above :slight_smile:

I don't see mention HomeKit automations with that. I'll keep simplicity thanks.

You can get an iPhone 6s for much less than I posted. That was just a quick example I grabbed. Lower prices come up all the time. It is the simplest way. You should be able to find one for around $50-60 typically. If you're not an iPhone user normally, just use the iPhone 6s for a controller and to build HomeKit basic automations that link devices to virtual switches, and the HE devices to buttons on the Opple controllers. All complex rules are done in Rule Machine on HE.

If you then get an Apple TV 4, the non-4K version, it's less expensive and I've read they're more stable. Mine is the non-4K, and it has never caused me trouble. I also use mine with our primary TV, but if you already have a streamer of choice, just connect it to your TV temporarily, set it up with HomeKit and then disconnect it and put it with your HE, just like any other hub.

No matter what, you will also need to run Homebridge, or any other bridging app on something. That could be a Docker image on your NAS if you have one, it could be a Raspberry Pi, and it can be an old computer. But whatever you use, it's really nice to have, because there are a lot of Homebridge plug-ins to connect other non-HomeKit hubs and bridges.

I recently added an OSRAM bridge plug-in so I can use their garden lights and bulbs, but not screw up my HE Zigbee network. If you're a nest protect owner like I am, there's a plugin that lets you connect them to virtual switches with HomeKit, so you can trigger lights again and tie it to other actions in HE. There are many other very useful Node.js apps too, so it's great to have that capability at hand. An old laptop that runs cool is a great asset if you have one kicking around. I have an old MacBook Pro that just sits quietly, sideways on a shelf with the lid closed. I remote into it when I need to, and it runs four other Node.js applications for me. It's been a very stable setup.

So with the cost of the iPhone, the Apple TV4 and the Aqara HomeKit hub for $36, you're looking at around $190 USD. But, then you start subtracting the savings on up to 32 Aqara or Mijia contact, motion sensors, or Opple buttons and other devices. The list of Xioami and partner products is growing fast. Once it's on their hub, the devices are amazing and their small, nice looking and low cost.

When the Aqara M2 hub finally comes out, you won't get the light and alarm functions with that hub, but you will gain Zigbee 3.0, the ability to use up to 100 devices with a single coordinator, and keep HomeKit compatibility. You then will also have access to existing Xiaomi products, and their upcoming 3.0 products.

It would not be handled with HomeKit automations, it would be a gateway to connect HomeKit devices directly without any Apple products in-between.

First off, thank you for the very detailed answer!

As for Apple devices, personally I do have Apple phones, an Apple TV 4 (not in use) and all the pre requisites except the Aqara hub. I have as of today more than 60 Xiaomi/Aqara zigbee devices connected to HE and my mesh is very stable.

I do hope your answer helps someone else though, I'm more interested in this because it would be fun to either write a driver for the 6 button remote, or port the HomeKit Controller code from Python to HE. In either case, I'll go get the current Aqara hub once the stores are open again. When they do have the Aqara M2 available I'll try that one as well.

With this said, I do have other projects to complete, just like most. Will try the existing route first to see how well they work and then work on replicating that using less devices and more code... What I'm talking about creating would be this:

But in Groovy instead of Python... Let us see how that goes...

1 Like

Cool. You are lucky. That's quite rare. I wouldn't be able to duplicate it, and with the success, and then rapid failure I had, along with the restrictions it put on the HE hub, I wouldn't try that way again personally. I do have a few Xiaomi devices still directly connected that are stable, but the rest weren't. It was very easy for me to get going since I was already an Apple user. I kind of figured from your reply it wasn't your way of approaching the issue, and my response was indeed primarily meant for the community in general if they wish to do the same. :slightly_smiling_face:

1 Like