Over the last 9 days i have not had a single missed close event using you current contact driver. As you can imagine removing repeaters put my zigbee mesh in trouble. After it settled the events kept coming. For me, I’ll consider it case closed. This makes a strange behaviour even stranger. Must be the year.
1 Like
Hello,
This is my first time posting here, following over from the HE forums. I understand that this is now broken off from the Hubitat side, but was wondering if anyone can help me.
I have these drivers in the Hubitat Driver and the Aqara devices are working great. From time to time they are dropping connection, but fix themselves after some hours. I have an automation with Hubitat where it notifies me so I can check it out.
I also use HomeAssistant, but it seems all the attributes from the entity are not being exposted. For the temp sensor, I only get temp, humidity, pressure, and battery. I was hoping to also get the last contact date so I can view it on my Hubitat Dashboard.
Is this something that is a Hubitat / App issue with pushing to HomeAssistant or something inside of the driver code itelf?
Thanks for any help or pointing me to the right direction.
@markus, the battery status, I wonder if it’s the intention the battery status is updated after the initial pair?
For example, a motion detector with high traffic, since a year it is still 100%
Feedback from an other user : they don’t report battery status reliably if at all. . . . . . .none of them report battery status or voltage apart from the 100% on first pairing.
I can se that to on my aqaras…
Mine has changed between 97, 99 &100 over the last month and the battery is 10 months old.
Xiaomi / Aqara contact sensors are very sensitive to any ferrous or other magnetic material nearby can interfere with the sensors’ ability to reliably detect open/close events. The EMI problems JohnRob reported in his modification are testament to the sensitivity of the reed switch installed in these sensors.
Fridge and freezer doors are usually sealed with a rubber accordion gasket with magnetic inserts to grab the box frame and pull the door closed. Am I correct in assuming your sensor is installed near this accordion seal? If so, you have a magnetic interference problem, most likely. One ugly solution is to build standoffs to hold the sensor and its magnet away from the door a bit. Personally, I’d just look for a sensor that uses a stiffer reed switch and stronger magnet… this should solve the issue.
Interesting. However that explanation doesn’t explain the data (sensor sending events that seen in the log).
Also, reverting back to @veeceeoh’s older drivers makes the issue disappear.
1 Like
It does explain the behavior as described by @hoveeman, which I admit was what I assumed everyone else was seeing. Door opens, sensor moves away from all magnetic fields, reed switch shows open. Door closes, magnetic environment is messy due to presence of extra magnets in the door seal, reed switch fails to close enough to register, but only sometimes.
If changing the driver fixes the issue, obviously EMI is not the dominant problem.
Not sure this matters any, but I have my Aqara vibration sensors paired directly to a mijia hub. I integrate them with Hubitat via Node-RED, using the xiaomi smart home set of nodes.
Anyway, the output for X, Y, and Z is decimal in that integration as well, and tilt-angle is output as a string. So I convert tilt-angle into a number as shown below before using it to trigger a sequence. I do the same for X, Y, and Z.
It’s easily fixed in the driver (even I could do it 
), but if possible I would rather not be manually amending it every time the driver is updated . As it stands those attributes aren’t useable in RM as triggers and the changes probably have no adverse implications.
Just curious, is there a particular reason why you’re using the Xiaomi hub? Is it for connection stability?
1 Like
Yup. Kind of. I’ve seen lots of missing events with the last couple driver releases that get fixed when I use the older drivers from @veeceeoh.
A while back 5 of my 57 devices dropped off so I moved sensors to a Mijia hub and I use NR to bring them into Hubitat.
2 Likes
Very late answer, but yes, this would be in the integration with HomeAssistant.
They report it as part of the hourly check-in. What is reported is the voltage, and it may not change at all for a very long time as far as the device is concerned. The way it is measured isn’t very accurate.
This is probably due to the difference in accepting which packets are considered contact events. The issue with my version is that broadcast events are ignored, under normal circumstances both broadcast and direct events should be sent, I’ve yet to see an instance of only broadcast events. The issue I have is that I would need a log of the actual packet you do get to be certain I catch it without causing duplicate events.
I did, I’ve been very bad at staying active the past mo9nth, too many things to handle at the same time. Sorry for that.
The change could be done, but since it may be a behaviour currently expected by some it would have to be as an alternative setting.
Apart from the contact sensor on a fridge? I’d love to hear more about that.
@markus
Are you aware of the exception that occurs when you try to set the Open and Closed values in the vibration sensor driver. It’s a type casting exception. I have modified the local code and everything seem OK.
I’ve seen this while using tilt angle values from an Aqara Vibration Sensor, and it started sometime in August/September.
Here’s the longer description. I have a vibration sensor on my HVAC return register grille. If I move the grille to just vacuum the filter, there is only one tilt angle change. If I move the grille to remove the filter, there are two tilt angle changes.
I had a NR automation to keep track of filter changes based on seeing two tilt angle changes in succession with 10 seconds. This worked fine from ~April to ~August. Then stopped working - the second angle was never received by HE. Then I realized that it still worked if I moved the grille slowly with a 10-15 second pause between two motions that report both tilt angles.
I repeated this with the @veeceeoh driver, and it worked like it used to work earlier (and without the pause). Off course the sensor is not as stable on HE as it is with your driver, so that wasn’t a viable long-term option.
In the end, I decided that since all my automations are in NR, that I might as well as bring the sensor directly into NR using the Mijia hub.
1 Like
Unhandled Event PLEASE REPORT TO DEV - description:read attr - raw: 10D0010000080100200A, dni: 10D0, endpoint: 01, cluster: 0000, size: 08, attrId: 0001, encoding: 20, command: 0A, value: 0A | msgMap:[raw:10D0010000080100200A, dni:10D0, endpoint:01, cluster:0000, size:08, attrId:0001, encoding:20, command:0A, value:0A, clusterInt:0, attrInt:1, valueParsed:10]
I was not, fixed for the next release.
Ok, that sensor I don’t use much, I’ll have a look at that then. There must be more of the broadcast packets that I filter since they are not what would normally be needed.
Thank you, I’ll see what I can sort out with these, I’ll have to move some devices back onto a HE hub.
Which device and which driver is this?
1 Like
Xiaomi contact sensor.
1 Like
I think you have one small mistake in preferences of temperature driver.
You have Humidity Resolution twice in preferences. I guess the second one should be Pressure Resolution.
yes, I noticed that, it’s fixed in the next release. thank you 
1 Like