I think I've said it before, but I'll say it again.
I am not a paid developer. I am an end-user. I am not a coder by trade. I took up learning Groovy language last year with the purpose of helping to improve Xiaomi / Aqara Zigbee device handlers for SmartThings, and after buying my Hubitat hub, I ported them over. For free.
I don't receive anything for what I do, other than the custom device drivers and apps by other users who have also decided to freely share the products of their time, energy, and efforts.
In fact, I pay for what I do. I have bought devices just for the purpose of helping others to be able to make use of them. I can't really afford to buy loads of devices I might not actually use myself, so this makes the testing process a lot more difficult, not having them in front of me to work with.
Furthermore, since this is not my paid job, I can only use spare time to maintain, improve, and introduce device drivers, as well as to field a constant stream of questions from other users on both platforms. Spare time that I don't have a lot of. So even though it shouldn't have to be said, apparently I have to ask for some patience.
But if you really need to know how I am going with the update, here you go:
I have been working on updates to the entire set of Xiaomi / Aqara device drivers for Hubitat. This includes working adding support to some device drivers for a number of recently released new revisions of some Aqara devices I don't own myself.
Add to this the fact that I have been having major issues with the overall speed of my Hubitat hub, despite removing all custom apps. So while I have been trying to troubleshoot that for more than two months, at the same time I've working on updates for numerous Hubitat device drivers and SmartThings device handlers. If you look at my recent post with the table showing all Xiaomi / Aqara ZigBee devices and their various revisions, you'll see that there are a LOT of them.
The slowness of my Hubitat hub directly affects the ability of some of the device handlers to execute time-sensitive operations as expected. One of them is the device handler for the "original" Xiaomi Button, which is making it very very difficult to test improvements I'm trying to make to the reliability of the software-based button held feature. But since you've mentioned it @mike, I assume the "original" Xiaomi button driver is the other one you're really hoping can have human readable date/time stamp events when the button is pushed to use in a Hubitat dashboard. With that in mind, I'm going to share a beta update for that device driver (see below) which only includes the custom attributes for human readable time/date stamps as well a big update to the Aqara button driver to maintain consistency.
[BETA] Hubitat Device Driver for Xiaomi "Original" Button version 0.85b
Device driver code available here.
Changelist
- Renamed custom attributes
lastCheckin
,buttonPressed
,buttonHeld
, andbuttonReleased
tolastCheckinEpoch
,buttonPressedEpoch
,buttonHeldEpoch
, andbuttonReleasedEpoch
, respectively, - Added custom attributes
lastCheckinTime
,buttonPressedTime
,buttonHeldTime
, andbuttonReleasedTime
, which are used to generate human readable time/date stamp events - Removed all references to WebCoRE for use of Epoch-time/date stamp custom attribute events and replaced with "Apps that can use Epoch time/date stamps"
[UPDATE] Hubitat Device Driver for Aqara Button version 0.6
Device driver code available here.
This update takes v0.55b out of beta as a full release. It now provides support for all three known versions of the Aqara Button:
Model WXKG11LM (original revision)
- Single click results in
button 1 pushed
event - Double-click results in
button 2 pushed
event - Triple-click results in
button 3 pushed
event - Quadruple-click results in
button 4 pushed
event - Button release is automatic, based on user-adjustable timer, resulting in
button 0 pushed
event
Model WXKG11LM (new revision)
- Single click results in
button 1 pushed
event - Hold for longer than 400ms results in
button 1 held
event - Release of button results in
button 1 released
event - Double click results in
button 1 doubleTapped
event
Model WXKG12LM
- Single click results in
button 1 pushed
event - Hold for longer than 400ms results in
button 1 held
event - Release of button results in
button 1 released
event - Double click results in
button 1 doubleTapped
event - Shaking the button results in
button 2 pushed
event
Changelist (from v0.5)
- Changed driver's name to "Aqara Button"
- Added specific device join names to all the fingerprint entries
- Removed
deviceId
s andendpointId
s from fingerprint entries - added compatibility for the new revision of Model WXKG11LM (ZigBee reported model:
lumi.remote.b1acn01
) with help from Hubitat user @guyeeba - changed event type functionality for Model WXKG12LM to include
DoubleTapableButton
andReleasableButton
capabilities, so thatpushed
,held
,doubleTapped
, andreleased
events are all assigned tobutton 1
, and shaking the button results in abutton 2 pushed
event. - added a routine to determine model at time pairing / when saving preferences and set appropriate number of buttons available to Hubitat apps
- added
buttonPressedTime
,buttonHeldTime
, andbuttonReleasedTime
attributes used for generating human-readable date/time stamp events which can be utilized for Habitat dashboard display - Renamed custom attributes
lastCheckin
,buttonPressed
,buttonHeld
, andbuttonReleased
tolastCheckinEpoch
,buttonPressedEpoch
,buttonHeldEpoch
, andbuttonReleasedEpoch
, respectively - renamed
updateCoREEvent()
toupdateDateTimeStamp
- Removed all references to WebCoRE for use of Epoch-time/date stamp custom attribute events and replaced with "Apps that can use Epoch time/date stamps"
- changed default battery voltage range used for calculating percentage to 2.9 V minimum / 3.05 V maximum
Fixed error in info log messages displayed when button is pushed, double-clicked, held, etc. - removed redundant call to
init()
function ininstalled()
- removed
push()
andhold()
command "trap" functions which are no longer necessary - various minor formatting / comments fixes
In my testing, instead of new Date()
, it's better to use new Date().toLocaleString()
which will make sure the time/date stamp is correct for your location's time zone (and presumably 12 or 24-hour clock setting).
However, the above two updates incorporate new Date().toLocaleString()
, so you could just try using those, for the Xiaomi / Aqara Buttons at least.