[Release] Xiaomi / Aqara device drivers

community_driver

#706

I bought this one. The "Original" Xiaomi


#707

I don't use any of my motion sensors with HSM personally, but I can try it when I get home from work.

In the meanwhile, I'm wondering how it's not working for you. I connected to my hub remotely and can add my Aqara Motion Sensors to any/all of the intrusion device lists, no problem. Also, when used with Rule Machine or other automation apps they work fine, meaning the events are being generated correctly, which is what HSM would use.

Note that the same driver is used for both models of the motion sensor, with everything working identically except the addition of lux value reports from the Aqara model. So which model you're using has nothing to do with any issues with HSM. It's something else.


#708

Sorry I should have been more specific. For example, I can get lights to turn on/off on motion status, but I cannot get HSM to trigger an alert when armed away. It works for my doors when I open them and is armed away.


#709

I got the newer version with light sensor for 12.48. I also have the original version and it works fine too


#710

How is the light sensor working for you?


#711

So I'm not sure what happen. but i turned on logging and it all started to report HSM alerts.


#712

Works well, seems the illuminance range is 0 - 100, and it is responsive. I can turn on the lights but only if illuminance is low as a condition.


#713

Can you look into supporting the " Mijia Honeywell Natural Gas Alarm Detector"

Also I do not see battery level for the Contact or temp sensors.


#714

I'd recommend having a look a my detailed post regarding the lux sensor of the Aqara Motion Sensor.

Here's a choice TL;DR quote:

However, as with all things Home Automation, YMMV.



Model JTQJ-BF-01LM/BW, correct?

I have looked into it, but because I would need to own one to correctly develop and test a driver, I have no plans to develop a Hubitat integration.

If you don't mind purchasing a Xiaomi Gateway hub and a server (Synology NAS, Raspberry Pi, or Linux Server) to run a Docker image, then this solution will allow you to integrate a Xiaomi Gas Sensor that is connected to the Xiaomi Gateway:

Do you own one? I could attempt to write a driver based on the one for the Smoke Detector. I just can't make any promises because I would need to ask for a lot of testing and reporting of log output from a user who owns the gas sensor.


#715

I don't have one yet but wanted to order 2 of them. Do you live in the USA?


#716

Yes, in Oregon.


#717

Ok my order shows up (about 1 month) I will get with you send you one of them to make the driver?


#718

@veeceeoh Keith,

I'm having issues changing the sensitivity on the Vibration sensor. In the past, I set it to HIGH so I know the process works. I'm using technique #2 (sensitivity switch on, push medium button, short press the device).

Here's my log:

The battery level report is from successive short presses, so it seems to be seeing the press. But no indication in the device page that the sensitivity level has actually changed. Any ideas?


#719

Sounds good, thank you.



A few things to check first:

  1. Are you using the current release Hub firmware and not a beta?
  2. Timing between sending the request to change the sensitivity level and short-pressing the reset button may be important. Have you managed to do that sequence in 10 or less seconds?
  3. Is it possible you already had the sensitivity level set to Medium? I am not home to test it, but it's possible subsequent requests to change to the level that is currently set may be ignored.

Aside from those things, I can say that the battery voltage message is separate from the message that confirms the change in sensitivity level, and in my testing I did see instances of the request not working or being ignored.

If you could turn on debug message logging and post log output from attempts to change the level, that will help to see whether that confirmation message is being received and ignored by the driver for some reason.


#720

Hi @veeceeoh,

I've started having issues all my Xiaomi devices since updating to 2.0.9.129.
One by one they started dropping on the same day of the update.

When re-pairing, I'm seeing errors. Below is an Xiaomi original contact.

