Virtual Buttons

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 -, 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.

Does your mod support the Minomote long press?


Here is Duncan’s response from another thread:

It should, but I can’t test it.

Would this work with double tap?

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.

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.


Does “held” make sense for controlling up/down for volume and dimmer controls? Or is that a different concept.

Enjoy! Wish I could be there!

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”


Thank-you for the excellent example!!! :smiley:
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 (???).

  • Some variation that combines the two.

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.


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.


1 Like

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.

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)

I think you’ve just got the files mixed up. VirtualButton.groovy
( is a device type. VirtualButtons.groovy ( is the SmartApp. You’ll need to copy and publish both.

Haha. You’re 100% correct. Sorry 'bout that. Apparently I wasn’t paying attention.

1 Like