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

[RogerThat]

I see that you also get the preassure readings with the driver. Is it the small round one, or the square Xiaomi one that you have?
I have the round one, and do not get preassure readings.
Maybe I use a driver that does not check for this? Hmmm...
RogerThat

[bobbles]

@RogerThat

I have the round one, and do not get preassure readings.

This one does not give pressure readings. The square one does. I have both connected up to the Mi Home hub and that is what I get from this hub as well.

[RogerThat]

Ahaa, I see.
I just installed 6 of the round once, but thinking of ordering some squared once too. Just a quick experience question.
Does the sqare one have bigger batteries, or is it the same, and
do any of them seem to have better battery life than the other?
RogerThat

[bobbles]

@RogerThat

Does the sqare one have bigger batteries, or is it the same, and
do any of them seem to have better battery life than the other?

Batteries are the same for both models. As for battery life, I've not noticed any difference TBH.

[RogerThat]

OK, thanks a lot for info, bobbles!

[markus]

@altajer I have released, what I believe, a fully functional driver, see this thread. Please test it and tell me how it goes.

[a.p.a.browne]

Hi, any chance of developing the lumi.light at any point in the future?
Many thanks for all your amazing work.

[veeceeoh]

[UPDATE] v1.0 v1.0.1 of Xiaomi/Aqara Temperature Humidity Sensor device driver for Hubitat

I have finally added parsing of check-in messages, which means everyone is now guaranteed to see sensor reading report events every 50-60 minutes! Also, users will now be able to see what ZigBee parent device the sensor is connected to - a real help with ZigBee network troubleshooting. Combined with a change to log message output at device pairing, I now consider this driver to be feature complete, so it receives version 1.0 status! My plan is to incorporate parsing of check-in messages to all of my other drivers, along with any applicable fixes / improvements seen in this driver in the last 3 versions.

I'd like to give a big thanks and shout out to @guyeeba, whose code I adapted for the parsing of check-in messages.

The updated driver code can be grabbed from here. If you are currently using v0.9 of the driver, you are welcome to take advantage of Hubitat's semi-automated Import Code from Website feature to skip the manual copy and paste procedure.

Major Changes

• Added parsing of sensor reading check-in reports sent every 50-60 minutes
  The Xiaomi and Aqara Temperature - Humidity sensors always send a sensor reading report embedded in the check-in message that the driver previously only used to extract data for the battery level report. The driver will now generate events for all temperature / humidity (/ pressure - Aqara only) check-in reports, regardless of whether the value has changed since the previous event. Note that this is the one exception to following the default built-in Hubitat drivers' behaviors of not generating events when a report value remains unchanged. I decided on this because many users have reported it would be helpful to see regular, consistent, time-based sensor reports, and with only 12-13 events per day they won't "clutter up" the events lists significantly. However, the driver's default behavior for all other reports follows the Hubitat built-in driver behavior: No events are generated for unchanged battery level values and no events are generated for any unchanged sensor report values happening between the check-in messages. New preferences have been added to the driver to modify this behavior, though (see two bullet points below).

• Added parsing of check-in reports of RSSI dB and LQI values plus the device's ZigBee Parent Device Network ID (DNI)
  All three of these reported values can be found in the State Variables area of the sensor's Device View page in the Hubitat Hub web UI. Unfortunately, I have not figured out a way to convert the raw RSSI and LQI values into something usable, so until I or someone else works out the equation needed, the values listed are just the decimal number converted from the unsigned 16-bit integer hex value. However, the reported ZigBee Parent Device Network ID should be very useful as it informs the user of whether the sensor is connected to directly Hubitat hub (hex value 0000) or via a ZigBee repeater (router) device. If anyone knows of a way to automate the look-up the corresponding name of a ZigBee device based on it's network ID (DNI), please let me know!

• Added preference settings to change behavior of generating events for unchanged battery levels and sensor readings
  As mentioned above, by default no events are generated by the driver for unchanged battery level values no events are generated for any unchanged sensor report values happening between check-in messages. I've added two preference toggle settings to override this default behavior: One toggle to enable generation of all events for unchanged sensor readings between hourly check-in, and the other toggle to enable generation of events for unchanged battery levels (i.e., events for all battery reports). Note that there is no way to disable generation of events for check-in sensor reading reports with unchanged values.

