[Deprecated] Xiaomi / Aqara ZigBee device drivers (possibly may no longer be maintained)

I always noticed this from the one in the kitchen, and it says Aqare on the top. It flashes twice now, and I'm fairly certain it only flashed once before. I believe the hack puts the motion sensor into a test mode permanently. Battery is still at 100% and it works perfectly. I'm happy that someone figured this out for all of us.

2 Likes

Thanks @bizapp I will get some of that. How many coats did you end up putting on by toothpick in the end?

One coat, but you may have to dab two or three times if you don't get the liquid down quick enough before it starts to dry. You just have to be careful not to put too much and connect more than the two required contacts.

You could also use Super Glue and Al Foil to bridge the contacts or some of the automotive putty that contains metal. There’s a JB Weld that is metallic and should conduct.
Obviously you just need a tiny amount, just able to link the contact points.

Got my two temp sensors working.

It may be crazy, but I think I figured out a new trick. So once you get them paired and they haven't sent their battery report (after 50 mins or so), they only seem to report when there's a significant change in temp/humidity/pressure. Even pressing the button didn't get them to reliably report if nothing had changed.

So... I just blew (like you do when you want to clean your glasses) on the sensor a few times. That raised the humidity up to a good 80%+ and they started chatting away as they went up, then fell back down to normal. Could just be a coincidence, but they stayed paired after that, reported battery status, and have been good since! =)

1 Like

You mentioned buying an xbee. Please see my post below the xbee S2C is 17.50 and has an incredible signal, total cost like 20 bucks with a cheap USB adapter

adapter:
https://www.aliexpress.com/item/Pro-Mini-FT232RL-FT232-BTBee-Bluetooth-Bee-USB-to-Serial-IO-Port-Xbee-Interface-Adapter-Module/32896387394.html?spm=2114.search0604.3.14.73e34305YQaEBZ&ws_ab_test=searchweb0_0,searchweb201602_2_10065_10130_10068_10890_10547_319_10546_317_10548_10545_10696_10084_453_454_10083_10618_10307_537_536_10902_10059_10884_10887_321_322_10103,searchweb201603_35,ppcSwitch_0&algo_expid=d80b5632-15ff-4a78-812d-aba5db95d71a-2&algo_pvid=d80b5632-15ff-4a78-812d-aba5db95d71a&transAbTest=ae803_5

Ordered aliexpress adapter.

Will wait to order Xbee for like a month since then they'll likely arrive around same time. =P

Thanks!

I’ve got a picture of someone bending over a tiny sensor blowing over it, in my mind now. LOL

1 Like

The adapter above doesn't include the reset button, and most of the time is needed, so probably you will have to short 2 pins in the xbee when doing the programming.

This one has the reset button and it is micro USB instead mini USB

1 Like

[BETA] v0.8 of Aqara Vibration Sensor device driver for Hubitat

After two weeks of testing and trying out different implementations of sending the command to set the sensitivity level of the sensor, I have a working beta with two mechanisms for setting the level.

The updated driver code can be grabbed from here .

Major Changes

  • Working implemention of changing sensitivity level setting
    In a nutshell, the way it works is like this: The driver needs to request the hub to send a specific write attribute command with the sensitivity level to the sensor, which is queued to send, until the user short-presses the reset button on the sensor itself. At that moment the command is sent, and the sensor sends a catchall message back to the hub as a confirmation that the sensitivity level change request was accepted.
    However, there's no way to read the current sensitivity level setting because the sensor won't respond to any read attribute commands. So it's up to the driver to keep track of what level was last requested and then generate a custom attribute event for sensitivityLevel that the user can look at or use in dashboard to know what level is currently set.
    There are two implementations. The default is to use the reset button itself. Basically, press it once to queue up the command, and then press it again so the sensor responds with the confirmation. The requested level will cycle through the three choices like this: low -> medium -> high -> low, etc.
    Unfortunately, in my testing it is not 100% consistent in responding with the confirmation, so I set up the driver to try sending the command again on the next button press. It is entirely possible the wrong level is getting set when this happens, and I am hoping the great people here can help with testing that.
    The second mechanism needs a preference setting to be toggled, named "Enable sensitivity level change command 'buttons' (DISABLES reset button level change mechanism)". When that toggle setting is enabled then the three command buttons can be used, as seen here:


    The same procedure needs to happen with these buttons as well, though. Click the corresponding button, and then short-press the reset button on the sensor itself for the queued command to be sent, and (hopefully) the confirmation message will be received. Again, this has not worked 100% in my testing. Sometimes it takes two short-presses of the reset button for the confirmation message to be sent by the sensor.
    Using either mechanism I highly highly recommend enabling info message logging so you can get feedback on what's happening. Note that every time the reset button is short-pressed, a status message is sent that includes a battery report so the driver will parse that and generate an event as well. Here's what info log output looks like when using the default mechanism of short-pressing the reset button:
    08%20PM

  • lastCheckin___ events now only occur at same time as battery reports