dev:42162019-05-02 07:32:46.689 pm debugLounge Window Left: Creating event [name:contact, value:closed, isStateChange:true, descriptionText:Contact was closed]
dev:42162019-05-02 07:32:46.685 pm infoLounge Window Left: Contact was closed
dev:42162019-05-02 07:32:46.680 pm debugLounge Window Left: Setting lastClosed to current date/time for webCoRE
dev:42162019-05-02 07:32:46.659 pm debugLounge Window Left: Message payload: 00
dev:42162019-05-02 07:32:46.655 pm debugLounge Window Left: Parsing message: read attr - raw: 2EDA0100060800001000, dni: 2EDA, endpoint: 01, cluster: 0006, size: 08, attrId: 0000, encoding: 10, command: 0A, value: 00
dev:42162019-05-02 07:29:47.930 pm debugLounge Window Left: Creating event [name:battery, value:99, unit:%, isStateChange:true, descriptionText:Battery level is 99% (2.995 Volts)]
dev:42162019-05-02 07:29:47.927 pm infoLounge Window Left: Battery level is 99% (2.995 Volts)
dev:42162019-05-02 07:29:47.925 pm infoLounge Window Left: Battery level is 99% (2.995 Volts)
dev:42162019-05-02 07:29:47.923 pm debugLounge Window Left: Battery parse string = 0600100121B30B21A8012400000000002195002056
dev:42162019-05-02 07:29:47.921 pm debugLounge Window Left: Message payload: 0600100121B30B21A8012400000000002195002056
dev:42162019-05-02 07:29:47.918 pm debugLounge Window Left: Parsing message: read attr - raw: 2EDA0100003002FF4C0600100121B30B21A8012400000000002195002056, dni: 2EDA, endpoint: 01, cluster: 0000, size: 30, attrId: FF02, encoding: 4C, command: 0A, value: 0600100121B30B21A8012400000000002195002056
dev:42162019-05-02 07:29:47.915 pm debugLounge Window Left: Unable to parse message
dev:42162019-05-02 07:29:47.913 pm debugLounge Window Left: Message payload: 0A
dev:42162019-05-02 07:29:47.911 pm debugLounge Window Left: Parsing message: read attr - raw: 2EDA010000080100200A, dni: 2EDA, endpoint: 01, cluster: 0000, size: 08, attrId: 0001, encoding: 20, command: 0A, value: 0A
dev:42162019-05-02 07:29:47.905 pm debugLounge Window Left: Data type of payload is little-endian; reversing byte order
dev:42162019-05-02 07:29:47.880 pm debugLounge Window Left: Reset button was short-pressed
dev:42162019-05-02 07:29:47.878 pm debugLounge Window Left: Message payload: 126C756D692E73656E736F725F6D61676E6574
dev:42162019-05-02 07:29:47.875 pm debugLounge Window Left: Parsing message: read attr - raw: 2EDA0100002C050042126C756D692E73656E736F725F6D61676E6574, dni: 2EDA, endpoint: 01, cluster: 0000, size: 2C, attrId: 0005, encoding: 42, command: 0A, value: 126C756D692E73656E736F725F6D61676E6574
dev:42162019-05-02 07:29:47.739 pm errorjava.lang.NullPointerException: null (parse)
dev:42162019-05-02 07:29:46.949 pm infoLounge Window Left: Configuring
dev:42162019-05-02 07:29:34.936 pm debugLounge Window Left: Reset button was short-pressed
dev:42162019-05-02 07:29:34.932 pm debugLounge Window Left: Message payload: 126C756D692E73656E736F725F6D61676E6574
dev:42162019-05-02 07:29:34.930 pm debugLounge Window Left: Parsing message: read attr - raw: A7070100002C050042126C756D692E73656E736F725F6D61676E6574, dni: A707, endpoint: 01, cluster: 0000, size: 2C, attrId: 0005, encoding: 42, command: 0A, value: 126C756D692E73656E736F725F6D61676E6574
dev:42162019-05-02 07:29:29.712 pm debugLounge Window Left: Reset button was short-pressed
dev:42162019-05-02 07:29:29.708 pm debugLounge Window Left: Message payload: 126C756D692E73656E736F725F6D61676E6574
dev:42162019-05-02 07:29:29.704 pm debugLounge Window Left: Parsing message: read attr - raw: A7070100002C050042126C756D692E73656E736F725F6D61676E6574, dni: A707, endpoint: 01, cluster: 0000, size: 2C, attrId: 0005, encoding: 42, command: 0A, value: 126C756D692E73656E736F725F6D61676E6574
dev:42162019-05-02 07:29:26.928 pm debugLounge Window Left: Unable to parse message
dev:42162019-05-02 07:29:26.927 pm debugLounge Window Left: Message payload: 0A
dev:42162019-05-02 07:29:26.925 pm debugLounge Window Left: Parsing message: read attr - raw: A707010000080100200A, dni: A707, endpoint: 01, cluster: 0000, size: 08, attrId: 0001, encoding: 20, command: 0A, value: 0A
dev:42162019-05-02 07:29:26.923 pm debugLounge Window Left: Creating event [name:battery, value:99, unit:%, isStateChange:true, descriptionText:Battery level is 99% (2.995 Volts)]
dev:42162019-05-02 07:29:26.905 pm infoLounge Window Left: Battery level is 99% (2.995 Volts)
dev:42162019-05-02 07:29:26.901 pm infoLounge Window Left: Battery level is 99% (2.995 Volts)
dev:42162019-05-02 07:29:26.900 pm debugLounge Window Left: Battery parse string = 0600100121B30B21A8012400000000002195002057
dev:42162019-05-02 07:29:26.898 pm debugLounge Window Left: Reset button was short-pressed
dev:42162019-05-02 07:29:26.896 pm debugLounge Window Left: Message payload: 126C756D692E73656E736F725F6D61676E6574
dev:42162019-05-02 07:29:26.895 pm debugLounge Window Left: Message payload: 0600100121B30B21A8012400000000002195002057
dev:42162019-05-02 07:29:26.886 pm debugLounge Window Left: Parsing message: read attr - raw: A7070100002C050042126C756D692E73656E736F725F6D61676E6574, dni: A707, endpoint: 01, cluster: 0000, size: 2C, attrId: 0005, encoding: 42, command: 0A, value: 126C756D692E73656E736F725F6D61676E6574
dev:42162019-05-02 07:29:26.884 pm debugLounge Window Left: Parsing message: read attr - raw: A7070100003002FF4C0600100121B30B21A8012400000000002195002057, dni: A707, endpoint: 01, cluster: 0000, size: 30, attrId: FF02, encoding: 4C, command: 0A, value: 0600100121B30B21A8012400000000002195002057
dev:42162019-05-02 07:29:26.882 pm debugLounge Window Left: Data type of payload is little-endian; reversing byte order
dev:42162019-05-02 07:29:26.726 pm errorjava.lang.NullPointerException: Cannot invoke method getAt() on null object on line 71 (parse)

