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.
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.
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
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.
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.
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 a smoke tested event.
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.
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, and lastTested to lastCheckinEpoch, lastClearEpoch, lastDetectedEpoch, and lastTestedEpoch, 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, and lastTestedTime custom 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 enable lastClear___, lastDetected___, and lastTested___ time/date stamp events. NOTE: the default setting is DISABLED.
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
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.
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...
@roberto@veeceeoh I installed the driver, discover Zigbee and pushed the sensor button for 4-5 sec every now and then. HE discovered it but stuck on initializing. Did this prosess a numerous of times, and waited for the pairing to finish for 30-40 mins. But still wont pair.
5 seconds first time (enter pair mode) just 1 second after. If you push 5 secs every time, the devuce enter pairing mode each time resetting the process. I hope this can help you. I had not problems.
be sure to have not any uncompatible repeater (switch off them all)
@veeceeoh, I added support for LLKZMK11LM (the Aqara double relay) to my wall switch drivers. There is not much difference, even power metering and button/relay separation works (with some tweaks), you can implement them in your drivers if interested.
Anyone with a C5 hub getting weird characters when joining some Xiaomi devices? It doesn't seem to happen to all of mine, but here is what one of my buttons looked like (this is a couple-year-old square variety):
I don't have Zigbee on my older hubs anymore so I can't test for sure, but I wonder if this has something to do with character encoding on the C5 as we found with the "Hubitat® Dashboard" app name. I suppose it could also be related to endianness changes in Zigbee parsing as of a few firmware versions ago. In any case, besides the odd display, this also prevents it from choosing the correct driver, but it seems to work as expected if I manually choose it after. Looks like it might be something with the Hubitat pairing/parsing process and not the driver itself, but I wasn't sure where to post this or if anyone else has noticed similar problems. Again, while I can't test, I suspect it's a C5 thing.
EDIT- you're correct, it's 
