Those drivers are amazing, I use them since a couple months on my HE, they have worked fine. I cannot thanks Markus enough, he’s my hero.
I hope the drivers will keep working on HE. Another solution could be a new OLL hub 
2 Likes
As you know I wrote a very popular app ‘Device Watchdog’ (HE). This app relies on the ‘Last Activity’ to make sure things are up and running. This change basically kills all Xiaomi device support for users of your drivers (me included) in DW. 
Please reconsider updating the ‘Last Activity’ within your drivers.
Thanks
4 Likes
I know, this is an issue, the problem is that there is no way of controlling when Last Activity is updated. Updating Current State (which the presence functionality requires) does so automatically.
If you could allow a check against the Current State lastCheckin as and alternative to Last Activity that could be solved since this represents basically the same thing as Last Activity (in other drivers) but with some enhancements like Recovery etc.
I’d be happy to work with you in making sure this works reliably 
EDIT:
Another alternative could be to just look for the presence attribute, if set to “present” the device is there, “not present” it is not.
1 Like
@markus, so I took a quick look at your code for a motion sensor after seeing @BPTWorld’s question…
I am curious why you’re not allowing the Hubitat Event system to determine if the state of the attributes have changed, but rather forcing it to either False or True…?
Wouldn’t simply removing the “isStateChange:” parameter in all of the calls below resolve the issue so that The Device Watchdog App would continue to work properly? Am I missing something? To be honest, I have not tried to follow all of the logic in your code, but a quick search of this one driver made me curious… 
void sendMotionEvent() {
logging("sendMotionEvent()", 1)
Integer resetTime = resetTimeSetting != null ? resetTimeSetting : 61
runIn(resetTime, "resetMotionEvent")
sendEvent(name:"motion", value: "active", isStateChange: false, descriptionText: "Motion Active")
}
void resetMotionEvent() {
logging("resetMotionEvent()", 1)
sendEvent(name:"motion", value: "inactive", isStateChange: false, descriptionText: "Motion Inactive")
}
void resetToActive() {
logging("resetToActive()", 1)
sendEvent(name:"motion", value: "active", isStateChange: true, descriptionText: "Motion was Reset to Active")
}
void resetToInactive() {
logging("resetToInactive()", 1)
sendEvent(name:"motion", value: "inactive", isStateChange: true, descriptionText: "Motion was Reset to Inactive")
}
2 Likes
The two sendEvent calls with isStateChange set to True are triggered solely by commands and are meant to fire an event every time pressed. This is not part of normal device operations.
Whenever it is possible (and doesn’t make more sense with the opposite) I do use “isStateChange: false” (baring some mistake somewhere, but that should have been found by now). The big issue with using Last Activity inside my drivers occur when the attributes notPresentCounter and presence are updated as part of the device NOT being present. Every time that occurs and there is a change in Last Activity.
I’m having an issue with my contact sensors not receiving a closed event reliably. I have sensors on my freezer, fridge, and a couple doors. I will open the Fridge, and it will receive the open event, and I will close it a few seconds later and it will still show it as open. I will have to open the door again and then close it again and it will then receive the closed event. This is happening on all of my xiaomi contact sensors.
You can see on the events for my Refrigerator Door that it received open, but not closed. On picture 2 there is a red line. That is when I realized that the door sensor was still listed as open. So I opened the door and closed it again to the get the closed status.
I would say that this has been happening for the past 4 months or so.
I also tried to re-pair the xiaomi sensor to the hub yesterday, but it is still happening today.
I’m using the latest drivers, installed through Hubitat Package Manager.
Any suggestions?
For monitoring if Xiaomi devices are online / present, DW is so close to working using the special tracking ability. The issue is the “Trigger Value for attribute” does not distinguish between ‘present’ an ‘not present’
This shows what is reported when the attribute value is ‘present’. If the attribute value is ‘not present’ then nothing is reported.
Perhaps I am misunderstanding how to use Special tracking.
2 Likes
First I assume you have taken steps to verify the sensor is connected to the hub. It is really curious that you are having troubles with fridge / freezer doors. I have the same issue. It’s the issue I have had the longest. I have tried everything I can think of. I have an Ikea repeater with line of sight to the sensor and maybe 15 feet away. I’ve tried different placements. Having the magnet the moving part and the non moving part. I have read that contact sensors do not like it if the magnet slides in from the side. Instead they need to come together perpendicularly. Still not reliable.
I wonder if the metal of the door is some how causing the problem. Out of curiosity is the door also metal? I wonder how many other people are experiencing the same problem.
Good call out, and yes I have. I can always just open and close the door again and it fixes it. I believe it always receives the open event.
They are opening/closing the same way they would on door/door frame.
The chest freezer one is about the same scenario as yours where the repeater is about 15 feet away. I will try moving the repeater so it is about 2 feet away from the contact closure and see what happens.
I don’t believe I had this issue until switching to these drivers. I could be wrong… but I may switch back to the original ones from veeceeoh on the fridge and see if it always receives the event.
Two fridges, 6 sensors. I took the one that gave me the most trouble and moved it to a door leading to the garage and it has been working perfectly. This why I’m perplexed as to why it doesn’t work on the fridge.
Using this with Device Watchdog’s ‘Special Tracking’ option will give us what we need. Thanks
6 Likes
Hi @markus
I’m using these drivers on HE at the moment and I’ve noticed that with the latest release, as mentioned above, they no longer work with @BPTWorld’s Device Watchdog app.
It has been said that using ‘Special Tracking’ in DW will be OK as a work round.
Unfortunately for me this is not giving the information that I need.
Just a couple of questions for you.
Is there a specific reason why you had to do this?
Would it be possible to reverse/make some changes to your drivers so this functionality works again with Bryan’s code.
Thanks.
@hoveeman I think the below would apply to your situation as well. Even though you have it happen to all of your sensors. Have you tried changing batteries?
That is truly odd, exactly which model is it and which year was it purchased? I’m trying to track down if maybe there are two different packets being sent and my driver listens for one and @veeceoh for another. Then it just so happens that the one I’m listening for is not reaching the driver under bad sending conditions. This is very far fetched, but could be worth looking for.
What is it that is missing for you when doing it that way?
Yes, it’s the Presence and Recovery feature. What is it that has changed for you in this? I have not made any specific changes to this part of the code for this release.
You can disable the Presence and recovery feature in Settings, though I wouldn’t really recommend that.
I ordered 20/05/2020. I turned debugging back on and will watch out for anything interesting.
Almost forgot, the model is MCCGQ01LM.
@markus
Missed close event
Logs
Other than the close event missing close event nothing looks out of place.
Opened and closed the door twice.
And the logs
I gave up on this months ago because I couldn’t prove/disprove it wasn’t a signal problem. Let me know if you see anything. Meanwhile I have the code reactivated and will watch what is going on. Can it be an issue is the open/close events are only a few seconds apart.
1 Like
Thanks @markus for the reply! Yep, I have. New batteries.
I moved the refrigerator over to the veeceoh driver after my post and I haven’t had any missed messages all weekend on the refrigerator. Every open and close has been coming through.
I’ll have to track down when I bought them, but it was probably 2 years ago.
I’d be happy to do any testing for you. Really appreciate our hard work on these.
1 Like
@markus fwiw, I have the exact same observation. Curiously, also with a contact sensor that is on my fridge door.
And similar to @hoveeman, there are no missing events with the older (Keith G’s) driver.
That’s good enough, then I know what to expect in signaling.
There must be two different events, I’ll look into it, this is very odd indeed.
2 Likes
Hi @markus - sorry this has taken so long. Here are two screenshots:
- From the info log
- From the events page for the same device
The events marked in red are ones that don’t show up in the device event page.
@markus
I’ve just purchased some Iris contact sensors 3320-L.
They work well on HE using the Iris V1 Contact Sensor.
Would it be possible to modify your Xiaomi/Aqara contact sensor driver to work with these devices or is this a rabbit hole you do not want to go down.
Just wondering as I like the ‘presence’ option your drivers provide.
If it’s a yes, what info do you require.
If no, no problem but just thought I would ask.
Thanks.
EDIT: Interestingly when I paired the device it initially pairs using your Zigbee - Generic Outlet (with Presence) driver.