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

🚧 Developers
323

It wouldn't handle them better per se, it would just be a way to isolate them on their own zigbee network with no other devices other than xiaomis.

324

I'd never move them back to my ST hub, for two reasons:

  1. A major loss of functionality. On SmartThings, you lose access to a bunch of functions of the Xiaomi / Aqara buttons & Wall switches. For example, the two button Smart Wireless wall switch is only "seen" as one button (both buttons send the same message when used in SmartThings), while with the Hubitat Hub, it works perfectly.

  2. Local execution of code. That's the main reason I switched over to the Hubitat hub. Cloud executed code makes a very noticeable hit on the speed and responsiveness of motion sensor and button activated automations and routines.

Another example: Combine those two factors, and the original Xiaomi button goes from being rather inconsistent on ST when using the driver-based button hold feature to working great with the Hubitat hub.

1 Like
325

The multi-clicks on the Xiaomi round button are assigned to different button numbers. So in RM, select that Xiaomi button, and then for double-clicks, choose button 2 pushed as the trigger, for example. Triple-click is button 3 pushed, etc.

Note that with all the Aqara buttons, if there's a double-click function, then that is assigned to button 1 double-tapped, not pushed.

326

Works thanks

327

With the newest Xiaomi Aqara Vibration sensors, how is everyone finding the battery life? Mine are in a colder section of house and after a month are at 30%. Since these are so new I'm not sure what to expect from them or if this short life is exposing a communication issue. I know the driver is beta for this DJT11LM sensor and not sure IF that could affect battery life or if they are reporting so frequently it's killing the battery

328

I've noticed the battery drain too, not huge as your but in a month it lost around 30% and it's placed few meters from the hub so it's not related to poor signal

329

