It appears that the single-button model may send messages when it's pressed and when it's released.
However, I don't think you've assigned the device driver I linked to, because it would never post "Button triggered" log messages.
Please try going to the device details page, assigning the Xiaomi Aqara Dual Button Light Switch driver, click "save", then turn on debug log output, "save", and post your log entries that occur when you click the button, hold for a few seconds and release. That should produce the Zigbee messages in the log that I need to make the device driver compatible.
I think I confused this model with a different button.
Does your button look like this:
If yes, then you should use the āoriginalā Xiaomi Button device driver. It supports button hold, single-click, double-click, triple-click, quadruple-click, and also quintuple-click.
EDIT: I have released a new version of the round button device driver; please see my next post (below).
For anyone who downloaded the updated code for the Aqara Leak Sensor driver, @NoWon alerted me to an issue that shows an error on the log page and prevents the wet / dry status to be sent to the hub.
I have fixed the code, but I wonāt be able to test it until I get home in about 8 hours.
Thanks again for these drivers Keith. Just received my Aqara button today. Pairing was easy. Hope it stays paired, as this thing is so cool, and an incredible deal vs a Flic. So far Iām using single-click, hold, double-click and triple-click with the Button Controller app. All are performing perfectly.
@veeceeoh: Would it be possible for you to add a offset configuration field for the Aqara motions sensors, to compensate for variances in there illuminance reporting? Thanks!
The lux upper limit of the Aqara Motion Sensor is 1000 or 1200 (depending on model revision) and does not seem to be highly accurate.
Although a lux reading message is sent by the sensor when motion is detected, the order of lux and motion detection messages is not always the same (i.e., the lux value message may be sent before or after the motion detected message.) With that in mind, a change in lux value should probably be evaluated before evaluating whether motion detected = true in an automation app rule.
Is anyone else seeing their Xiaomi (original) motion sensors not going inactive after a while? Itās normally fine after the hub has been rebooted, but within a day or so the runIn() call doesnāt seem to do anything.
Iām wondering if thereās a resource thatās not being freed somewhere, although I can only assume that itās in the Hubitat firmware, since the DTH looks perfectly fine.
Perhaps not related, last night I discovered that all events of device subscribed to by apps were being ignored. I was pulling my hair out for an hour before deciding to reboot and then it was all working fine again.
Since I still consider my Hubitat to be "in testing", I have very few apps, only 6 RM rules, and just one WebCore Piston. I see no reason why I would need to reboot my hub because of resources being bogged down in any way. A look at my logs shows very frequent inactivity, so I am becoming increasingly frustrated with bizarre issues that are magically cleared by a reboot.
But enough of my rant. Have you checked your events list for the motion sensor to see if the motion - inactive event was sent?
Yeah, I have checked the events list in the past and the inactive event was definitely not being sent.
I have 3 cats and they trigger the motion sensors quite a lot, especially the ones on the stairs (one likes to sleep on the stairs). From a quick scan of the logs, each motion sensor is triggered about 40 times in a 24 hour period. There are 3 sensors in active use at present in the same area so that's 120 calls to runIn() in a day. It seems to take around 2-3 days before I have to reboot the hub, so if there's a limit on the number of timers used by runIn() and there's a resource leak then that limit would be about 256.
Of course I could be entirely wrong in my diagnosis, but without access to more detailed logs of the internals of Hubitat it's hard to be sure.
I find that really hard to believe, as runIn() is used by Apps for all kinds of delay-based automations. If there are limits on how many / how often it and other chon schedule calls can be used per day, it hasn't been mentioned anywhere.
Sounds like something to ask the Hubitat folks about.
I hope you're right about that. It would certainly be a surprise. I've enabled info and debug logging in a couple of the motion sensors - unfortunately that doesn't seem to include any debugging for calls to runIn()
I've added some debugging code to my version to see if there's a possibility that the device state isn't as expected. I'll see how it runs for a few days.
As I understand it, the device driver code is executed once for each message received from a device or command sent, and then exits. But, the runIn() call initializes a scheduled execution of the driver code, and at the scheduled time, it goes right to the function named in runIn() and then exits.
Since I can't add any log message above the "level" of device driver execution, all I can do is put a confirmation info log message in the function that resets motion to inactive, and it's no more helpful that checking whether the inactive event was sent.
So if the system is not honoring scheduled execution requests, there's no way to have the device driver code let you know about that. It would require system or admin level logging.
