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

Hi
My Xiaomi/Aqara Temp/humidity sensors are draining a lot of battery. The are new and I bougth them last saturday, the lost 15-23% in a few days.
My HE is also new and I am new... so a newbie question, should this happen?

Please see my full answer in the other thread you started on this:

Thanks, sorry, for doubleposting, still trying to find my way here...

[BETA] v0.6b of of Xiaomi MiJia Honeywell Gas Detector device driver for Hubitat

Again with the help of @SmartHomePrimer, I have been able to move forward with this driver, which should now be fully functional in every regard except the experimental Check-In Report feature. Most importantly, the check and set sensitivity level functions should work correctly, and I was able to make improvements that will in turn result in a greatly improved driver for the Xiaomi Smoke detector as well.

Major Changes / Fixes

  • Set Sensitivity Level now a Driver Command
    I realized that it would be more useful if the Gas Sensitivity Level could be changed via a driver command and to store the current state of the sensitivity level by generating events. So I have removed the Gas Sensitivity Level preference setting and there is now a Set Sensitivity Level (setSensitivityLevel) device driver command.

  • Changes in sensitivity level generates hub events
    After using the Set Sensitivity Level or Check Sensitivity Level commands, an event will be generated using a new custom attribute sensitivityLevel as soon as the confirmation message is received from the detector. The detector's current level can always be viewed under "Current States" in the device details page in the Hubitat Hub UI (see screenshot, below). This combined with the new Set Sensitivity Level command now allows users to create a dashboard that can both control and/or display the current Gas Sensitivity Level, and/or use apps to control, display, or respond to changes in the level.

  • REMOVED the "DISABLE 2.0.5 firmware compatibility fix toggle"
    Firmware 2.0.5 was many many versions ago, and I find it hard to believe anyone is still using a hub running firmware prior to 2.0.5. So I am going to be removing this preference setting from all Xiaomi / Aqara device drivers with the assumption no users require the fix to be disabled.

  • Removed, renamed, and added driver commands

    • The Configure command has been removed because it performed exactly the same function as the Check Sensitivity Level command
    • The confusingly-named Reset Hub to Clear command is now called Send Clear Event (sendClearEvent), which creates a manually generated smoke clear event, useful for testing
    • A Send Detected Event (sendDetectedEvent) command has been added, for creating a manually generated smoke detected event that can also be used for testing.
    • The Test command has been renamed to Test Connection (testConnection) because the command message sent only results in a short "chirp" of the alarm speaker to confirm the device's connection, rather than starting a full Self-Test sequence. The only way to perform a full Self-Test is via the physical button on the front of the detector itself.
  • Log output at pairing
    The driver will now automatically output all info type log messages for the first 30 minutes after the device is paired. After it automatically stops, log message output can be permanently enabled via the driver's preferences for the device. I plan upon incorporating this feature into all Xiaomi / Aqara drivers.

Screenshot:

If any of these changes / fixes are not working as expected or if you have any questions / feedback, please let me know!

I am still looking for feedback on the experimental check-in report feature. Every time the gas detector sends its check-in message (around every 5 minutes), with info message logging turned on you'll see a report with:

  • Internal temperature
  • RSSI dB value
  • Gas density value

24%20PM
(simulated log output)

Internal temperature is an unconfirmed value, and the units / range of the gas density value are unknown, so I would love to hear feedback on what range of values you're seeing in your logs. If any of these values turn out to be of use, I plan to add custom attributes so events are generated from the reports that can be then used in automations / notifications / etc.

To import the latest version of the driver, just click the [Import] button in the pop-up window and then [close], like this:

Otherwise, the newest beta device driver code can be grabbed from here.



Full Change List

  • Fixed incorrect formatting of Zigbee commands used to set the device's gas sensitivity level
  • Removed "DISABLE 2.0.5 firmware compatibility fix" preference toggle
  • Removed Configuration capability because Check Sensitivity Level device command provides same functionality
  • Removed Gas Sensitivity Level preference setting (replaced with new device driver command)
  • Added new Set Sensitivity Level (setSensitivityLevel) device driver command
  • Added new Send Detected Event (sendDetectedEvent) device driver command, which manually generates a smoke detected event
  • Added handling of check sensitivity level response messages to generate hub events using new custom attribute sensitivityLevel
  • Added debug log output for messages confirming successful receipt of check/set sensitivity commands
  • Added debug log output to identify unknown message types
  • Renamed Reset Hub to Clear command to Send Clear Event (sendClearEvent), which manually generates a smoke clear event
  • Changed log output behavior: Info level log messages are output for the first 30 minutes when the device is first paired. The preference settings can be used for log output after that.
  • Changed behavior when setting gas sensitivity level: The driver only updates the display of new level (via hub event) when a check sensitivity level response message is received from the device
  • Cleaned up and reformatted portions of code
