[RELEASE] Xiaomi Aqara Mijia Sensors and Switches Driver

thank you @chirpy
I can now use the WXKG01LM with the button controller app for the various tap actions.

One more thing I noticed from the logs is that you can actually see different data if the button is pressed 5 times, so for someone in the future the button might serve a 6th action that it can trigger.

I'm attaching the logs for pressing the button 1,2,3,4,5 times and holding it so you can see what I mean.
The other things that might be nice to do to clean up the WXKG01LM is to configure it so that it doesn't report that it can support pressed, held, double tapped, released on all 5 buttons, but that's me being picky, it's no big deal with the way it is.

Personally I'm happy with the current version

Logs

dev:1902021-02-12 13:26:58.928 infoOffice Button was released

dev:1902021-02-12 13:26:58.909 infoOffice Button contact changed to open

dev:1902021-02-12 13:26:58.904 debugProcessing Xigbee data (cluster:0006, attrId:0000)

dev:1902021-02-12 13:26:58.898 debugIncoming data from device : read attr - raw: A7C90100060800001001, dni: A7C9, endpoint: 01, cluster: 0006, size: 08, attrId: 0000, encoding: 10, command: 0A, value: 01

dev:1902021-02-12 13:26:56.103 infoOffice Button button 5 was pushed

dev:1902021-02-12 13:26:55.554 infoOffice Button contact changed to closed

dev:1902021-02-12 13:26:55.549 debugProcessing Xigbee data (cluster:0006, attrId:0000)

dev:1902021-02-12 13:26:55.541 debugIncoming data from device : read attr - raw: A7C90100060800001000, dni: A7C9, endpoint: 01, cluster: 0006, size: 08, attrId: 0000, encoding: 10, command: 0A, value: 00

dev:1792021-02-12 13:26:47.700 infoSending temperature event (Temperature: 24.0 °C)

dev:1902021-02-12 13:26:37.424 infoOffice Button button 4 was pushed

dev:1902021-02-12 13:26:37.418 debugProcessing Xigbee data (cluster:0006, attrId:8000)

dev:1902021-02-12 13:26:37.412 debugIncoming data from device : read attr - raw: A7C90100060800802080, dni: A7C9, endpoint: 01, cluster: 0006, size: 08, attrId: 8000, encoding: 20, command: 0A, value: 80

dev:1902021-02-12 13:26:32.876 infoOffice Button button 4 was pushed

dev:1902021-02-12 13:26:32.871 debugProcessing Xigbee data (cluster:0006, attrId:8000)

dev:1902021-02-12 13:26:32.865 debugIncoming data from device : read attr - raw: A7C90100060800802004, dni: A7C9, endpoint: 01, cluster: 0006, size: 08, attrId: 8000, encoding: 20, command: 0A, value: 04

dev:1902021-02-12 13:26:29.448 infoOffice Button button 3 was pushed

dev:1902021-02-12 13:26:29.443 debugProcessing Xigbee data (cluster:0006, attrId:8000)

dev:1902021-02-12 13:26:29.434 debugIncoming data from device : read attr - raw: A7C90100060800802003, dni: A7C9, endpoint: 01, cluster: 0006, size: 08, attrId: 8000, encoding: 20, command: 0A, value: 03

dev:1902021-02-12 13:26:26.311 infoOffice Button button 2 was pushed

dev:1902021-02-12 13:26:26.306 debugProcessing Xigbee data (cluster:0006, attrId:8000)

dev:1902021-02-12 13:26:26.300 debugIncoming data from device : read attr - raw: A7C90100060800802002, dni: A7C9, endpoint: 01, cluster: 0006, size: 08, attrId: 8000, encoding: 20, command: 0A, value: 02

dev:1902021-02-12 13:26:23.827 infoOffice Button button 1 was pushed

dev:1902021-02-12 13:26:23.807 infoOffice Button contact changed to open

dev:1902021-02-12 13:26:23.802 debugProcessing Xigbee data (cluster:0006, attrId:0000)

dev:1902021-02-12 13:26:23.797 debugIncoming data from device : read attr - raw: A7C90100060800001001, dni: A7C9, endpoint: 01, cluster: 0006, size: 08, attrId: 0000, encoding: 10, command: 0A, value: 01

dev:1902021-02-12 13:26:23.632 infoOffice Button contact changed to closed

dev:1902021-02-12 13:26:23.627 debugProcessing Xigbee data (cluster:0006, attrId:0000)

dev:1902021-02-12 13:26:23.621 debugIncoming data from device : read attr - raw: A7C90100060800001000, dni: A7C9, endpoint: 01, cluster: 0006, size: 08, attrId: 0000, encoding: 10, command: 0A, value: 00