Detailed Change List

  • Changed method of sending sensitivity level request on reset button press to include a 300 millisecond delay
  • Added Set Sensitivity Level command 'buttons' (disabled by default)
  • Added check for catchall: messages to handle sensitivity level change confirmation
  • Added preference setting to enable set sensitivity level command 'buttons' and disable reset button press mechanism
  • Refactored code that manually parses map of elements in read attr messages
  • Removed unnecessary Refresh command
  • Changed lastCheckin___ events to only occur when the sensor checks in (at same time as when battery voltage is reported)
  • Changed initialization to set sensitivityLevel to "unknown" when sensor is first paired
  • Other fixes, reformatting, and reorganization of code

If you can at all confirm that the level reported matches the sensitivity you are experiencing with your sensor, it would be of great help.

One last note: I have read in one place that it may be possible to set the sensitivity to 100 different levels, not just the three offered in the native Xiaomi/Aqara Gateway + Mobile App, so I am investigating this.

As always, thanks everyone for your patience and support!

6 Likes

Really appreciate the work you put into figuring this out. Thank you.

1 Like

Keith, Huge thank you for continuing to improve these drivers. So with the vib sensor, I used ONLY the set to high & medium sensitivity buttons in the new driver. In over 10 changes(high to medium & reverse of that) they work perfectly. I have the Xiaomi hub and it also requires a quick press of the reset button to change sensitivity levels , when the sensor is connected to the aqara hub.
Thanks to you, I am very close to being able to deploy these vib sensors as glass break sensors on my windows.

2 Likes

Another observation, in troubleshooting a disconected xiaomi door/window sensor. I tried pressing the reset button for 5 seconds, that didn't help, so I pressed it for 10-12 seconds and it was detected. Once i realized i was using the wrong driver of yours -> Xiaomi "Original" & Aqara Door/Window Sensor Version 0.7.1,(has temp capability) I switched to the correct driver for sensor(the lumi aq2 door sensor) Xiaomi "Original" & Aqara Door/Window Sensor ver 071(this driver lacks temperature capability)
Once i changed the driver and the sensor was reporting I observed something I've never seen before, under state variables I saw the router to which the sensor was connected. Not sure if this is a driver function or a hub update(im on the latest 2.0.8.109 hotfix). I think this would be very valuable, esp with Xiaomi devices troubleshooting.

Actually, if you were using a Door/Window Sensor driver with temperature capability, that means it's @guyeeba's variant of the driver, and that's where the routerID came from. My current Door/Window Sensor driver (works for both the "original" and Aqara models) is version 1.7.2.

He came up with a method to make better sense of the long string of data that is sent by Xiaomi/Aqara devices when they do their regular 50-60 minute check-in, beyond the battery voltage data that my drivers (and the SmartThings device handlers they were originally based on) pluck from that data.

I have seen no evidence that the Door/Window Sensors have any temperature sensor hardware, however the router DNI (device network Id) appears to be legitimate, possibly along with LQI / RSSI values.

I have been planning on testing and adapting his method of parsing the check-in data string after finishing the vibration sensor driver. Since I have the XBee to check on what my Xiaomi / Aqara devices are connected to (router vs directly to the hub), it should be quite straightforward to test if that apparent router DNI is correct in all cases across all of my Xiaomi / Aqara devices.

1 Like

The board part arrived today (and the pro module last week), yes, I see now that a 5 year old could put it together. Originally I had thought it would need soldering etc. Now I just have to read up on how to configure it/get it into my system.

