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 
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 asmoke testedevent.
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, andlastTestedtolastCheckinEpoch,lastClearEpoch,lastDetectedEpoch, andlastTestedEpoch, 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, andlastTestedTimecustom 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 enablelastClear___,lastDetected___, andlastTested___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.
Thanks for the info! I had Nest Protects in my old house with SmartThings and it worked well plus nest interconnects the detectors. The problem was dependency on cloud connection for all associated actions like unlocking doors, turning on lights ect. I'll have to keep looking, nest is too expensive
Hey Anyone want the Aqara motion sensor with Lux level for 11.99? RTCGQ11LM
Using the Aqara Motion Sensor V. 0.7.2 i cannot set max battery level to any value.
Look at the following screen snapshot
[SOLVED] Now it is working. Nothing is changed ...
After adding the driver for whatever Xiomi or Aqara product I want to pair. Do I need to "add virtual device" and in that case what should I use as "Device Nettwork ID" ?
No.
Just pair the device with the hub and when pairing the device should automatically pick the device type.
It should also automatically fill in all the required fields.
1 Like
Thanks, it works with both the window/door sensors from aqara and Mi, aqara click but not with the mini motion sensor.
Do you still need help getting the Motion Sensor paired to your hub?
If yes, can you explain what happens when you try to pair it?
Install the driver.
Acrivate zigbee discover function and Push the motion sensor button for 4-5 seconds, then every few second push again for one second the button, until HE discover the device.
This worked for me.
Using it for 10 minutes, it's working fine so far... 
Pros: Can be used with both momentary and regular switches, so perfect for retrofit. Reports changes, aaaaand: supports power measurement!
Cons: Floods the network with unusually long xiaomi strings (144 bytes in every 6 secs or so, but at least they're properly length-prefixed...), and despite its small size, it seems to be challenging to squeeze it into a standard european wall box...
Fingerprint:
manufacturer : LUMI
idAsInt : 1
inClusters : 0000,0003,0004,0005,0001,0002,000A,0006,0010,0B04,000C
endpointId : 01
profileId : 0104
application : 23
outClusters : 0019,000A
initialized : true
model : lumi.relay.c2acn01
stage : 4
manufacturer :
idAsInt : 2
inClusters : 0006,0010,0004,0005
endpointId : 02
profileId : 0104
application :
outClusters :
initialized : true
model :
stage : 4
Interesting stuff, probably I'll create a driver for it in the evening...
