You’re not doing anything wrong. Xiaomi devices aren’t always so easy to pair.
Sometimes a catchall message seen in the Hub Events will be different from the one that can be used for the “catchall” method to add a Xioami device. However, in your case, the raw: message contains everything you need to add that device:
dni is the Device Network Id and ieee: is the device’s Zigbee Id.
So if you haven’t long-pressed the reset button since you saw those messages, you could try copying those hexadecimal strings to add a device manually:
Otherwise, I would suggest trying to pair again. Sometimes it takes several attempts.
for reference
the Xiaomi Aqara motion sensors had been previously paired directly to the Hub but then remove and paired again through the Orvibo outlet
the Xiaomi Aqara water sensors were brand new never paired before until going through the Orvibo outlet
after 24 hrs with no power to the Orvibo ZigBee Smart Outlet
the Xiaomi Aqara motion sensors 1 automatically re-paired by itself directly to the hub after 7.5 hours the other did not
none of the Xiaomi Aqara water sensor re-paired
After I re-applied power within 5 minutes all of the sensors (including the motion) that stayed offline automatically started reading again. (no pressing the joining button)
I am going to remove all of the Xiaomi Aqara sensors then remove power from the Orvibo outlet again and add a GE ZigBee In-Wall Smart Switch 45856GE.
then try to pair all of the Xiaomi Aqara sensors through GE ZigBee In-Wall Smart Switch 45856GE and see how it does.
I will leave everything powered on and connected for at least 3-4 days.
Thanks a lot, Keith! That was an easy to follow explanation.
I had a better experience with aqara door and motion sensors. Paired them up within 5min of efforts.
I spent ~1hr yesterday, before posting here.
I will try out the way you suggested.
Edit: Got 2 original switches working. To me, they are less reliable registering a press. I am comparing with the responsiveness of Aqara door sensors and Aqara motion sensors. Could anybody compare between Aqara and Original Switches? TIA.
Happy to report that after powering off all my Hue devices and the two ZigBee light switches at the time of pairing, the Xiaomi Aqara sensors have stayed connected far longer than they did before. I have one more I need to pair. Going to try just powering off the two light switches and seeing if that does the trick
I have around 20 xiaomi sensors and about 6 xiaomi outlets.
For me this has been working quite ok, but i still have the occasional dropoffs.
Dropoffs mostly occur with sensors on windows/doors that are not frequently used.
One thing i’m about 100% sure is that Orvibo products don’t play well with Xiaomi.
I have a few Orvibo (door) sensors, and these fall asleep when using the Xiaomi outlets. It takes one door-opening to wake them up. Basically you miss the door being opened.
I still have one Orvibo sensor in use, connected directly to the hub and works 100% fine.
There are also reports that the original Smartthings sensors don’t play well with the Xiaomi outlets.
Since i am now 90% Xiaomi zigbee, everything works fine. The other 10% are Ikea Tradfri bulbs. These work 100% fine with the Xiaomi outlets, i have had 0 (yes zero) dropoffs with these bulbs connected to the Xiaomi outlets. I have used these Tradfri bulbs for about 6 months.
As said, The Xiaomi sensors have been working fine with the Xiaomi outlets, but i still have one droppoff per month. Sometimes they reconnect automatically and i have installed a few more Xiaomi outlets to improve the mesh, which seems to work.
Although i don’t have many dropoffs i have replaced all the major doorsensors with z-wave.
I bought three Aqara contact sensors and succesfully paired them with my Samsung Connect Home, which supports hub functions.
I am using up to this date DH, pairing was easy, but all of my sensors are going offline after cca one hour after battery check. Before that it worked fine even showed battery 100%.
Do you have any idea how is this possible? I dont have any other zigbee devices. Paired them again and again and same results.
@ArstenA - can i suggest a quick and small edit on the motion sensor DTH? At the moment, the default time for motion to be reset is not set. So i think the motion resets pretty fast. For the Aqara sensor, the hardware stays blind for 120 seconds. Can that be put in as the default?
I recently switched to the new DTH and all my automations went wild. Once i has set the default to 120 seconds, everything was back to normal.
Mine all come in at 60 seconds. Remember that when you first pair (or if you click the button) the motion sensors go into test mode for 2 hours - during which they reset every 5-6 seconds. After 2 hours they settle down to the regular 60 default.
I have two Aqara Motion sensors, and like @AlecM, when in normal mode the hardware is blind for 60 seconds after detected motion, not 120 seconds. All other user reports I’ve read here on the ST forums and elsewhere online show the hardware reset normally happens at 60 seconds.
The default of the DTH preference to reset motion before @ArstenA just changed it was 60 seconds, same as the hardware. It even says that in the text of the preferences. The code is written so that if the preference is left blank, it will still use a reset time of 60 seconds.
Did you re-pair the Aqara Motion sensor when you switched to the new DTH? As @AlecM mentioned, when the sensor is paired or if you short-press the reset button, the sensor will start a “test mode” which lasts for about 2 hours. During the test mode, the sensor hardware is only blind to motion for about 5-6 seconds.
I think the problem relates to the fact that the DTH doesn’t ignore any motion detected messages from the sensor during the countdown to the 60 second reset (or whatever the user entered in preferences.)
We could change the DTH so that even if the sensor is in test mode, the frequent motion detected messages are ignored, until the DTH countdown is finished and it resets with the “inactive” event.
EDIT: I looked around again, and even in this (somewhat badly translated) Xiaomi device API document, it confirms the 1 minute hardware motion detection timeout:
Aqara human illuminance sensor:
Information will be immediately reported to a report when the human sensor detects the movement of
people have also report illumination value “lux” at the same time. In the case where people have been moved, to conserve power, the human body sensor transmits a fastest one minute report. When the humanbody sensor of each heartbeat, also report the current illuminance value “lux”. In all other cases, it does not report the human body sensor light luminance value.
@veeceoh I wouldn’t want to change the DTH to “ignore” the frequent motion sensed during the 2 hour test period, if I’m understanding what you’re suggesting. I find it very useful to use while figuring out where to best place and how to point the device (which is the whole point of test mode). If it were messing up an automation I’d temporarily take device out of it or disable automation until it settled down. (or cover the sensor or temporarily point it to wall - whichever is easier).
Yes, I agree with that idea, but then the user could still set the “inactive” reset time to be shorter.
However, I realized my idea won’t work well, because it would prevent the “inactive” countdown from being extended by subsequent motion detected events.
I think the problem has to do with how automations are set up. If the automation is only looking for new motion “active” events, then during testing mode of course they will go crazy. If they are set up to only happen when changing from “inactive” to “active” then with the 60 second default in preferences, they would act normally even when the sensor is in testing mode.
The best happy medium I can think of is to add a second countdown timer which is 5 seconds shorter than the “inactive” reset counter. That second countdown timer period would then be used to ignore subsequent motion detected messages. Also, I now realize the default reset motion preference should be changed to 61 or 62 seconds to allow the first countdown timer to be extended if motion is detected exactly at the end of the hardware “blind” period.
Here’s what would happen in a couple of different scenarios:
Test Mode Active, motion reset preference at default of 61 seconds:
For the next 56 seconds, all motion detection messages are ignored by the DTH (automations don’t go crazy)
At 55 seconds the ignore motion countdown finishes and the DTH stops ignoring any motion detected messages
Between 56 and 61 seconds, if motion is detected, motion reset countdown is extended another 61 seconds, and ignore motion countdown of 56 seconds is started. Go back to step 2.
Otherwise, at 61 seconds, the motion reset countdown finishes, and a motion “inactive” event is sent.
Test Mode Active, motion reset preference set to 7 seconds:
For the next 2 seconds, all motion detection messages are ignored by the DTH
At 2 seconds the ignore motion countdown finishes and the DTH stops ignoring any motion detected messages
Between 2 and 7 seconds, if motion is detected, motion reset countdown is extended another 6 seconds, and ignore motion countdown of 2 seconds is started. Go back to step 2.
Otherwise, at 7 seconds, the motion reset countdown finishes, and a motion “inactive” event is sent. This allows the user to easily test the position of the motion sensor during its testing mode.
Normal mode, motion reset preference at default of 61 seconds:
For the next 56 seconds, all motion detection messages are ignored by the DTH, but of course the sensor itself is “blind” to any motion during this period too
At 56 seconds the ignore motion countdown finishes and the DTH stops ignoring any motion detected messages
When the hardware “blind” period ends at 60 seconds, if motion is detected, the motion reset countdown is extended another 60 seconds, and ignore motion countdown of 56 seconds is started. Go back to step 2.
Otherwise, at 61 seconds, the motion reset countdown finishes, and a motion “inactive” event is sent.
This is the only way I can think of to avoid issues with automations being constantly triggered if a user short-presses the reset button or needs to re-pair the sensor for some reason.
@veeceeoh How about a solution (if possible) that would identify "You are in test mode for the next 2 hours…etc. etc… "- I think your suggestion, though well thought out, would be very difficult for the average end-user to understand - (I had to chart it out and I still have a hard time keeping on top of the details ) -