Logs were caught right from the searching on 2.0.9.132. What I see is that they will pair, but then not report afterwards, so after a while they just drop off again.

Any help would be appreciated

Cheers
Roy


#721

I've just checked 4 of my many Xiaomi sensors and 1 had dropped off, It paired again out but gave this error.


#722

I have not updated to Hub version 2.0.9.xxx yet, and I am not part of the beta group, so I am completely unaware of any reasons why Xiaomi / Aqara devices dropping their connection.

What I can tell you with certainty is that in the case of Xiaomi / Aqara devices, dropped connections have nothing to do with the device drivers.

Looking at your log messages, I can see that the battery voltage report is being read correctly from the message sent on short-presses of the reset button, and also it appears open / close messages are being handled correctly.

As for the errors:

  • error java.lang.NullPointerException: Cannot invoke method getAt() on null object on line 71 (parse)
    This is caused by a rare occurrence of a catchall: message, which just needs some code added to ignore it, because it contains nothing useful to the device driver. It's nothing to be alarmed about, as it won't interfere in the normal use of the sensor.

  • errorjava.lang.NullPointerException: null (parse)
    I am not sure what is causing this because the line number isn't given for the error. However, the Device Network ID changed between the time stamps 07:29:34.930 and 07:29:47.875, from dni: A707 to dni: 2EDA. This means the sensor was reset and re-paired, so my guess is that this error is also probably from a catchall: message.

  • Unable to parse message
    This is not actually an error at all. That particular message received from the sensor didn't contain any useful information. If people find that confusing, I could change the message to something like "Message ignored because it contains no useful data"

As long as the version 2.0.9.xxx update hasn't shot down the ability of Xiaomi / Aqara devices to stay connected to the hub, I will update all of the device drivers to stop giving errors on catchall: messages that can be ignored.

But back to the dropped connection issue. After re-pairing your Xiaomi devices, did you see any "normal" battery reports, which start 50-60 minutes after pairing and then every 50-60 minutes after that?


#723

I only have the Aqara temp/humidity sensors, but all 10 of mine are working fine in 2.0.9.

I have device watchdog watching them and alerting if they don't update in <2 hours, no reports yet...


#724

I have Xiaomi original and Aqara motion sensors, Humidity sensors and Original and Aqara contact sensors and Original buttons..
I have had a couple of drop offs but this is normal for me. Could be my zigbee network causing this but nothing out of the ordinary so I'm not really concerned.


#725

I'm also having a few devices not reporting events. They are not dropped per se. Just not reporting events. If I press the reset button once and I go into ZigBee logging the device is reporting battery there. Just not reporting events. What is odd