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

[kayvint]

Is the version you working on, is that the Version 1.2? Just updated the device handler to that version and will give that a go.

[veeceeoh (Keith G)]

@kayvint

Is the version you working on, is that the Version 1.2? Just updated the device handler to that version and will give that a go.

Yes, that’s right. The GitHub comments thread on the link I gave has all my notes about the changes I made.

[cscheiene]

Great work guys!

The only thing I dont like is that the color on the temperature tiles are inconsistent from all the other devices I use. (Fibaro, Aeon multisensor, Netatmo etc)

Here is an example of the code used for other devices:

		backgroundColors:[
			[value: 31, color: "#153591"],
			[value: 44, color: "#1e9cbb"],
			[value: 59, color: "#90d2a7"],
			[value: 74, color: "#44b621"],
			[value: 84, color: "#f1d801"],
			[value: 95, color: "#d04e00"],
			[value: 96, color: "#bc2323"]
		]
	}

For me this seems to be the standard on all the official smartthings DTH, and the color will stay the same even if you switch between F and C

[veeceeoh (Keith G)]

@cscheiene

For me this seems to be the standard on all the official smartthings DTH, and the color will stay the same even if you switch between F and C

The color set to represent temperature display in the two Xioami Temp/Humidity sensor device handlers was derived directly from the SmartThing’s Developer Documentation’s Color Standards.

In that section of the documentation they link to an example Device Handler which accommodates both Celsius and Fahrenheit values:

The link is to the Ecobee Thermostat device handler code, and you’ll see the set of values is nearly the same - I think the Celsius values section of the color mapping for the Xiaomi DTHs were lowered a bit.

@cscheiene

the color will stay the same even if you switch between F and C

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.

[gfbuyer]

I am getting duplicate notifications for each open and clsoe of one of these contact sensors. Anyone else see this behavior or know how to stop it ?

[Stiand]

I am thinking of buying the square button (WXKG03LM) as this looks rather nice. Does this work with any of the DH’s? See that its mentioned the other type only (WXKG11LM)…

Another question is also whether it works dimming lights with this switch? E.g. by holding button for dimming?

[veeceeoh (Keith G)]

@gfbuyer

I am getting duplicate notifications for each open and clsoe of one of these contact sensors. Anyone else see this behavior or know how to stop it ?

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.

@Stiand

I am thinking of buying the square button (WXKG03LM) as this looks rather nice. Does this work with any of the DH’s? See that its mentioned the other type only (WXKG11LM)…

Another question is also whether it works dimming lights with this switch? E.g. by holding button for dimming?

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

[toch]

what is the CATCHALL method ?

[veeceeoh (Keith G)]

@toch

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

@CultusMechanicus

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?

@veeceeoh

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

@toch

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]

@veeceeoh

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: