Hey Everyone
I hope this is in the right section. I want to pick up this.
https://a.aliexpress.com/_sWFEFH
I found a few threads on some of the switches and matching drivers. But none for this specific.
Will the other Xiaomi driver switches work?
Thanks
Check this topic out.
This is one of my favorite controllers. It's up there with the Picos, but as mentioned in my post, I'm using it with HomeKit via HomeBridge. It's great, but you just won't be able to use it with Hubitat directly at this time.
Thanks for the reply.
Super disappointed - the button looked great and would have worked perfectly for me.
Is there a chance a solution will arrive for Hubitat, or is this something that is too complicated for the effort?
It does look fun, when they open the stores here in China again after the Chinese New Year I'll see if they have any in stock in my local Aqara shop. Or I might order one, but it still requires the Chinese New Year to be over. No promises, but if it looks like something I like and there is a way to reconfigure the buttons I will look at writing a driver if @veeceeoh doesn't... But it could take some time, I have many little projects pending...
Hey!
That would be awesome.
I would love to learn how to write a driver. I don't mind doing the work. Just no idea where I would start obtaining that knowledge. Lol
For writing a driver for HE, you need to learn to code in the Groovy language (easy if you know other programming languages, probably not very hard regardless if you have the time and put in the effort). For HE specifics there's the official Hubitat Developer Documentation, the SmartThings Classic Developer Documentation and probably most important of all, check the official example repo. For Xiaomi-specific code to learn from, check the drivers by @veeceeoh , they would be the "gold standard" for this particular type of driver. So, now you have somewhere to start 
As for coding environment and all of that stuff, I use Visual Studio Code and like that, others may code directly in the HE web interface or use something else.
The only way I see a useful driver being created is if there is a way to stop the button presses broadcasting to all nodes. I haven't been able to find anything about if this is possible.
I've paired mine with my Hue hub and use it as a sort of shutdown switch to turn all of the lights off or as a dimmer for the lights I already have on.
Absolutely, first would be to know if the official app has some settings for this? If there's settings in there, next step would be to sniff the traffic between an Aqara hub and this device. I only have the older Aqara hub, so would need a newer one for this.
EDIT: @at9 it seems this switch implements the binding features of Zigbee, and does so according to standard amazingly enough, as such, the behaviour of button 1 and 2 can be changed, see here.
Honestly, adding a driver for this might put another device on the list of Xiaomi compatible devices that work well with Hubitat, like the Mijia button. But there are so few that are 100% reliable due to the non-standard Zigbee implementation.
But attach any of these to the Aqara HomeKit Gateway, and they are rock solid devices at a bargain price. So to me, the greatest value for the Hubitat community would be a software bridge (similar to Mi Connector) that would allow those that don't want to, or for them it's not a reasonable choice, to add HomeKit to their environment to bridge the Aqara HomeKit Hub to Hubitat.
Lutron Caséta Pro Bridge is one of the best investments you can make to allow you to add their very inexpensive and well designed Pico remotes, their dimmers, switches, fan controller, and now motion sensor. Even at the $100+ price tag it's worth it thanks to the built-in HE integration. However, I would argue that an integration with the Aqara Hub would be even more valuable because of the wide range of very inexpensive, small and nicely designed devices available, and with an average price of just $35 for the Aqara HomeKit Hub, it's a very good value for the money too, since the hub can also be a doorbell, alarm siren and full color Zigbee nightlight.
This for me is the reason why Homebridge has become such a valuable part of my integration now, that I just won't give it up. So for those that haven't already invested in the Apple environment (or just won't), an alternate integration would do far more than adding one more Xiaomi compatible device to the list of devices that may or may not work well with HE on a case by case bases, and limits the user to what they can do with their Zigbee network because you will be forced into using only Xiaomi compatible repeaters in order to try to keep your directly connected Xiaomi and Xiaomi compatible devices connected to the HE hub.
None of this is to say that the tremendous effort that @veeceeoh has put into direct device integration isn't worthwhile and deserving of all accolades, but I just think it's time there was something more to bring Xiaomi devices to Hubitat. Constantly fighting with their stability issues due to the non-standard Zigbee implementation wears so thin with many people that some just give up and decide that the Xiaomi compatible devices are crap. I can tell you with absolute certainty that nothing could be further from the truth. Even though they are Zigbee, their implementation needs to be considered almost as proprietary as Lutron ClearConnect. I know that's not a perfect analogy, but it illustrates my point that once you have the necessary "bridge" in place, you have absolute stability between the device and its hub or bridge. The only hubs/bridge capable of offering that level of stability and performance that come to mind are Insteon, Lutron, and Xiaomi (and probably Konke too, but I don't have experience with that hub and know of no way to connect it to HE). These all rely on proprietary radio communications to achieve that.
From what I've read, the Aqara-Opple switches have a default binding to the coordinator (hub) but with groupcasting of messages to the all device group. I haven't seen any information anywhere on how to keep the binding to the coordinator and disable the groupcasting, just information on changing the binding to a specific end-device for point-to-point control without coordinator intervention.
Until I've read an explanation on how to disable the groupcasting feature of the switches, It makes no sense for me to work on a Hubitat driver.
See this post from a Zigbee2Mqtt GitHub comment thread that explains the issue.
Also, the folks that have gotten Xiaomi / Aqara devices working with the DeCONZ Rest Plug-in are very close to getting the Aqara-Opple switches working for them. See this (long!) thread for more details:
I have posted to ask for clarification, but I believe the solution to the groupcast issue is probably to make a "fake"/empty group owned by the coordinator (hub) that the switch's binding is assigned to (instead of the "all devices" group). and the solution to disable the broadcast messages that affect all bulbs / switches is to configure the Aqara-Opple button to create bindings from the On/Off and Level Control clusters to a specific ZigBee group. Then the coordinator would need to be set up look at the state of that group as a switch itself that can then be used to triggers for automations.
The problem is that this scenario is much like what is needed to get the IKEA 5-button "steering wheel" remote working on the Hubitat Hub, and that is never going to happen:
Original explanation from July 2018 of how the IKEA 5-button remote uses groupcast messages:
Declaration of no support for the IKEA 5-button remote in April 2019:
Since the Aqara-Opple switches only use groupcast messages seem to always send groupcast messages in addition to reports to the coordinator (hub), I am going to guess that they also will not work with the Hubitat Hub, and won't be supported.
@SmartHomePrimer integrating the Aqara HomeKit Gateway would be an interesting way of doing things, if someone starts to look at doing this I'd be interested in collaborating, I'm just not sure I would have the time for this type of thing by myself. The Aqara M2 Hub does look nice... As long as we get it off the cloud...
@veeceeoh Thank you for summarizing all available info on the subject, as always, you're THE source for this! Let us hope there is a way to sort this out... If there is no direct way, maybe a "hackish" way of using a CC2531 with a custom firmware to "translate" the group signal... It does look fun to write a driver for...
Agree fully with that. I wouldn't have added the Aqara hub to my network if it required a constant cloud connection. As it is today, the only requirement is for the Aqara Home app to contact their to Chinese server to join your WiFi. Why? 
I guess they want to log your WiFi credentials. But once connected, you can block their access and it will function via HomeKit locally.
I'm wondering then if it wouldn't be best to just implement a HomeKit Controller in Hubitat? Maybe there is something like that already in the works? A HomeKit Controller would be able to connect to the Aqara M2 Hub and many other HomeKit devices. There is support for using multiple HomeKit Controllers in the standard. Not sure if that is working with all devices though.
Personally I don't use Homekit devices connected to anything Apple. Even though most of our phones and tablets are Apple devices, but I do understand why many(most?) would not choose to do it this way.
EDIT: There is something like this for HomeAssistant, written in Python. That could be very interesting... Have anyone tried this?
I've gotten more clarification on how the Aqara-Opple button "switches" would need to be configured to work on a hub other than the Aqara gateway. And some input from Hubitat staff is needed to know if it could work in theory at all.
I decided to post about it on this thread which is titled with the device's name.
Download the Hubitat app
