Are you running the latest version of the handler? I had a report that the current app cannot manage a “?” in the battery indicator anymore so changed it to the more widely used “–” a few days ago. However, not able to test it makes any difference. Something has changed in the latest smartthings app that does not like the “?”.
Yep, latest version. They all pop back in on the list once battery status is received.
I’m running into the same issue with the smart button. I have 4 buttons, first thing in the morning first click doesn’t work. Second click on that button or any other button works fine. Same thing seems to happen after a longer time of inactivity.
Today I ran a live logging session before I pressed the button. This is my first post, not sure about etiquette, privacy of posting a log.
If it would help I can post the log, just let me know what is safe to post and what you would like to see.
1 Like
Looks like the latest app does not like “–” either 
You running ios or android?
Android, on a Oneplus 3T.
1 Like
No point posting a log. The handler code can only process what it sees. If the click does not arrive at the hub then the actions would not run. The handler has no way of differentiating a first or second click. These types of issues are at a zigbee layer outside of my control.
Yes the problem is I can see the event logged in the device handler for the first click but seems it is not passed to smartthings or smartapps no clue of what’s going on, I thought of some kind of sleep mode in the button but if that’s the case the device handler should not receive it
Glad to know it’s not just me
It reappears once the battery level is updated (sometimes takes a few hours)
Hi @cozdabuch, @ZebraBlinds when you next see the problem can either click on the temperature humitdy sensor button and grab a copy of the live logs for me for the device? I would like to see if I can spot any clues as to why you’re seeing this and fix it.
1 Like
Firstly I want to thank a4refillpad and other contributors for the hard work they’ve put into making these handlers, which have all worked very well for me.
I have door/window sensors, motion sensors and buttons. They were mostly easy to connect, with only one taking several attempts before it stuck.
All have been reliable for the time they have been connected (three weeks to six weeks) none have dropped yet…
I have found, like others, that the button was sometimes unresponsive on the first press, but after changing to webcore to run pistons via the buttons (toggle lights, run routines, etc) they seem to work first time.
I paired an additional 5 motion sensors this week with no real drama. 2 stuck first time the remaining 3 on the second go. I now have 7 motion sensors, 2 buttons, 2 temp humidity and 2 door sensors all paired, working and reporting battery. Props to Wayne for the work on the DTH and ongoing ‘support’!
I also noticed the change in behaviour that others have seen once battery reporting kicks in. Before the battery level appears, the motion sensors behave much the same as my ST and Orvibo ones do. That is to say that the sensors will report additional motion as soon the sensor has gone back to no motion. Once the battery level appears Xiaomi motion sensors do not report additional motion for 60 seconds. Not a big issue, just interesting that the sensors behave this way.
1 Like
There is a setting in the DH for this. So I assume once the battery syncs it also sets the desired timeout.
1 Like
No there isn’t. The device will always remain blind to motion for 60seconds following first detected motion. It doesn’t matter what you set the value you refer to. That value just clears the ‘active’ status…but the device will still remain blind…
2 Likes
Correct, there’s some confusion here. I’ll add some text into the device handler settings to see if I can help people understand it a bit better. I might as well use some of your post here @pbrain as the text!
2 Likes
I also paired some more sensors today. 3 more open/close sensors specfically. All paired and stuck first time using the catchall method.
I have three more temp sensors on the way to complete my all room temp monitoring too.
Thanks again to @a4refillpad for the DH
I got 1 button, 2 motion, 1 door sensor working pretty easily and they seem like nice little devices…however, one of my motion sensors is very flaky. It is still connected and sometimes works, but i would say about 90% of the time it doesnt sense motion. Has anyone else seen issues with the motion sensors? Even when next to the hub it still doesnt work well. The other motion sensor seems to work 100%.
I have 7 xiaomi motion sensors and see that 2 of them aren’t accurate. They seem to be kind of hit and miss. Any one else have such issues?
Just seen above message from @mginster. Mr issue is exactly the same.
Can you guys elaborate a bit more on what this means?
I just received and setup my motion sensor. My battery reporting is currently showing “–”. I set the setting for “Number of seconds after the last reported activity that motion is inactive” to 15 seconds.
I have confirmed that after motion is detected and reported in the app/IDE logs, 15 seconds later reporting shows there is “No Motion”. I can immediately trigger a new motion event and have it captured in the app/logs as well.
Are you guys saying after battery reporting kicks in, behavior changes to 60 seconds of reporting inactivity with no way to override it?
Sample Events:
8:44:58 PM: debug Parse returned [name:motion, value:active, descriptionText:Xiaomi Motion Sensor detected motion]
8:44:58 PM: debug motion
8:44:58 PM: debug Parse: null
8:44:58 PM: debug description: read attr - raw: F8250104060800001801, dni: F825, endpoint: 01, cluster: 0406, size: 08, attrId: 0000, encoding: 18, value: 01
8:44:41 PM: debug Parse returned [name:motion, value:active, descriptionText:Xiaomi Motion Sensor detected motion]
8:44:41 PM: debug motion
8:44:40 PM: debug Parse: null
8:44:40 PM: debug description: read attr - raw: F8250104060800001801, dni: F825, endpoint: 01, cluster: 0406, size: 08, attrId: 0000, encoding: 18, value: 01
Update:
Motion sensor has been configured and I am now getting battery reporting. I can confirm motion sensor is blind for 60 seconds after motion is triggered. The setting we have is for allowing ST to set motion sensor to inactive after X amount of seconds.
Strange that prior to device being fully configured (prior to battery reporting) the sensor behavior worked differently. Anyone know if we can modify this behavior in the device handler?
I’m seeing similar battery drain issues on a temp/humidity sensor. Battery dropped overnight from 52% to 36%. Using your DH dated 2017-03-29.
Had no trouble pairing, but wasn’t getting updates initially. Deleted the device, reset, and re-paired (using catch-all method), getting regular updates now.
Will PM you logs from overnight to take a look.
1 Like