1 Like

That is awesome to hear. I just wanted to offer an observation that might save you a headache. With my XBee sometimes a different 16 bit device address is shown on the scan, as compared to the hubitat device page. I'm not sure what's going on but the address in Hubitat is the only one that actually controls the device.
Considering all the advanced stuff you're doing you're probably already aware, but thought I'd mention just in case.
I'll double check the door/window driver(that includes temp) author, but I only download your stuff, I'm partial :smiley: EDIT- you're correct, it's @guyeeba 's driver but he left your namespace/author in it, hence hubitat displays your name in drivers tab

[UPDATE] Xiaomi Mijia Honeywell Smoke Detector device driver for Hubitat v0.6

This update takes the previous release out of beta, and adds two new features courtesy of @guyeeba: A smoke sensitivity level preference setting, and a (self) test command. Since I don't own a Xiaomi Smoke Detector myself, I am unable to test any of the improvements and new features. Please let me know if anything is not working as expected.

The updated code is available here.

Major Changes

  • All changes from the v0.6b beta release (see this post for details)

  • Added Smoke Sensitivity Level preference setting


    This feature comes thanks to @guyeeba and has a default of High Sensitivity.
    Note: the sensitivity level will not be set by the driver when the smoke sensor is first paired or if the sensitivity level is manually changed. It will only be set when you press the "save preferences" button while viewing the device details page.

  • Added (self) test command


    This feature also comes thanks to @guyeeba. I believe when the command "button" is pressed, the alarm will sound a short beep to confirm the smoke sensor is working properly, and may also send a message back to the hub that results in a smoke tested event.
    Additionally, using this command might have the added benefit of silencing a smoke detected alarm. I would be very interested in hearing whether this is the case.

Detailed Change List (since v0.5.1)

  • Added test command (thanks to @guyeeba)
  • Added sensitivity level preference setting (thanks to @guyeeba)
  • Reworked and refactored message parse code to eliminate errors introduced in driver v0.5.1
  • Corrected an undefined object used when parsing IAS Enroll Request messages
  • Fixed debug message output behavior so that "Enable debug message logging" now controls all debug message log output
  • Renamed custom attributes lastCheckin, lastClear, lastDetected, and lastTested to lastCheckinEpoch, lastClearEpoch, lastDetectedEpoch, and lastTestedEpoch, respectively, used to generate Epoch time/date stamp events
  • Removed any references to WebCoRE for use of Epoch-time/date stamp custom attribute events and replaced with "Apps that can use Epoch time/date stamps"
  • Added lastCheckinTime, lastClearTime, lastDetectedTime, and lastTestedTime custom attributes, to be used to generate human readable time/date stamp events
  • Changed lastCheckin____ events to only occur when the sensor checks in (at same time as when battery voltage is reported)
  • Added two new preference settings, one to enable generation of lastCheckin___ time/date stamp events, and the other to enable lastClear___, lastDetected___, and lastTested___ time/date stamp events. NOTE: the default setting is DISABLED.
3 Likes

Does this detector activate the other detectors in the house? I've looked at a lot of devices and the interconnected feature seems to be missing. If HA works right everything happens. If not, I still need every detector to sound.

The Xiaomi MiJia Honeywell Smoke Detector cannot link to and activate the alarm of other Xiaomi Smoke Detectors.

Actually, the name of this Xiaomi device should be smoke alarm, because that is the industry standard name (in the U.S.A.) for self-contained smoke sensors with a built-in alarm.

If you really need a 100% reliable system that will sound all alarms in a whole house or building when smoke is detected by one sensor, then I would not recommend using Hubitat, SmartThings, or any other general home automation hub-based system.

With people's lives potentially at risk, I would recommend looking at dedicated fire alarm systems.

By the way, I am changing all "fire detector/detections" references in my posts to "smoke detector", because the device doesn't actually sense or detect fire, but rather smoke only.

In the next couple weeks I will do a dissection, sometimes those xiaomi devices can be a challenge to open, and also I'm going to run mine at 60hz. From what I understand the mfg has no motivation to test at 60hz, even tho the device could be compatible. So I will test at 60hz. If I understand correctly the freq is only a big deal for motors/compressors etc.