• Changed the behavior of log message output when device is paired or re-joined
  In previous driver versions, a few info level log messages were output during the initialization of the driver when the device is first paired. The driver now automatically enables both info and debug level log messages for the first two hours after the sensor is paired or re-joined to the ZigBee network. The two hour timer can be overridden by enabling / disabling message logging as desired and saving preferences for the device.

• (v1.0.1) Reverted back to using pressure attribute for pressure events

Screenshots

Detailed Changelist

• Added parsing of "check-in report" messages sent every 50-60 minutes:
  • Generate events for check-in reports for sensor readings: temperature / humidity (/ pressure - Aqara only). Note that all check-in sensor reading events are generated even if the value is unchanged from the most recent event. Check-in sensor reading events can be recognized by the addition of "(check-in report) at the end of their event description text."
  • Log output and update State Variables for reported RSSI dB, LQI, and ZigBee Parent device network ID (DNI)
• Added new preference settings:
  • Added toggle to enable generation of events for ALL sensor readings that occur between check-in reports. The default is the normal Hubitat driver behavior of NOT generating events for unchanged sensor reading values, with the exception of check-in reports.
  • Added toggle to enable generation of events for ALL battery reports. The default is the normal Hubitat driver behavior of NOT generating events for unchanged battery values.
• Debug and Info messages are now automatically logged for the first two hours after the device is paired or re-joined. A State Variable is no longer used for the purpose of automatic logging at device pairing.
• Refactored and changed method of generating events [all events are now generated using sendEvent()]
• (v1.0.1) Fixed issue with pressure measurement events not working correctly by reverting back to attribute pressure

[aaiyar]

Thanks, Keith!

[rocketwiz]

Seconded!!

[gavincampbell]

Thanks for all the work you put into this!

[chillibenny]

Hi Veeceeoh,

The screenshot of what appears to be some sort of ZigBee Analysis / Mesh Info software, do you mind if I ask what is it called & where you got it?

The reason I ask is that when I troubleshoot IT/Electronics/etc., the fields I work in, I have a wide variety of tools including software to reach a successful end to nagging faults etc.

However, the one thing I prefer to start with is Software that generates usable graphics as it takes in information that compliments the technical data.

I just find it helps me when I need to get my head around an issue, software or hardware related to build myself that mental picture when diagnosing faults, especially like HA setups as they start to expand in size and complexity.

Cheers

[markus]

That is Digi XCTU, used with an Xbee Zigbee device.

[way2fast4u]

How did you get the lux value to show on hubitat. I have one and it will only show movement. I am new at this. Thanks

[veeceeoh]

@way2fast4u

I have one and it will only show movement. I am new at this. Thanks

There are two models, the Xiaomi Motion Sensor (RTCGQ01LM), and the Aqara Motion Sensor (RTCGQ11LM).

Only the Aqara model has the light sensor to give lux readings. Which one do you have?

[way2fast4u]

I have the Aqara Motion Sensor (RTCGQ11LM)

[aaiyar]

Using the correct driver?

Edit - the original and Aqara versions use different drivers.

[way2fast4u]

I am not sure I know it says device

[aaiyar]

@way2fast4u

I am not sure

Okay - sounds like you don't have a driver installed. Read this post by @veeceeoh, and install the correct driver for your lux/motion sensor:

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

NOTE: Although many users have had great success using them, Xiaomi / Aqara ZigBee devices are NOT officially supported or guaranteed to work on the Hubitat Elevation platform. I am maintaining a collection Xiaomi device drivers for Hubitat in a GitHub repository, at veeceeoh/xiaomi-hubitat. These device drivers are based on the bspranger/Xioami repository of device handlers for SmartThings, but with significant modifications and improvements for use only on the Hubitat Elevation hub platform. …

Also, read this post:

Xiaomi & Aqara Devices - Pairing & Keeping them connected

NOTE: Although many users have had great success using them, Xiaomi / Aqara ZigBee devices are NOT officially supported or guaranteed to work on the Hubitat Elevation platform. Because of their small size, simple design, and relatively low price, the Chinese home automation (HA) market ZigBee mesh network-based devices from Xiaomi / Aqara have seen an increasing level of popularity in other countries, where users are attempting to integrate them with their HA hub platform of choice, instead of t…

[SmartHomePrimer]

Or the driver may have been installed, but it didn’t automatically select it on pairing, so it needs to be manually set and saved in the device settings.