The error happens when I press the button.
The buttons didn’t work.
I just tried the 12LM driver and it works fine with that driver. I have triple checked the back side of the buttons and they say 11LM…
That is very odd.
Do you get all of the functions of the 12LM? I think the easiest one to check for would be the accelerometer. Take a look at the device page and log output while you shake the button!
If you get an "active" reading on the accelerometer and button 6 is "pressed" then you've got a 12LM in an 11LM case. Or... somebody has put the wrong battery cover on. 
No, I do not get any other functionality than button 1. I tried shaking the device but no accelerometer showing up in the device tab or in the log.
Last quiz questions! 
- What is shown as the model in the Data section of the Device page?
- Is the device recently purchased, or recently added and removed from a Xiaomi hub?
Models for me '11LM being "lumi.sensor_switch.aq2" and '12LMs are "lumi.sensor_swit".
Second question is pondering whether there's been new firmware released.
All 4 buttons show:
- model: lumi.remote.b1acn01
- physicalButtons: 1
- application: 02
- driver: v1.0.1.1123
- manufacturer: LUMI
I have had the buttons for about two years and they have never been paired to a Aqaba/Xiaomi, don’t own one.
Ah, well, would you look at that.
Known about in the veeceeoh drivers, I must have some earlier revision units here.
Keep using the '12LM driver for now and let me know of any errors. I may try to merge the two drivers, there should be enough which is similar, the real trick is that the driver may end up presenting features which aren't available on all units, which is always a source of frustration when configuring behaviours and automation. If I can work around that then I may well do it.
Looks like my model names are being truncated somewhere too.
2 Likes
I switched to the veeceeoh drivers for my new revision of the 11LM. I can send you the “send to dev” strings for all the events from your driver if you want. They seem pretty straightforward and I was going to submit a PR to your driver until you pointed me to the veeeceeoh ones. =p
1 Like
Hold doesn't seem to work. Push and double tap work as it should though.
@birdslikewires Do you think it’s possible to get Hold working on my 11LM buttons using the 12LM driver?
If it’s sending the right messages, yes. Can you turn on the debug and trace logs, press and hold and send the log output here?
Someone on here once said that they were still waiting for the 36 hour days they'd ordered from Amazon to arrive. I think my order is also still outstanding.
There's an updated version of the WXKG12LM driver which now contains support for the WXKG11LM. It's pointless maintaining them separately now given the r2 has the hold and release function; the reason to keep them separate was to avoid presenting functionality that the device didn't support, but if that now involves maintaining three almost identical drivers then my principles can go jump.
To try this out, first make sure you are running HPM v1.8.7. Then check for updates and install the WXKG12LM update. If you've installed manually you will now need to add my library code like this:
- Download library.zip
- Install using Developer Tools > Bundles > Import ZIP
Then you can update the WXKG12LM code to v1.04.
Clearly I don't have a WXKG11LMr2 to test with, so please check that the hold, release and level values are being updated as expected.
2 Likes
Everything has been updated to amalgamate the '11LM and '12LM wireless mini switch drivers now.
If you're using the WXKG11LM driver please update and switch your driver to the "Xiaomi Aqara Wireless Mini Switch WXKG11LM / WXKG12LM" one when convenient.
No resets or configuration button presses required, it'll just keep on going.
Hold works after the update. Thank you very much for implementing that into the driver!
1 Like
Good stuff!
Actually seems as though there's a firmware bug in the ones I have too, which makes them report their model as lumi.sensor_swit instead of lumi.sensor_switch.aq3. Suspiciously the truncated version is exactly 16 characters.
I had thought this was somehow my fault, but the model name is read by Hubitat and the raw Zigbee frame only contains lumi.sensor_swit as 6c 75 6d 69 2e 73 65 6e 73 6f 72 5f 73 77 69 74. So this one's not on me.
Instead, the driver just catches the shortened name as well as the full length. Matching works fine.
Ever seen this error it comes right after that Warning "tell the developer" you once told us to ignore. If this looks like something related to link failure back to the hub (like a broken path due to errant repeating) that might fit a situation I'm cleaning up after...otherwise it might be something that's been there that I just now noticed.
Thanks
Received : endpoint: null, cluster: null, clusterId: 0006, attrId: null, command: 00 with value: null and 9 bits of data: [D4, FD, FF, 04, 01, 01, 19, 00, 00]
I've seen this before, it's a ZigBee Device Object (ZDO) match descriptor request and according to the ZigBee Cluster Library Specification the command is used to discover an upgrade server, if I'm reading it correctly.
Driver updated to gracefully skip the messages and use the new library code bundle.
4 Likes
OK, so... that is the device saying "hey, any new firmware for me out there on a compatible hub"
and this likely came up when I took the battery out/in to shake the device into taking a new repeater path.
Just checked....it doesn't give up.....that msg is still popping up this morning. Gotta upgrade the driver.
And now I'm thinkin,
"hey, i've seen an option switch on some driver screens for ZDO and had no clue", sooo need to look how those are set.
