Original & Aqara Xiaomi Zigbee Sensors (contact, temp, motion, button, outlet, leak, etc)

I’ve only seen it happen now and then. No idea how to change it, because as far as I have seen, it’s based on messages sent directly by the hardware.

WXKG03LM <— This one, right?

The wall surface-mounted Aqara Smart Light Switch model WXKG03LM can be used with the Aqara Button DH.

Sadly, the hardware only supports sending a button pressed message. There’s no multi-click or hold support.

Beware: The two-button Aqara Smart Light Switch model WXKG02LM does NOT work as two buttons with SmartThings. The technical reason for this is that the SmartThings ZigBee attribute report message parser strips out what is known as the endpoint number value. The two-button WXKG02LM model uses a different endpoint number for the left button press, right button press, and both-button press. The DH only receives all of those messages as coming from one button. Until SmartThings changes the way it handles ZigBee attribute reports with different endpoint numbers, the two button functionality of the WXKG02LM model will never work.

1 Like

what is the CATCHALL method ?

See my post here for the details.

Has anyone spoken to support to see if this is a bug or a ‘feature’ with the striping?

Hey guys, FYI the Xiaomi Zigbee Button handler as of v1.1 doesn’t actually work. Presses from the app tile work, but actual hardware presses don’t due to this line. buttonNumber should not be a String, removing the “” makes it all work correctly.

They are most definitely aware of it. Whether it’s a bug or feature depends on who you ask.

The suggested workaround is to send commands to Zigbee devices asking them to send reports that include the endpoint data, but this does not work with Xiaomi device because they do not accept any commands. They only send reports to the hub.

1 Like

[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:

2 Likes

Thanks for the bug report!

As luck would have it, a major update to v1.2 was ready to release today, after over a month of testing. The issue you identified is fixed in this new version.

1 Like

[UPDATE] Aqara 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

  • Compatible with the new Aqara Button model WXKG12LM, which offers single-click, double-click, hold, and shake functions (see table below)
  • Compatible with Aqara Smart Light Switch models WXKG02LM / WXKG03LM (with limitations, see Important Notes, below)
  • 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

Aqara Model WXKG12LM Functions Table

Button action Event sent to hub
single-click button 1 pushed
hold button 1 held
double-click button 2 pushed
shake button 3 pushed

Note: the hold function is hardware-based, activated after 400ms according to Xiaomi’s specifications - which cannot be changed

Important Notes

  • Limitation: The “original” Aqara model WXKG11LM, and both models of Aqara Smart Light Switch only support button pushed. There is NO possibility of adding a hold feature for these models.
  • Limitation: 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.
  • 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 (or shaken, for model WXKG12LM)
    lastReleasedCoRE - model WXKG12LM only updated when the button is physically released after being held
  • The device handler no longer sends button 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 “pushed” (or for model WXKG12LM, “single-clicked”, “double-clicked”, or “shaken”) lasts for about 1 second, and then will reset back to “released”. When model WXKG12LM’s button is held, the UI will display “held” until the button is physically released, but note that the button 1 held event is always sent after the button has been held for 400ms.
4 Likes

thanks for your feedback - maybe a stupid question - how can I select the correct catchall ? - i select the closest catchall, create a device named it and put the device network id on it.There after I found it under things - and I paired it.
But it was empty when I try to open it. I am quiet sure I am using the correct device handler -( bspranger : xiaomi temerature humidity senser – not the type Aqara ).
There after I was confused - there was a lot of " catchalls - did a select the correct ?

( but I believe if I had select a wrong catchall I would not be able to find it under things - or would I ? )

PLS give me some feedback and have patience with me

Thanks for the update @veeceeoh - also working great with my WXKG03LM’s, so you can add those to the compability list…
(still waiting for my WXKG12LM’s from China…) :crossed_fingers:

Just to avoid confusion - Shouldn’t this headline read WXKG12LM instead of WXKG11LM? :slight_smile:

// K

2 Likes

There can be other catchall messages listed in the hub events.

It should be similar to this:

09%20PM

Also, after pairing, there may be nothing displayed for the sensor in the SmartThings mobile app. It will only send reports when the temperature of humidity changes, and the first battery only comes about 1 hour after pairing.

So, after pairing, to check if you got the correct device Network ID, try blowing on the sensor to make it send temperature / humidity reports.

Yes, that was a mistake, and it’s fixed now - thanks!

I also noticed my direct link to the code was incorrect, and I listed the one-button Aqara Smart Wall Switch as model WXKG01LM, but it is actually model WXKG03LM, the same as you have - so yes that compatibility was intentional. :grin:

2 Likes

I have tested, and changing from C to F in the smartthings app will display the same color

Sensor 1:


Sensor 2:


I’m hoping this is something that we can leverage, if so will largely negate my need of a hubitat?

@veeceeoh can you break it down for us mortals?

Local processing for some devices & smart apps is old news, and doesn’t apply to Xiaomi devices. Looking at the FAQ page:

“Certain” means “not all”.

From everything I’ve read, the list of possible “supported devices” will only include “Works with SmartThings” ZigBee or Z-Wave devices, and ZigBee or Z-Wave devices with Device Handlers found in the official SmartThingsPublic GitHub Repository. In other words, devices with community-supplied DTHs are not considered “supported devices”.

With many firmware updates since sometime in 2016, the list of local-execution capable devices has grown. For example, with the 21.12 v2 Hub Firmware update being released today, 9 more DTHs now have local execution support. Those DTHs are on the v2 hub’s pre-installed list of DTHs.

So unless there is a huge change in their policy with the upcoming platform update, Xiaomi devices will continue to run on cloud processing.

Also worth remembering is that the functionality of some Xiaomi devices is limited because SmartThings ZigBee API ignores certain Zigbee message data (specifically endpoint data). This issue affects the round “original” Xiaomi Button, Aqara Button model WXKG11LM, and the dual-button Aqara Smart Wall Switch (model WXKG02LM).

On the Hubitat Hub all Xiaomi device drivers’ code is executed locally, and all functions are available. But of course, some people are still having pairing / dropped connection / repeater issues with some Xiaomi devices, just like with SmartThings, so I can’t say they work perfectly with Hubitat, either.

3 Likes

cho hỏi đã fix được lỗi disconnect chưa thế? mình cũng dùng samsung connect home và cũng dính sau khoảng 1h là lỗi.

Mình cũng ko rõ vì cất xó cái connect home rồi :))

I lived in Hanoi for 9 years and know cất means “put away”. So did you stop using your Samsung Connect Home?

Yes, I bought a 2nd gen hub a few months ago and it’s been working really well, so I put my Connect home away :). Unless they decide to update its firmware, there’s no way for xiaomi devices to stay connect with it, I guess :frowning: