I’m thinking the change in DNI was due to me resetting it again.
I’ve re-paired 3 motion sensors which still haven’t reported any battery status in over 4 hours, and are still working. Yet the two contacts I paired have. It’s late here, but I’ll re-pair tomorrow and monitor then report back.
I also didn’t think this was a driver issue, I’ve not changed any drivers for a long time. Unless something is causing some real interference here, I’m at a bit of a loss. I did roll back the Update, that didn’t appear to make a difference. But I’ll be trying again tomorrow.
small update. All my motion sensors have started to report in hourly now, after I re-paired yesterday its taken around 9 hours for this to start. I re-paired 3 again yesterday evening, and although they worked through the evening not one reported in. But in the early hours, they started reporting again.
Very strange episode, and cant put my finger on any reason this happened at all. I'll re-pair the remaining buttons and contacts today and continue monitoring. But many thanks for the great response.
I think that it could be related to the hubitat reboot for rimware update, where maybe Xiaomi devices lost connection for a while (even if actually they are through a repeater and not directly to Hubitat).
I had 2 of them dropped out when upgrading to latest 2.0.9 hotfix but none dropped after 2.0.9 main upgrade (I have around 25/30 of them mixed between contacts, temperature, motion, vibration, water)
@veeceeoh I've sent a PR on GitHub for Aqara Motion Driver because I've found an issue: actually the resetToMotionInactive() function it's called after each motion detected, regardless other motion detections in the meantime.
This means that, especially if you have modded the sensor with 5 secs hack, it could generate a false inactive motion.
I'll explain with an example: consider that you have a modded sensor (so 5 secs between motion detection) and set the reset to inactive at 8 secs. Timeline (let's use Sec. 0 as first event to be easier) will be:
Sec. 0 => Motion detected, schedule inactive after 8 secs
Sec. 5 => Another motion detected, schedule inactive after 8 secs (13 secs from start)
Sec. 8 => Motion inactive by first motion event
Sec. 13 => Motion inactive by second motion event (do nothing because already inactive)
In PR you can see the workaround (basically at sec. 8 checks how much time has elapsed from last motion, if greater than "reset to inactive secs", it resets, otherwise it will reschedule the reset inactive at "reset to inactive secs" after last motion).
Parameters delayInSeconds - How long to wait in seconds until the handler should be called, don't expect that it will be called in exactly that time. handlerMethod - The name of a handler method in your driver or app. The method name should not contain parentheses. options - Optional values to control the scheduling of this method
~ overwrite - defaults to true which cancels the previous scheduled running of the handler method and schedules new, if set to false this will create a duplicate schedule.
~data - optional data to be passed to the handler method.
~ misfire - If set to "ignore" then the scheduler will simply try to fire it as soon as it can. NOTE: if a scheduler uses this instruction, and it has missed several of its scheduled firings, then several rapid firings may occur as the scheduler attempts to catch back up to where it would have been.
Most important in that documentation is the overwrite option, which defaults to true.
Here's what actually happens with your example:
Sec. 0 => Motion detected, schedule inactive after 8 secs
Sec. 5 => Another motion detected, cancels previous schedule and sets new schedule inactive after 8 secs (13 secs from start)
Sec. 13 => Motion inactive
Another way to look at this is that every time motion is detected, the motion inactive call is delayed by another X seconds (X = the user's setting).
So your workaround should not be necessary. If you are not seeing the behavior that I've described, please let me know because then we should check with Hubitat staff on the use of the runIn() method.
Hmmm I'll do some other tests tomorrow morning.
I've tried to apply the workaround because some of my lights (powering off whet motion stops without delay) where powering off even when I was moving under them, but maybe motion wasn't detected by the sensor?
EDIT: Looking at the events, even before I applied the workaround, seems to be working as you describe, so the problem is somewhere else...
My experience with my Aqara Motion Sensors is that they sometimes aren't triggered if I'm not moving much after I've entered a room.
With the hardware hack, I believe a good way to help with this is to set the reset to no motion time to at least double (or triple) the hardware reset time. So maybe 12-15 seconds?
Another way to handle it might be through Rule Machine. Set the reset to 1 second, which means a motion active event is generated every time the hardware detects motion. Then if possible, set up a rule that takes action if nomotion detected event has occurred for X seconds. In other words, the rule is ignoring motion inactive events, and only looking at how long it's been since the last motion active event. To be honest, though, I am not sure if that's something that could be accomplished in RM.
Hi all, I've had a look through this post and also searched the forums. Has anyone got any information about these Xiaomi Mi Mijia ZigBee Smart Sockets. I was hoping to find out if they function on Hubitat
If anyone is interested, banggood has the xiaomi motion sensor for 12.99 and the aqara dual relay for 18.99. I have both and they work well in Hubitat. And the relay works in USA with 60Hz, I tested a LED bulb, a fan and a blow dryer on hi-zero issues
New member 1Day old, Having difficulty in getting my Aqara wall switch to work.
I have the QBKG04LM no neutral (model number:- lumi.ctrl_neutral1)
I have loaded the above code, HE picks up the device but then will not operate, is there any other codes i have to load.
I'll add it to the master list in the opening post of this thread, thanks.
Personally, since I'm in the U.S., this wouldn't work for me. I am still waiting to hear about pricing of IKEA's Fyrtur Smart Blind solution (and if they will offer more than just grey shades!)
I don't own one myself and don't plan to buy one, so the best I could do is make a "blind" attempt at porting the SmartThings device handler over. I'd probably need to work with someone who owns one to get it fully functional, though.
Since @guyeeba has mentioned the new Aqara Smart Window Shutter Motor (model ZNGDZJ11LM), I want to point out in my search for more information about it, that there is also a new B1 revision of the Aqara Smart Curtain Motor (model ZNCLDJ12LM) which is fully wireless capable, making use of a rechargeable battery pack:
Wow Superb, Thank you very much for your quick reply.
all now working, even better than on Smartthings !
It would control and stayed paired fine on ST but if you manually switched it on or off, the state wasnt getting back to ST, it does here. EXCELLENT STUFF
Yes from what I read the bottom part is the battery pack. However if you have power near your curtains you can still just connect power directly and not use the battery.
Also for this new curtains motor, it uses a new curtains rail. however if you have the existing curtain rails from the older aqura curtains motor, it's backward compatible and you can just swap the new curtains motor on the existing curtains rail.