Ryan, could you add the debug off option to this driver? I modified it to have 1 minute timeout but adding the debug toggle is beyond my limited knowledge.
Thanks.
Yes, I set away by a button inside the door that does everything (opens garage, turns off lights, sets HSM, etc). I don't like using presence for departing since I like to know that the system is actually arming. What good is a security system that isn't armed when you leave, right?
However, if you're just looking for something to cope with the backups overnight, you could use a rule to disable at 1am and enable at 4 am (or whatever time). That way you wouldn't get those ghost leaves in the middle of the night.
Yeah....I'm going to add the debug toggle in later today....but I've been dealing with a bunch of work crap. Damn job! lol
Like I said, this ported directly from ST with no modification at all....thought that was pretty cool for a change.
I was actually going to add another custom command that you could pass a parameter too....disableAutoReenable. This way you would input the number of minutes you want the sensor disabled for and then after the period of time it would automatically re-enable. Could also do the reverse if there's interest in that...but i figured most folks would use it the way that @Somel needed...to disable for the nightly backup causing his fob to go sleepwalking. 
1 Like
I think I need to get the damn thing into a therapist.
Either that or get it some sleeping pills.
@mike.maxwell
Quick update with the 2.0.7 release.
Before the .07 release the fob was having the occasionally drop off/on during the early morning but was relatively stable.
With the .07 release I'm starting to see the exact same behaviour with the fob dropping several times during the day (I work from home).
My assumption is that with the update the fob will need some time to readapt to the mesh (no other device shows this behaviour) and eventually will settle in.
I will post an update in the weekend.
well as you saw in the release notes, there were no changes to the zigbee stack in 2.0.7, and no changes to the presence reporting functionality of the presence sensors.
The battery reporting update simply allow the driver to send a battery percentage event more often than before.
So whats changed between 2.0.6 and 2.0.7 in regards to this device?, a few hub reboots...
Exactly i didnt say it was the update itself but rather the act of updating.
Anyway just reporting the findings and as I mentioned let's hope it settles in as it did last time after a few days.
I'm very curious, I never had an unexpected drop off of my presence sensors, but thinking that you are the number one defender of Xiaomi, maybe it's something related with the repeaters? As you know, I have 2 separate zigbee networks, one for Xiaomi and the other for everything else, I'm tempted to move one of my arrival sensors to the Xiaomi network but my house is small, so maybe it just connects to the hub with no effect, could you look if this particular arrival sensor is connecting through an ikea repeater? What is the average RSSI of this sensor?
Are we going to blame Xiaomi now for all the evil in the world?
Besides is not only me with issue with this behaviour.
Additionally currently I have 0 repeater on the mesh. Everything is connecting to HE hub.
Come on, not blaming Xiaomi, just asking, analyzing data. My Xiaomi sensors are working perfectly.
So you have no repeaters, and this arrival sensor, where is located when it dropped the network? Near the hub? RSSI?
Interesting, how many devices currently?
It happens at different locations from 1m to 4m.
what did you set your timeout to?
These sensors do not appear to be very strong you might have to add a few repeater devices to strengthen your mesh
and how many zigbee end devices do you have?
2 isolated mesh one for lights through hue 30 lights.
1 directly to hub with no repeated.
15 different Xiaomi devices
samsung presence v4 1 fob..
Also what zigbee channel are you using?
He 20/25 Hue
Hey @Somel I wanted to add a data point for you so we could compare results (and since I rely on these sensors quite a bit).
I audited the last 100 events from both the sensors on myself/SO's keys, as well as sensors in two cars. All 4 sensors last 100 events contained no false away reports nor did they contain any returns that were inaccurate.
I'm running Zigbee on Channel 15 and have a couple ST outlets in the room closest to the garage/entry so likely the fobs are hitting those before the HE.
let me know if any information from me can assist you in your troubleshooting.
Well i had no false positives/negatives after the .124 update it seems a few extra reboots make it more stable.
Let's wait and see.
Has anyone had their battery status report in on the events logging screen?
I just updated to .124 and have to wait until they come home this afternoon to check
but with 2.0.7 updates prior to .124 I still had not seen any battery reporting (last night when they were home)
The main device page just stays stuck with the last report weeks ago when I did a battery change
arrival and depart as always still works fine