1 Like

My xiaomi motion sensors are on a zigbee network with many repeaters and a small house. Several of them keep dropping off. Re join is easy but I don't want to keep doing it. Can anyone recommend an alternative ?

Sorry to hear that! The usual reason for Xiaomi / Aqara devices dropping their connection is that they aren't compatible with one or more repeaters (as fully explained and covered in this thread) and the only sure-fire way to resolve this is to stop using the offending repeater(s).

If you've decided you don't want to deal with that, I can say that in addition to my Aqara motion sensors I picked up some Iris V1 motion sensors on eBay at a cost comparable to the Aqara ones. They are just a bit slower but work great otherwise.

1 Like

What kind? Have you read this thread or at least the very first post (which summarizes users' findings) to verify that your repeaters are one of the (very few) known to be "compatible" with Xiaomi Zigbee devices?

An alternative to what? As an alternative to Xiaomi devices, there are countless standard Zigbee (and Z-Wave and a few LAN) devices that play well with Hubitat. You can look at the official list of compatible devices, but most Zigbee (ZHA 1.2 or Zigbee 3.0) or Z-Wave (classic or Plus) devices of common device classes (motion sensors, contact sensors, smart plugs, etc.) will work with Hubitat out-of-box.

Or if you're looking to keep the Xiaomi devices but are looking for alternative way to use them, some people have created a dedicated Zigbee network just for their Xiaomi devices (and possibly known-good repeaters) to isolate them from problems caused by many standard repeaters. You'll need a second Hubitat hub plus an app like Hub Link/Link to Hub or HubConnect (I'd recommend the latter, though the former should also be sufficient for this limited purpose) to share devices between the hubs. (If you're feeling insanely adventerous, you could probably also use the Xiaomi Gateway with Home Assistant and integrate the devices with Hubitat via MQTT.)

If you mean something else, you'll have to be more specific. Good luck whichever option you take!

1 Like

Thanks for the replies. Definitely an alternative to xiaomi. I have read the first post in detail but my repeaters are not on there. 3a nue dimmers (hubitat is working on supporting these officially soon) and swannone power out lets. So not sure they play well. They did on smart things though and rarely dropped with same setup .

I'm after a compatible zigbee motion sensor with illumination sensor but not one that will break the bank. As I have to replace about ten of them.

Iris V1 motion sensors could be a good way to go. How much slower do you find them to be ? One or two seconds I'm guessing.

Thanks again

Anyone having success with the aqara leak sensors? Mine are difficult to pair and never stay on. I have xbee3's and ikea plug acting as repeaters and all my other aqara sensors stay connected no problem... For the life of me I can't seem to get the aqara leak sensors to stay connected.

That's what I did and I don't regret it. It was cheaper for me to buy a new hubitat hub dedicated to the devices + a few Ikea repeaters than it was to replace the Xiaomi devices.

One thing you could try is to unplug any "bad" repeaters during pairing of the Xiaomi devices. This will force them to either connect directly to the hub or to go through a "good" repeater. That should at least keep them online for a little bit, and if you paired them near the ST hub (as many on that forum recommend), that could be why you didn't have problems there (the other being that the hubs' radios have different characteristics and it's possible ST's radio was stronger and more appealing even if you paired in-place). This isn't a guarantee: Zigbee devices will re-evaluate routes and change if they think one is better, but I haven't seen a Xiaomi device of my own ever do this (other say they have), so you might at least have a little luck that way.

But if you want to not worry about it at all, I'd definitely recommend replacing the devices. Iris v2 motion sensors might still be available in a lot of 10 for $55 on eBay if you're able to find them anymore, but unfortunately other devices (and even these when they they were new) tend to be a bit more expensive, one of the allures (besides their generally small size) of Xiaomi devices, I suppose.

1 Like

Yeah well said. I'll have to either invest or get lucky with finding some Iris ones thanks

Or, if you have patience, you could wait to see what happens in the next month when the new Aqara devices (Zigbee 3.0 compliant?) come out. If they are as inexpensive as past models and are repeater agnostic, it could be a game-changer for a lot of folks.

I wasn't aware thanks! Will look them up!

1 Like

I only have 1 but it's been connected for probably 6 months now and never dropped. I also have a couple of xbees but I think the leak sensor is connected directly to the hub, not through an xbee repeater.

I also have done problematic xiaomi devices with my 3asmart devices as repeaters. Drives me crazy.

Let's start a club. Ha. Keen to find out if the new ones will resolve the issues. It's not clear.

Looked at this, but it still talks about “T1” devices. Those aren’t the new (3.0) ones right?

From the various articles I've read, it appears so. Here is another link.