--- Live Log Started, waiting for events ---

Thanks very much

1 Like

hey @chirpy any idea of the vibration sensors can be used with HSM? Or if not what capabilities does the driver expose for the vibration sensor?

Having moved from ST I have discovered that my ST multipurpose sensors which report as acceleration sensors (amongst other things) are not supported by HSM, so I'm wondering if these cheap vibration sensors from Xiaomi would be supported. Don't want to buy some wait 2 months and then find out that I wasted some money on them

I'm afraid that I have no idea as I don't use HSM. You could try asking in a new thread to see if there are people who do.

I need to understand before I do open up a thread what capability does the vibration sensor trigger? Is it an acceleration trigger? Or motion? Or perhaps a shock?

As it's a combined driver I don't think I can just set up a virtual device with the driver as I imagine the capabilities would depend on actual data received from a sensor.

Thanks chirpy

The vibration sensor driver section exposes the following attributes (this is for an inactive one):

  • acceleration : inactive
  • battery : 100
  • motion : inactive
  • presence : present
  • temperature : 22.0
  • tilt : inactive
  • voltage : 3.06
2 Likes

Is it possible to set the properties of a device to actually reflect its capabilities?

I have an Aqara temperature sensor which has these states:
aqara_temperature_states_

The device properties show as:

Note that the properties: motion, measure-illuminance, contact, button, acceleration and measure-water are all shown but not supported by this specific device.

This is an issue for me as I am publishing the device via @kevin 's MQTT App and using the properties to determine the device's capabilities in Indigo. So I am not getting an accurate picture of the device's capabilities.

is it possible to correct this? :slight_smile:

1 Like

@autolog It's likely me populating that properties data value. It is interesting that say temperature matches a measure-temperature property in terms of a change being discussed for an upcoming release of the MQTT app.

Down to me I think.. these property values carry over to MQTT $properties I assume ?

It's also likely the nature of the combined driver, as this is. The device capabilities apply to all devices, though only the ones supported have attributes set. I came across a similar issue with developing an Alexa/Google device using Raspberries and the Maker API. In the end I had to use the device attributes rather than capabilities.

1 Like

Hi @chirpy, Im getting this error in my logs for aqara wirelless switch:
2021-02-20 19:43:05.101 [error](http://192.168.1.30/device/edit/277)groovy.lang.MissingMethodException: No signature of method: user_driver_waytotheweb_Xiaomi_Aqara_Mijia_Sensors_and_Switches_579.checkEventInterval() is applicable for argument types: () values: [] (checkEventInterval)

And this for Xiaomi button:
[dev:361](http://192.168.1.30/logs#dev361)2021-02-20 20:24:59.872 [error](http://192.168.1.30/device/edit/361)java.lang.NullPointerException: null (parse)

Any hint what can be wrong?

Make sure you have clicked the "Configure" button in the device details. That error suggests that you've switched from a different driver that had old scheduled tasks that pressing Configure should resolve.

Thank you, that solved the problem :smiley:

Hi @kevin - Should I file an issue on Github for this or are you tracking it? :slight_smile:

@chirpy, do you have a command list for these products?
kinda off topic, but using Aqara wall switches...
i have the 2 button wall switch (wired): lumi.switch.b2naus01
and im hoping there is a command to disconnect(disable) the physical buttons from changing the release... aka a child lockout in my case
maybe its not supported... how can i find out (ideally with documentation of commands from manufacturer)

thanks
mitch

Unfortunately, Xiaomi do not document anything. It's all done through reverse engineering. There seem to be only a few switches that allow you to disable the physical relay in the switch and I've no idea if this is one.

1 Like

@chirpy, I thought my previous driver updated the state of the sensor on the hourly check-in. Incase of a "missed" status change the state was corrected after max 1 hour,
Does you driver has that same functionality?

There's nothing in the driver to do that. I've never seen a missed status change for any of these devices.

It rarely happens to me, but the reason for the question was because the problem occurred today on a contact sensor....

Thinking about it, there's actually nothing the driver can do as it is not possible to interrogate these devices. The driver has to wait until the device itself actually sends the data.

1 Like

Yes, that was what I mentioned above, at the hourly check-in of the device. If the status info comes on the hourly check in moment, why not overwrite? If a status was missed, the problem is solved at the next check-in moment...

What I’ve written below may not be relevant to Hubitat, but it is what I’ve observed with Aqara contact sensors reporting under zigbee2mqtt.

There is no hourly check-in. Check-in can occur even 3-5 hours later. And contact status is not always reported. Sometimes temperature or battery are the only things reported by the Aqara contact sensor.

2 Likes