@jared.zimmerman Support for Pressure events from the Keen sensor has been added, it was a minor change so I put it directly in Release.
@Angus_M This has been added and is on Github now.
1 Like
No more explicit errors, you should add LUMI/Keen to the driver name 
dev:7722020-05-24 11:22:45.687 pmdebugrefresh cmd: []
dev:7722020-05-24 11:22:45.679 pmdebugdirty model = RS-THP-MP-1.0, clean model=RS-THP-MP-1.0
dev:7722020-05-24 11:22:45.572 pminfogetDriverVersion() = v0.6.1.0525
dev:7722020-05-24 11:22:45.568 pmdebugrefresh() model='RS-THP-MP-1.0'
dev:7722020-05-24 11:22:45.562 pminfoinitialize()
--- Live Log Started, waiting for events ---
I would, but it will cause issues with the Package Manager unless I add support for alternative/old names in my manifest generator. Maybe another day 
1 Like
First off, thank you for your work on these. Very polished and love the attention to detail.
For the button (WXKG01LM, 2015?), would it be possible to add an option to have the held event be sent immediately instead of waiting for release (default for the old driver is immediate)?
Version: v0.6.1.0524
1 Like
For the double button (WXKGO2LM, 2016). It is not differentiating between buttons 1, 2 or 3 (both pressed same time) instead only showing it as button 1. Debug does show each as a different endpoint though.
[dev:1227] 2020-05-27 02:45:52.518 pm [debug] parseButtonEvent() (btn: 1, btnModified: 3, endpoint: 3, physicalButtons: 3)
Version: v0.6.1.0524
model: lumi.sensor_86sw2Un
@markus I know you said you're planning the remainder of the device drivers. Wondering if you wouldn't mind adding a particular feature to the Aqara vibration sensor driver when you're near release. Keith had previously created an open/close attribute based on the vibration sensor angle. It works very well for my use case, but on HE that sensor keeps dropping, regardless of battery strength and a close proximity to the hub and two Xiaomi compatible repeaters.
I'd normally just attach it to my Aqara hub in this case, but then I only get active/inactive based on any activity.
1 Like
I'm a little confused here. How would it know if you are going to hold the button at the start/immediately? Prediction?
Or do you mean if you hold the button for an extended period of time then after 1 second it'll treat it as a hold and not wait for the button release?
If the latter (assuming this is how button old work as I haven't checked) you could look at rule machine to do this. Have a rule that when the button is pushed trigger a rule. Then have a delay of 1 second before checking if the button is still pushed. If still pushed then treat it as a hold, so push a virtual button called hold. If not still pushed then treat it as a push and push a virtual button called push. So then trigger tasks of the virtual buttons.
To stop this delay happening all the time even for a quick push you could probably use the release event to trigger another rule that determines if the push/hold rule finished (by using a variable at the start of the hold rule equalling 1 and then changing it to 0 at the end and cancelling the push/hold rule from the release rule) If it's still 1 then it was just a push as the delay didn't finish.
Immediately (as soon as) the determination of what a "held" event constitutes. The new driver has a preference, Millis for Hold: Set the minimum number of milliseconds to count as held. The previous driver would send "held" as soon as the configured amount of time passed (released or not). This new driver doesn't seem to pass "held" until both the time has elapsed AND the button has released.
I am requesting an option that would let "held" function like the previous driver.
Ahh ok. Yes that would be better at the driver level than using rules like I wrote above.
1 Like
Possible, yes, I did not implement this using timers, they seems to cause strange behavior at times due to them requiring a DB lock. So when possible I avoid them. To do what you want I would need to use timers, I'll consider it, but it is not as "clean" as the current implementation based solely on events.
Yes, that will be there, I'm looking at alternatives on how to best implement that, he used Euler Angles and it is a smart way of doing it, I might do the same.
I need complete debug logs of all types of button presses (including the description log message). This is an older device than the models I have and there must be some difference in what is sent vs the newer model. If you send me the logs in a PM I will update the code to get the buttons right.
2 Likes
I'd rather you keep the drivers as clean as possible. I'd rather not mess with the integrity of it. I can use the previous driver for the one device that my wife complained about the hold function. 
PM sent. Thanks again.
Hi @markus,
Any plans to provide support for the Xiaomi Aqara Vibration Sensor? (model DJT11LM, lumi.vibration.aq1)
Iām currently using @veeceeoh beta driver which appears to be working ok... but I am seeing an odd error message in the logs (not sure if related to a bad inclusion of sensor to HE - took a few attempts).
groovy.lang.MissingMethodException: No signature of method: user_driver_veeceeoh_Xiaomi_Aqara_Vibration_Sensor_1089.checkPresence() is applicable for argument types: () values: (checkPresence)
Cheers!
Just grabbed the WSDCGQ11LM For attic temp/humidity and installed it today. It only goes to 50C or 122F which is likely too low of an upper range for an attic but I figured why not get one to test out. The driver is working great. I like the Last Battery Replacement Date option.
For anyone interested I created a mask for the Xiaomi motion sensor see here. I am using these outdoors so I needed to lower/remove the false positives.
4 Likes
Previously in this thread @markus said he would be creating drivers for all the devices. I knew this and asked a question relating to the vibration sensors which he answered two posts prior to this one.
Short answer: Yes.
1 Like
Great! Sorry, missed that part of the thread...
Nice work, mate. You're getting your 3d game on too!
1 Like
@markus I'm sure you're aware of this Lumi API doc. It's a bit old, but perhaps useful to you in some way. I came across it when looking for some info on Yeelight Bluetooth Mesh bulbs.
1 Like
@markus
Not sure if this is an issue of yours or HPM
[app:129] (http://192.168.0.10/logs/past#app129)2020-06-02 21:17:49.097 errorError downloading https://raw.githubusercontent.com/markus-li/Hubitat/release/apps/expanded/smartly-enhanced-dashboard-expanded.groovy: groovyx.net.http.HttpResponseException: Not Found
It doesn't exist, yet, will sort that out. The downside of to much automation 
thank you for pointing it out.
2 Likes
