Thank you for reporting back on how the driver's working for you. I will have a chance to do some investigating into using Rule Machine or another App to set up toggle actions for dimmers, since I have a few (including the GE Z-Wave Plus Dimmer) myself.
On a slightly-related note, I have just learned that there is now an "upgraded" model of the Aqara button, which has four functions: click, double-click, hold/release, and shake. The model number on the box and back of the button itself is WXKG12LM. It's so new that it will be difficult to ensure that is the model being shipped when buying from direct-from-China resellers like GearBest, etc. I am going to try to secure a couple because the messages they send are completely different and it will need a separate device driver.
[UPDATE] v0.6b of Xiaomi âOriginalâ (round) Button Device Driver
For convenience please copy the updated beta round button driver code from this direct link.
New Feature!
I discovered the button sends the hub one additional type of unique message for any multi-click over 4. So for any multi-click of 5 times or greater, a pushed - button 6 event is sent. I am calling this the âshizzle-click.â This is definitely my 7 year-old daughterâs favorite type of multi-click.
Other Changes
Added code to handle Push and Hold commands (part of the current implementation of the PushableButton and HoldableButton capabilities). The commands wonât do anything, however, because this button is non-controllable. See my note below for more information.
Added required numberOfButtons event to be sent to the hub when the button is paired, configured, or updated (i.e., when preferences are saved). This lets Apps know how many buttons are available to use.
Added a preference setting to toggle the display of debug log messages, with a default of OFF.
Notes:
Although the current Hubitat button implementation automatically adds commands that allow a button to be controlled, the Push and Hold commands arenât used by this device driver, because the Xiaomi âOriginalâ button is only a trigger (actuator) device, and cannot be controlled. Please make sure not to select the Xiaomi âOriginalâ button as a âcontrollableâ device in any App as nothing will happen. It should only be used as a âtriggerâ device. As I understand it, the Push and Hold commands for physical buttons will be changed or removed in a future update of the Hubitat button implementation.
Just because this device driver maps different types of clicks to 5 different button trigger events doesnât mean they all must be used. Any type of press / multi-click to mapped buttons that are not used by any App are simply ignored.
I have tested this Device Handler with both Rule Machine and also the Button Controllers App. Everything is working as expected, and simple toggle or on/off switch actions based on different button press/click types are very responsive. I am leaving the beta status on this device driver for another week or so, hopefully to get more user feedback, and finalize the code.
I havenât updated to the latest version of your button code yet, but until now it has worked perfectly via Rule Machine. Thanks a ton!
There is just one issue though, I somehow couldnât get the device to show the right attributes on webCoRE.
I am not sure if this is an issue with the driver or the way Hubitat implements buttons. The button is only shown under the Holdable Buttons list on the page where I select devices to make visible to webCoRE.
On the webCoRE piston edit page, I just canât seem to be able to use a button press event because the event generated is an attribute called âpressedâ whose value could be 1, 2, 3, 4, 5 or 80 depending on how many presses were made. Now this value does not change after the press and remains the same until a different number of presses are made the next time. There is no âlastPressedâ attribute either.
Am unsure if I am doing something wrong or if this is an incompatibility with webCoRE since RM handles button presses well. Could you please guide me on what could be going wrong?
Very likely the latter. And we're talking about webCoRE running on Hubitat, right? All the issues of porting it over haven't been worked out, from what I've read here in the forums.
I don't use webCoRE myself, but there can't be any attribute or event named pressed because there's nothing in the code with that name. Did you mean pushed?
The value of 80 is strange because that corresponds to what I named the sizzle-click, a multi-click of over 4. The device driver is supposed to change that 80 to 5, the button number assigned to that type of click. But really, I think the issue has to do with the difference in the Habitat button implementation. SmartThings expects a button event with a value of pushed or held while the Hubitat expects a pushed or held event with a value corresponding to the button number. I would have to attempt installing webCoRE on my Hubitat to find out how to get that implementation working.
As for lastPressed, I removed it, unaware that it's needed or useful for webCoRE. How does it get used?
I can certainly put lastPressed back in, but I need to know in the case when the button is held, whether a lastPressed date/time event should happen at the start of holding the button, or when the button has been held long enough to match the user set countdown.
For example, in the native Hubitat system, using the Rule Machine or Button Controller App, I set up my Button to turn on a group of lights on Button 1 pushed, and to turn them off on Button 1 held. When I click the button once, the device driver immediately generates a pushed event with a value of 1 (for Button #1) because it sees a pressed message from the button followed directly by a "released" message, well before the held countdown timer is finished. But when I hold the button, even though the button sends a "pressed" message, no action is taken until the countdown times finishes, and only then does the device driver generate a held event with a value of 1 . So when the button is held, I could have the device driver either generate the lastPressed when the "pressed" message is received from the button, or at the same time that the device driver generates the held event.
Very likely the latter. And weâre talking about webCoRE running on Hubitat, right? All the issues of porting it over havenât been worked out, from what Iâve read here in the forums.
Yes, webCoRE running on Hubitat. I realize that all the issues haven't been worked out yet but I do have almost all my other devices and pistons working fine at this point, so I assumed this wouldn't be a related issue.
I donât use webCoRE myself, but there canât be any attribute or event named pressed because thereâs nothing in the code with that name. Did you mean pushed ?
My apologies, I wrote my earlier message at work only to come back home and realize that the attribute is indeed called 'pushed' as you pointed out.
SmartThings expects a button event with a value of pushed or held while the Hubitat expects a pushed or held event with a value corresponding to the button number.
That might probably be why I find these options missing. Did not know that.
I can certainly put lastPressed back in, but I need to know in the case when the button is held, whether a lastPressed date/time event should happen at the start of holding the button, or when the button has been held long enough to match the user set countdown.
The use-case here is that since for my button press logic, I need some MOMENTARY event that I can use to trigger actions. Unfortunately, the Xiaomi button on Hubitat, currently changes only two attributes from what I can understand... The 'lastCheckIn/lastCheckInDate' and the 'pushed/held' number. Unfortunately, if I press the same button number (say 1 click) in two consecutive instances, even the 'pushed' value remains the same (1). Thus I have no event to track in webCoRE that can help me trigger an action.
The options I can suggest with my limited knowledge of device drivers are...
Make 'pushed' act as a momentary value with the default unpushed state having a value 0 (basically clear the variable)
Have the 'lastpushed/lastpressed' attribute change every time a push is registered, so that that value compounded with the 'pushed' number can be used to trigger actions.
The Aeon minimote, with its native Hubitat driver, doesnât work with WebCoRE on Hubitat either. No âbuttonâ is selectable. I posted that observation a few days ago in the âWebCore on Hubitatâ topic; this was Mikesâ reply:
So if the Hubitat minimote driver doesnât work with WebCoRE, I wouldnât expect your Xiaomi driver to work either. I think the concept of âWebCoRE is running on Hubitatâ is a bit overstated
By momentary event, I assume you mean that webCoRE needs to see both a "pressed" and "released" state. If true, then because the Hubitat button implementation only provides "pushed", "held", and "doubleTapped" events, and does not provide built-in support for a "released" event, the device driver will have to "fake" a released event. The good news is that, based on your screenshot, webCoRE can use the status any kind of event state (e.g., lastPressed, as was used in a4refillpad's button device handler for SmartThings), regardless of whether it's an officially supported one or not.
You're right, this is unfortunate, because all of the Apps I've tried on Hubitat recognize every instance of events, even if the same state is repeated.
Since in the Hubitat button implementation the value corresponds to button number I'm not sure that using button 0 will work or is a good idea. Since other Hubitat Apps don't need a default "released" state, it would be better to use a custom event just for use with webCoRE, whenever it has finally been tweaked work fully with Hubitat.
So since driver already has a built-in held button function, my idea is to add a buttonReleased event state, which will happen when the button is actually released, like this:
Note that I simply won't be able to support a hold at the end of a multi-click, because of the way the hardware itself sends messages in those cases.
So with my implementation, webCoRE could use the releasedButton Event as a way to make a comparison to all of the types of button presses. Just know that for any click types, the releasedButton event would be sent immediately after the pushed event. If that will work, then I'll add that code and we'll take the driver to v0.7b).
Really appreciate you taking the time to provide a detailed response.
I think your idea would work great!
A releasedButton event in conjunction with the current pushed value or held value could help me intercept all possible button events available, for use as a trigger.
Once again, thank you for being such a receptive developer and helping the community out
@veeceeoh
Keith I tried to pair my aqara button last night and hubitat found it but it did not assign the correct DH to it. I then manually selected the Xiaomi Button DH but I am not certain it is working correctly.
I haven't had a lot of time to play with the hubitat but I haven't been impressed yet...
With my original âroundâ buttons on Hubitat Iâve found that when they didnât get discovered automatically and identified correctly during the pairing process, they never began the hourly battery check-ins and eventually dropped off. Just as with SmartThings, if they wind up as child devices of a Zigbee router they eventually wonât work properly and eventually wonât even register button clicks.
If you have any Iris plug paired to Hubitat nearby they are likely routing through it and will cause problems. The radios in those things seem to be much more easily discovered during the pairing process than the one in the Hubitat, even if they are significantly farther away (Iâve seen how mine attached when I mapped them with XCTU). Once properly paired, they stay paired (at least mine have since Keith released the driver) and work great â they never miss a click.
That would be because I haven't made an (original) Aqara Button device driver yet. I don't have one personally, so I haven't yet been able to find out exactly what messages it sends for anything beyond a single click.
Do you think you could copy the log output for single-click, double-click, etc. to a post here? Either the "Thing" DD (device driver) or the "Original" Button DD with logging turn on should work.
Then I could make the (original) Aqara Button DD. I don't think I'll be able to do a unified button driver, because the "original" Button driver needs to see a "release" message from the button and from what I understand the (original) Aqara Button doesn't send any message when released, only when pressed.
The only change that affects functionality of the device drivers is the addition of a preference setting to toggle the display of log messages. As of this release, when itâs turned on, all messages are labelled debug, but I may later split off info messages with a separate preference toggle setting, to keep in line with the Hubitat-native device driver functionality.
I can confirm that the buttonReleased attribute works perfectly for me. Was able to use a combination of this trigger and the pushed value to harness all button events from 1 to 5, from within webCoRE. Great job again, thanks!
The only scenario that could not be worked out is the Button Held scenario. Currently, there is no way to differentiate between the following triggers since buttonReleased is agnostic to whether the button was pushed or held.
a) pushed = 1 && buttonReleased changes
a) held = 1 && buttonReleased changes
But I guess this was already known at the time we were discussing possible approaches and we didnât have a clear solution.
I believe it should be possible to generate events that would allow a held button to be recognized, but I don't quite follow why WebCoRE can't use the buttonReleased event as a way to make a comparison to either pushed or held events.
In any event, in my own testing tonight I think I need to work a bit more on the code because it's generating buttonReleased events when I expect it to.
I think I wasnât clear in my explanation. I donât think webCoRE is the issue.
Letâs assume that the following scenario takes place after the button has been installed and pressed as well as held, at least once. (This makes the current pushed and held values, both set to 1, or more).
So, now to create a trigger, I can use any combination of values or changes in values, provided by pushed, held and buttonReleased.
Do note that the values of each of these attributes persist. So before I push the button, the value of pushed is 1. After I push the button once, the value is still 1. The only trigger I can use is to see if the buttonReleased value changed (and then to look at the pushed value to determine the number of clicks).
With held, I donât have such a liberty. The value of held, like pushed is still 1, both before and after holding the button. But herebuttonReleased, though a valid trigger, cannot tell me if the update in its value was because of a hold or a push. So technically, I can only intercept holds also as pushes only, in webCoRE.
Only solution I can think of is to have a buttonHoldReleased or something similar, which updates only for a hold.
Again, I do not miss the lack of a valid trigger for hold at all. The handler works perfectly and now I have 5 different button press scenarios to chose from, unlike the limited options while I was on ST, thanks to you!
