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

[toch]

what is the CATCHALL method ?

[veeceeoh (Keith G)]

what is the CATCHALL method ?

See my post here for the details.

[Behold81 (Antony Pugh)]

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

[CultusMechanicus]

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.

[veeceeoh (Keith G)]

@Behold81

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

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

The state of ZigBee with attribute reporting

ZigBee attribute reporting is a great feature. It basically allows for “push” messages from devices when their state has changed. This eliminates the need for polling, reduces traffic on the network, and keeps SmartThings instantly in sync. I’ve been hitting various roadblocks in this endeavor and I thought I’d document them in this thread. Feel free to add your own observations. First up are the SmartThings devices. In nearly all the device type templates I’ve looked at, there is a bug in the report configuration. For example here’s a snip of the Cree device type: def configure() { log.debug "Configuring Reporting and Bindings." def configCmds = [ //Switch Reporting "zcl global send-me-a-report 6 0 0x10 0 3600 {01}", "delay 500", "send 0x${device.deviceNetwork…

Zigbee Receive Report Attribute from multi-endpoint

Hi community, I am new to Smartthings and now I’m trying to write Device Type Handler for my Zigbee Switch Devices. Here is my switches http://www.lumi.com.vn/Elite-Version-pd-4. In each physical switch plate, they have from 1-4 buttons to control on/off device. They have multi endpoint, each one associate with one button. I have write my Device Type Handler for them and Smartthings now can regconize and control them. My problem is when those swiches send Report Attribute to Smartthings, as I debug on IDE, the description received in parse function is just ‘on/off: 0’ or ‘on/off: 1’. There is no additional information like the source end point, so I can not decide where this Report come from and update status of right button. So anyone know how to overcome this problem? Thanks

ZigBee Temperature reporting question for Cluster 0x402

I’m working on a new device driver for a ZigBee thermometer that has two temperature probes (one for inside and the other for outside). Each probe is on a unique end-point. Everything works as expected as far as querying the attributes of each end point and getting that probe’s temperature. All is good there. However, when I configure the device to report its attributes to the hub it does so for each end point but what is delivered to the parse method is a string with the word “temperature” and the value, not the “catchall” string. I have no clue what end point this came from so I cant associate it with the correct probe. Is there a way I can find the source end point for this reported temperature?

Zigbee reporting, multiple endpoint same cluster

Hi, Im working on a DTH for an in wall switch with two inputs and two outputs. Trying to figure out how to set up the reporting for on/off: 0x0006 cluster. The outputs can be found on endpoint 1 and 2. I have setup the reporting like this: configCmds += zigbee.configureReporting(0x0006, 0x0000, 0x10, 0, 300, null, [destEndpoint: 0x01]) + zigbee.configureReporting(0x0006, 0x0000, 0x10, 0, 300, null, [destEndpoint: 0x02]) I can see in the logs that the reporting have been setup successfully: 903c7fa1-fff6-412f-9826-c97d7faa7636 14:58:39: debug On/Off reporting successful 903c7fa1-fff6-412f-9826-c97d7faa7636 14:58:39: trace parse: map is [raw:0104 0006 01 01 0140 00 8DDB 00 00 0000 07 01 00, profileId:0104, clusterId:0006, sourceEndpoint:01, destinationEndpoint:01, opti…

ZigBee Abstraction Documentation!

On the multiple endpoint front, we released the ability to fingerprint on any endpoint that I mentioned earlier, plus we’ve added the ability to send commands like zigbee.readAttribute and zigbee.command to different endpoints. That was possible before with the legacy st rattr and st cmd commands but not with the zigbee.* commands. We also added the ability to send manufacturer specific commands to different endpoints which previously wasn’t possible, even with use of the legacy raw command. As for including the endpoint in the attribute reports, it’s a lot more complicated to implement without breaking backwards compatibility so it’s not something we’ve made much progress on yet.

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.

[veeceeoh (Keith G)]

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

[veeceeoh (Keith G)]

Hey guys, FYI the Xiaomi Zigbee Button handler as of v1.1 doesn’t actually work.

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.

[veeceeoh (Keith G)]

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

[toch]

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

[AnubizDK (Kenneth Eriksen)]

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…)

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

Aqara Model WXKG11LM 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

// K

[veeceeoh (Keith G)]

There after I was confused - there was a lot of " catchalls - did a select the correct ?

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

It should be similar to this:

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.

[veeceeoh (Keith G)]

@AnubizDK

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

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.

[cscheiene]

I have not seen this behavior, but certainly I can try the Fahrenheit-centric color set you quoted (same as on the ST Dev Docs) again and report my findings with screenshots back here.

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

Sensor 1:

Sensor 2:

[foz333]

Local processing

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?

[veeceeoh (Keith G)]

@foz333

@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.

[Duy_Hoang (Duy Hoàng)]

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.

[mieomeo (Tran Duc)]

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

[veeceeoh (Keith G)]

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?

[mieomeo (Tran Duc)]

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

[Duy_Hoang (Duy Hoàng)]

can you help me fix samsung connect home disconnect xiaomi sensor?