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

@veeceeoh has an explanation of how to get the Xioami to rejoin and change route without re-pairing. I have so few devices in comparison though, that I found it easy enough to just re-pair in place once the repeaters were in.

1 Like

of course.

1 Like

Start with the HE nearest repeater and then add one by one, one further the other. That worked for me

1 Like

@SmartHomePrimer apart from soldering the 2 points on the motion sensor or using a pencil, is there any other way to bridge that gap to do the super sensor hack? My solder skills are shocking (I have it a go last week and just don’t have the skills) and the 4H pencil that was suggested in the super sensor thread hasn’t worked (I drew the line multiple times, softly and pressure but no good) :smirk:

Only way. Give someone with a steadier hand a go? I have some of the shakiest hands, but I’ve been soldering since I was 5 years old too.

1 Like

Wait, what super sensor thread? Ive searched but don't see it. I want to solder a super sensor!!

1 Like

I used this to make the bridge and it works fine.

Besides the much quicker response, the only odd thing I noticed after doing this is that some of the motion sensors would flash blue when it detects motion in the morning. Not sure if this is because my solder isn't clean between the two points (bridging another contact) or it's normal behavior.

The pen isn't fine enough nor easy to use in the very tight location, so I just pressed the tip onto something to release some of the liquid and used a toothpick to dab some of the liquid metal and connect the traces quickly before it dries.

2 Likes

The blue flash and lack of blue flash is a difference between the Xiaomi versions. I modified two. One flashes and one does not. One says Aqare on the top and one doesn't.

All of my motion sensors are Aqara, but before the mod, I don't remember seeing them flash upon motion at all. After the mod, they flash once, I'm assuming after a long period of no motion.

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