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.
The Iris 3320-L are 2nd Gen Iris Contact Sensors. These are fully Zigbee HA1.2 compliant devices. You should be simply using the ‘Generic Zigbee Contact Sensor’ driver on Hubitat.
2 Likes
Yes I have changed it to that since I posted above. Working fine with it. Still like to use markus’s driver though if possible.
2 Likes
Hi Markus,
I have an Aqara D1 Switch (3 buttons) Neutral - QBKG26LM
Using latest driver : v1.0.0.1025
lumi.switch.n3acn3
Would you be be able to please add support for this? Many thanks
[dev:203](https://192.168.3.21/logs/past#dev203)2020-11-12 14:06:37.557 [warn](https://192.168.3.21/device/edit/203)Unknown model (lumi.switch.n3acn3) - PLEASE REPORT THIS LOG TO THE DEV - description:read attr - raw: 78DB0200002E050042126C756D692E7377697463682E6E3361636E33, dni: 78DB, endpoint: 02, cluster: 0000, size: 2E, attrId: 0005, encoding: 42, command: 01, value: 126C756D692E7377697463682E6E3361636E33 | parseMap:[raw:78DB0200002E050042126C756D692E7377697463682E6E3361636E33, dni:78DB, endpoint:02, cluster:0000, size:2E, attrId:0005, encoding:42, command:01, value:lumi.switch.n3acn3, clusterInt:0, attrInt:5]
[dev:203](https://192.168.3.21/logs/past#dev203)2020-11-12 14:06:37.514 [warn](https://192.168.3.21/device/edit/203)Unknown model (lumi.switch.n3acn3) - PLEASE REPORT THIS LOG TO THE DEV - description:read attr - raw: 78DB02000012040042044C554D49, dni: 78DB, endpoint: 02, cluster: 0000, size: 12, attrId: 0004, encoding: 42, command: 01, value: 044C554D49 | parseMap:[raw:78DB02000012040042044C554D49, dni:78DB, endpoint:02, cluster:0000, size:12, attrId:0004, encoding:42, command:01, value:LUMI, clusterInt:0, attrInt:4]
[dev:203](https://192.168.3.21/logs/past#dev203)2020-11-12 14:06:37.384 [info](https://192.168.3.21/device/edit/203)Recovery feature ENABLED
[dev:203](https://192.168.3.21/logs/past#dev203)2020-11-12 14:06:37.317 [info](https://192.168.3.21/device/edit/203)getDriverVersion() = v1.0.0.1025
[dev:203](https://192.168.3.21/logs/past#dev203)2020-11-12 14:06:37.294 [info](https://192.168.3.21/device/edit/203)initialize()Hey @KillSIG, I use the QBKG25LM which (I’m guessing) is identical to the neutral version in software except for its identifier. Everything in @markus’s driver works for me on that except for button disconnection, so at the risk of being cheeky, give this fudged version a try.
All I’ve done here is cludge in the model identifier n3acn3 for the neutral version alongside l3acn3 for the parasitic live version.
1 Like
, Thanks!!Excellent! Bringing the bodge! 
Hi @markus
In last 2.2.4 update there has become som issues with the aqara drivers , contact sensor to be specific in my case. The sensor works but a wrong message comes in logs.
Do you have time to check? Mike Maxwell wrote about it…
Thank you for the nice drivers and good work.
/Mattias Sweden
2020-11-17 18:39:01.125 warnUnable to execute hubAction:delay 2000 sent from Fönster Sensor Allrum Höger, invalid or unspecified protocol.
Mike wrote.
single command of “delay xxx” is invalid, delay is designed to be used within a list of commands.
hubAction only sends one command.
So as a start any hubAction that’s trying to send a “delay xxx” needs to be removed.
It has taken even longer for me, sorry about that. Looking at this now, it’s an odd issue.
Have you tried my Sonoff Contact Sensor driver with these?
I hope to add these changes to my driver soon enough.
Which version of the driver? The latest release version should not have this issue. If it does, that is very odd, especially with one regarding a delay of 2000, There is only one place where that delay length is used, and that piece of code is a method not even called in that specific driver.
These errors regarding delays are annoying to see I’m sure, but they have no ill effects I’ve been made aware of. With that said, all of these issues should be fixed in my last update released long before 2.2.4 came out. I was contacted by them regarding this when I was still over in the other community and did add fixes in accordance with what I was told would be added.
Please make sure you have the latest version of my drivers and report if the issue is still seen there.
2 Likes
Hi… Thank you for fast response. I had an old driver. Changed now and will se if wrong mess stops… …/Mattias
1 Like
Announcement
Updated all my Zigbee drivers to include the change needed for 2.2.4 since the previous way of doing it, as communicated to me by them earlier, turned out to have been incorrect.
5 Likes
Hi @markus
My hub and the kitchen are on the opposite sides of a bungalow. There is a repeater in the kitchen. When I actually measured the distance to the hub it was too far for the repeater. I added another repeater halfway. The contact sensors are working consistently.
With the caveat that I am ignorant of the nuts and bolts of drivers. I’ll throw out a wild speculation. May be it is not a question of a different event but rather other drivers are using a less precise match on the close event than you are using.
1 Like
I’ve thought about that as well since I have a very strict matching set (I don’t like to have things happening without me knowing about them), I’ve been trying to see any such packages, but have not yet seen any. I could add additional debugging especially for this and put that in the Beta version of the driver if you want to check for it?
@markus Yes sure go ahead with the logging version. In the mean time I’ll remove the middle repeater and see if I can back to the state where the contacts are not working correctly.
I’m having some interesting warnings coming from “Hub” on my C-5 2.2.4.148 hub. They look to relate to the devices where I am using the Presence drivers. Any idea what could cause that?
Yes, have you updated to the latest to version of my drivers?
Yes, I checked the version numbers and they match the latest. They are setup with HPM. Is there anything specific I should look for to be 100% sure?
I’ve had a Hubitat box for just over a year now
And for the beat part it works great
I have aqara switches all over my house ( yes what a nightmare) but when it works it works great now for about 5-6 months it’s worked great apart from the occasional times my hue sensor drops off the network
Now I have a new problem I have 4 IKEA smart plugs around the house ( used as repeaters for aqara devices) I’ve just found out 2 of the have been disconnected for some time now
So I’ve reconnected them to the hub to work the Xmas lights now I’m having loads of issues with my aqara switches not working
( is the hardware you guys are coming out with going to make it easier to work with aqara / Xiaomi devices
Hi @markus I was trying to use some of the attributes of the xiaomi vibration sensor in rule machine as triggers however the attributes currentX/Y/Z cannot function as triggers as they are coded as decimal and not numbers in the driver. Also tiltangle is coded as string,
Can the driver be amended so that all these are numbers?