A few things to know about the battery percentage reported by the Xiaomi / Aqara device drivers:

  • The percentage is calculated based on voltage, which is not an accurate method, but as voltage is the only thing reported by Xiaomi / Aqara devices, it's all we have to work with.

  • Newer versions of Xiaomi / Aqara device drivers (including the one for the Vibration Sensor) use a minimum Voltage of 2.9V and max of 3.05V to come up with the reported percentage, changed from 2.5V min / 3.0V max after @bobbles reported that changing the min/max values might help. Keep in mind that they are still essentially arbitrary values, and the calculated percentage only gives a very very rough idea of battery health.

  • Add factors such as different drain rates on each type of device and different environmental conditions for every user's placement and it's basically impossible to know when a battery has gone below operational capacity.

  • All the Xiaomi / Aqara device drivers cannot have any effect on battery life at all. This is because (with the exception of setting the Vibration Sensor's sensitivity level), all Xiaomi / Aqara devices completely ignore ZigBee polling messages and any commands that would change the frequency of reporting. Any unusual battery drain witnessed would be related to other factors, such as weak mesh signal strength, a higher frequency of triggers (affecting buttons, motion sensors, door/window contact sensors), or a higher frequency of temperature/humidity changes (affecting the temp/humidity sensors).

I know all of the above is probably not what people would hope to hear, because essentially what I'm saying is you don't have any way to know exactly how much battery "life" is remaining in your Xiaomi / Aqara devices.

If anyone has had consistent experiences with a lower voltage value that indicates the end of battery life for a particular device (because I expect this to be different for each device,) please by all means report it here and we can look at changing the min/max defaults used to calculate the battery percentage in the driver for that device.

330

Curious question - are you still planning on updating the temp driver to log less? I thought you said you were. Now that I have 10 of them paired, it is getting a little chatty in here.

I don't mind doing it myself, but thought I would ask first.

331

There's nothing I can do to reduce how frequently the temp/humidity sensors send reports to the hub. That is according to how the hardware is set up, and as mentioned all ZigBee commands to change the frequency or reporting or polling are ignored.

The way the hardware is set up, when temperature / humidity has changed by a certain amount, a report is sent. So that also doesn't help to reduce the number of reported events, because the only thing I can do in the driver is to ignore events that are consecutive repeats of the same value. So if the temperature is reported at 65 and five minutes later it's reported at 65 again, you'll only see one entry in the events list.

And that just leaves two things, which would basically halve the number of events seen in the events list: Battery voltage, and the custom lastcheckin time/date stamp which generates a custom event for every message received from the sensor.

However, if you were just referring to info and debug logging messages, either or both of those can be disabled in the preference settings for each device. The default after pairing is for all logging messages to be disabled after the initial setup is complete.

I can update the Xiaomi/Aqara Temp Humidity Sensor driver to follow in the footsteps of the changes to the Vibration sensor quite soon here. But I'm also thinking of changing when lastcheckin is reported, to only at the time that battery reports are received (every 50 or 60 minutes depending on the device). It will still be a feature that has a preference setting toggle to disable it, though.

332

Any trouble with these newer door window sensors? I'm assuming newer because I don't have an option to buy the more rounded type I had purchased before. I'm able to pair them, and while I don't get battery level at first, if I tap the pair button the battery level appears and I get an updated checkin.

Problem is I'm not getting a response when I move the magnet away. Also cannot manually reset to open or close in the driver. All this may be my fault. I got over confident and soldered wires to the board to trigger this remotely, but did not test it in it's stock configuration first. So either it's defective, or I overheated something and screwed it up. I've double-checked and there is no short. If I move the magnet near it, I can get a reading between the wires, so that confirms I didn't accidentally bridge the solder points and the reed switch is functioning.

What has been your experience with this type? Works right away or needs to be paired a few times before it starts responding?

333

I ordered 8 of those, I hope is something that can be fixed

334

[UPDATE] v0.8 of Xiaomi/Aqara Temperature/Humidity Sensor Device Driver

The new device driver code can be grabbed from here .

Similar to the most recent update to the Vibration Sensor beta driver, I've made "under the hood" changes in terms of how events are reported as well as adding control over custom checkin time/date stamp events that are reported.

Major Changes

  • The voltage range for Battery % has been changed
    The minimum / maximum voltage values used to calculate battery percentage have been changed from 2.5V min / 3.0V max to 2.9V min / 3.05V max. This means your reported battery percentages will change from what you have been seeing! It should not be a cause for alarm, however. Keep in mind that using the min / max voltage values to calculate a battery percentage only gives a very very rough estimate of battery health. Also, the min / max voltage values can be changed in the preference settings in the device details page for each sensor.

  • Battery % events will only occur when there's a change
    If you've been relying on battery percentage reports to know whether your sensor is still on the ZigBee mesh network, then you'll need to enable and start looking at the lastCheckin events (see the next point, below).

  • lastCheckin Time/Date stamp events are now optional (default = disabled)
    This driver includes custom lastCheckin_____ attributes for users that would like to use either for displaying the time/date of the last instance of a particular event in a Hubitat Dashboard (using lastCheckinTime), or to use with WebCoRE (if you dare) or other automation apps that may need the (UNIX) Epoch-based date format (using lastCheckinEpoch).
    Both of these custom attributes will now only generate an event when the check in / battery report message is received from the sensor (either every 50 or 60 minutes, depending on the model).
    However, these custom attributes add 28-30 extra events a day that some people would rather not clutter up their events list. So I've added a preference setting to enable/disable lastCheckin events. The default for these settings is disabled so if you've been making use of any of lastCheckin, you'll need to go to the device details page for the sensor and enable them.

Detailed Change List

  • changed default battery voltage range used for calculating percentage to 2.9 V minimum / 3.05 V maximum
  • Renamed custom attribute lastCheckin to lastCheckinEpoch (to be used for generating Epoch-based date/time stamp events)
  • Added custom attribute lastCheckinTime to be used for generating a human readable date/time stamp events - useful for displaying in a Hubitat Dashboard
  • Changed the use of both lastCheckin____ attributes to only generate an event every time the sensor does its regular 50 or 60 minute check in and battery report
  • Added a Preference Setting to enable/disable all "lastCheckin" events (lastCheckinEpoch and lastCheckinTime) with a default of DISABLED
  • Removed isStateChange: true parameter from all events except TiltAngle to avoid any redundant repeat events being posted
  • removed endpointId and deviceId values from fingerprints
  • Fixed reset battery replaced date command function
  • Change date formate used for battery replaced date to MMM dd yyyy (e.g., "Jan 17 2019")
  • Improved initialization and configuration when sensor is first paired
  • Reorganized code (order of functions, some refactoring)
  • Other minor code formatting cleanup and fixes
3 Likes
335

My first open/ close report came in at around 3 minutes After initialization. I don't check immediately as it seems some configuration or setup is occurring during the first few minutes after pairing, as evidenced by the change in the layout of the device page, with certain attributes only showing up after a while, ie: the device details page looks different after some time passes, maybe initially missing a parameter or two, then everything displays properly after a minute or two elapses.
PS- what is up with those batteries, a 1623?? I've only seen those once before in 50 years, I hope the lifespan is okay in these door sensors.

336

Looks good. I think the logging I was thinking of was the 3+ checkin events I got each 50 minutes. Obviously that is changed in this version - thanks!

337

I have installed 6 of them and around other 20 ready to be installed. No big issue so far, pairing and reporting correctly.

338

I had 2 of the older ones on a metal curtain pole that kept going inactive. New batteries didn't improve things. Changed them for the newer type and they have been rock solid. Not sure why but just thought I would put it on here.
BTW put the old ones on different doors and they have been fine since. Just one of those things. :wink:

339

Thanks. Sounds like I overheated it or knocked a cap off it. Something I did essentially. :confused:

340

@SmartHomePrimer I have a spare one sitting on my desk for months that is paired to my hub working fine.

1 Like
341

@veeceeoh

Was looking at the motion sensor with the illuminance capability. It currently reports in a range from 0-100 (or 255 not sure). According to the ST capability list this range is 0-100,000 lux. I didn't see a range mentioned in the Hubitat documentation though.

Do you think it would be good to translate the 0-100 reported by the device to the 0-100,000 range in the capability?

Only asking because I have some devices that use 0-100,000 and the motion devices use a smaller range. So it throws of apps.

342

Weird experience I've never had with these before. It's working now. Had to reboot because my Zigbee network was offline for some reason. I'm certain it wasn't offline when I tried before, because I was able to un-pair and re-pair it several times in an attempt to get a response from it. I'm wondering if maybe I have possibly still damaged this one and it's what caused that to happen. Working now. Will have to keep an eye on it.

Thanks everyone for the feedback.