I just posted a simple SmartApp that will create virtual single button devices for each button in a multi-button device. For example, I tested it with the Enerwave 7 Button Scene Controller, which has 7 buttons. With a single button device, it is much easier to use in a SmartApp in a common way, using only the capability.button. This also allows these types of devices to work with SmartRules (see here - http://smartrulesapp.com), so you can easily create a rule for each button on the device.
To make the Enerwave device work, it just needed a slightly modified device type, which is posted to the GitHub repo. It should work with the default device type for the Aeon Minimote. I also made small modifications to the existing community-created device types for the SmartenIt ZBWS3B and the Security Key Fob, so they should both work. Currently, only the Enerwave has been tested, so please post if you can verify it works with the others.
Iâll try to test this with the SmartenIT over the next few days when I get a chance. Awesome that you did thisâŠsucks that the way ST works with these controllers forced you to create a workaround! Hopefully they will put something in place to get these working in a standardized way.
tgauchat
(ActionTiles.com co-founder Terry @ActionTiles; GitHub: @cosmicpuppy)
6
Iâll take a look at it within the next day or so: Iâm a bit busy with the IoT World Event in SF today.
I still contend that button state âheldâ does not apply to Minimote. The âheldâ state should be for arbitrary length of hold (like holding a door lock buzzer), not for a hardware implementation of additional âshiftedâ buttons. The purest representation of the Minimote is 8 distinct buttons (not 4). To avoid user confusion, some descriptive text and/or compromises may be required, I admit.
But Iâd like to see Capability Button state âheldâ be clearly defined as I imply above. It is a religious issue and hard to justify without extensive discussion and more real-world examples, and may represent a weird perverted perspective I have.
tgauchat
(ActionTiles.com co-founder Terry @ActionTiles; GitHub: @cosmicpuppy)
7
Iâm not sure:
At least in the case of the Minimote, double-tap is unlikely to be reliable because each button press takes a round trip to be processed. Double-taps without a round-trip are filtered to a single tap. Rapid taps of different buttons are not filtered. Where is the filtering ⊠Iâm not sure. The Device Handler and/or Button Controller app are concerning to me, and glad weâre working on it.
Thatâs rushed explanation, but if youâve used the Minimote, you may have observed what I describe.
Agreed. Due to the filtering, it would be difficult to get the timing right for a double tap. The repetition from the device makes the filtering necessary.
I see what youâre saying, but I think what the original author (of the capability) was intending here was for âpushedâ and âheldâ to be two unique, momentary states of a button. I would suggest that the model you are looking for would actually not require a âheldâ at all, just a âpushedâ and a âreleasedâ, then the user of the device would determine that in between the two, it is held and take the appropriate action. Note that the button capability does not have a âreleasedâ, so thatâs what makes me think these are just supposed to be two momentary states, with the device itself deciding what is a push and what is a hold. Basically, this allows the device to only communicate on the release of the button, instead of on both the press and the release.
That being said, it would definitely make sense to have another device type capability that operates as you describe, as would be needed for a door buzzer like you said.
EDITED: to change âdevice typeâ to âcapabilityâ
tgauchat
(ActionTiles.com co-founder Terry @ActionTiles; GitHub: @cosmicpuppy)
11
YES!
Thank-you for the excellent example!!!
There are various ways that âheldâ can be implemented:
The hardware can report hold long the button was held (though not great because SmartThings canât start reacting to the button until it is released, possibly). Would need a new attribute for âtime heldâ.
The Device Handler can presume the button is âheldâ until its state is reported as âreleasedâ. Currently there is no such state âreleasedâ defined in the Capability (???).
It looks like weâre on the same page here, just I think it should be another, separate capability. With the current button capability, I would say no, âheldâ does not make sense for controlling volume/dimmers.
2 Likes
tgauchat
(ActionTiles.com co-founder Terry @ActionTiles; GitHub: @cosmicpuppy)
13
Yup â I agree. Capability Button implicitly overlaps with Capability Momentary, with the difference seemingly centered around this contentious state of âheldâ.
Tweaking Capabilities (or adding new ones) is something that just isnât happening for some inexplicable reason.
In this context, I would definitely like to have the definitions make it very clear what the difference and example uses and best practices are of Button vs. Momentary.
When designing an actual button device, whether itâs a mouse or an actuator or whatever, typically you think of it like an open/close sensor. There are two distinct states: Pushed and Released. Then you just count the time between them in milliseconds to distinguish between Press and Hold.
This is exactly why typical engineering terminology is Press and Long Press (rather than Press and Hold). Means the same thing, but âLong Pressâ is a reminder that itâs a measurement of time duration, not force.
So there are a lot of different ways to design Capabilities around that, but you do need to have a device that will report either both the press and the release or the press and the duration. ( edited to add Or the physical device will do those calculations internally and just pass you the result: press or long press or inactive. That might be considered a different Capability: Calculated Long Press. )
The problem, as always with physical button devices, is ânoiseâ (or âbouncesâ). The person whose finger hesitates slightly, then presses down firmly. So not all devices will report exactly what you expect, depending on their internal debounce protocol.
FWIWâŠ
1 Like
tgauchat
(ActionTiles.com co-founder Terry @ActionTiles; GitHub: @cosmicpuppy)
15
I agree.
The Aeon Minimote, however only reports the singular event of a button having been pressed, along with the button number (a hex code, but essentially 1 to 4, and with a bit that indicates held, but can easily be called buttons number 5 to 8). There is NO event sent upon release of the Button, and NO duration value.
So⊠IMHO: The Aeon Minimote is just 8 Momentary Devices, not a âButtonâ that has a pressed and held property (since, per your definition, that I agree with, it does not report release events, nor duration).
From a physical device standpoint, itâs actually the other way around. There are NOT eight physical buttons, right? There are four physical buttons, each with a Press and a Long Press.
The device is reporting those states correctly. 4 physical buttons, 2 possible active events per button (press and long press).
You may choose to think of those as 8 buttons from a coding standpoint, but the physical device has 4 buttons, and thatâs what itâs telling you.
You donât know what its internal rules are for press vs long press, the device is just reporting the result of the calculation. But those rules exist within the device itself, even if theyâre not exposed to coders along with the calculation results.
As I mentioned in my edit above, you could reasonably consider that a different Capability: Calculated Long Press. The physical device either passes the Release, the Duration, or its own Calculated Result. How many Capabilities that represents is open.
tgauchat
(ActionTiles.com co-founder Terry @ActionTiles; GitHub: @cosmicpuppy)
17
I see what youâre saying, but contend there is an alternate view that makes sense in some contexts⊠And perhaps the Device Handler(s) can make different choices for the same device model.
Consider a computer keyboard. Some have a dedicated set of extra buttons which form the numeric keypad. Another manufacturer may make a smaller keyboard that overlays the numeric keypad on top of letters and requires holding a âFnâ key.
The net result to the PC is the same: both pieces of hardware appear to have a numeric keypad (â 12 extra keys).
I canât create the app âVirtual Buttonâ. I get the following error:
No signature of method: script14318701195111022460890.metadata() is applicable for argument types: (script14318701195111022460890$_run_closure1) values: [script14318701195111022460890$_run_closure1@48bbaaa5] Possible solutions: getMetadata(), getState(), setState(java.lang.Object), metaClass(groovy.lang.Closure)
