[OBSOLETE] Xiaomi Sensors and Button (beta)

[veeceeoh (Keith G)]

@Gert_Koolwijk

Sorry for responing a bit late on your question. I currently have 3 model WXKG11LM buttons. Recently I ordered a new 12LM version. Have read somewhere it might be a hardware issue.

It’s not a hardware issue. The Aqara button model WXKG11LM simply doesn’t provide any way in the hardware to implement a hold function. However, the Aqara model WXKG12LM does support it. If you look at the header information section of the Aqara Button device handler code, there is a detailed explanation of the capabilities of each model when used in SmartThings:

Notes on capabilities of the different models:
Models WXKG11LM, WXKG02LM, WXKG03LM

• Only single press is supported, sent as button 1 “pushed” event
• The 2-button Aqara Smart Light Switch model WXKG02LM is only recognized as ONE button.
  This is because the SmartThings API ignores the data that distinguishes between left, right, or both-button presses.

Model WXKG12LM

• Single click results in button 1 pushed event
• Hold for longer than 400ms results in button 1 held event
• Double click results in button 2 pushed event
• Shaking the button results in button 3 pushed event
• Single or double click results in custom lastPressedCoRE event for webCoRE use
• Release of button results in lastReleasedCoRE event for webCoRE use

For more information, see my announcement post about v1.2 of the Aqara Button device handler here.

---

@siwilson

I have 2 of the G01LM buttons and I am using the original A4refillpad DTH. If I switch to the newer BSpranger DTH I lose the held function.

Which version of the bspranger DTH are you using?

Version 1.2, which I worked on and was extensively tested, does have button hold function, and improves on it. It was announced on the Original & Aqara Xiaomi Zigbee Sensors (contact, temp, motion, button, outlet, leak, etc…. thread four weeks ago:

[UPDATE] “original” Xiaomi Button device hander to v1.2

Available immediately on the bspranger/Xiaomi GitHub repository. The updated code can be copied from this direct link.

New features

• Button hold, which can set in preferences to send either a button 1 held or button 2 pushed event
• Button status correctly displayed in main tile of mobile app UI, with a new custom icon
• Live logging preference settings, with toggles for display of info (“plain” English) and/or debug (technical) log messages. As a default, info log messages are displayed.
• Improved webCoRE support

Important Notes

• The minimum time required for held can be changed in the preference settings. The default based on extensive beta testing is 2.0 seconds, and decimal values are allowed. Note that shorter times may result in greatly reduced reliability (see note about SmartThings cloud execution limitations, below)
• webCoRE users can make use of a number of custom attributes, some of which have been renamed from the previous version of the device handler:
  • lastCheckinCoRE - updated on every single message received from the button
  • lastPressedCoRE - updated when the button is physically pressed
  • lastReleasedCoRE - updated when the button is physically released
  • lastButtonMssg - updated every time the button is either physically pressed or released
• Because the button held feature is not hardware-based, no events are sent until the button is physically released. This means that even if the minimum time to held setting is 2 seconds, if you hold the button for 10 seconds, the held event is sent at the 10 second point, not 2 seconds after the press started.
• The device handler no longer sends button 1 released events. This is because SmartThings’ button capability only supports pushed and held events.
• The toggle mode option has been removed, because SmartThings’ button capability doesn’t support button released events and also because most Smart Apps that work with buttons offer a toggle switch option already.
• The SmartThings app UI display of button “pushed” or “held” event lasts for about 1 second, and then will reset back to “released”.
• Limitation of cloud execution: During beta testing, I and the beta testers found the accuracy of the device handler registering pushed versus held correctly to be well over 90%, as long as the minimum held time was not too short. The problem is that because the code is “cloud” executed every time a message is received from the button, sometimes the delays result in the release message being processed before the pressed message. The device handler decides whether a long press is a hold by comparing the press start time and release time, so if there are delays in the code execution, then even though you may hold the button long enough, the calculated time difference could be too short. There is really nothing that can be done to fix this other than physically holding the button for a longer time to compensate. However, I have made changes to the method used in the original a4refillpad device handler that improves on the level of reliability.

Screenshots: