Ah… sorry, I misunderstood. (Well… what I said is still useful, because someday, SmartThings will be “better” than that physical device!).
Yup – This is why there are some “double-tap” SmartApps, but no “hold” SmartApps. I don’t know if it is a part of the ZigBee (nor Z-Wave) specification to support any type of “send messages while held” feature.
It is not very practical from an implementation standpoint. Remember that mesh networking packets are not guaranteed to arrive in order … they arrive “eventually”: So if you have a device that is sending “hold, hold, hold, hold, hold, release”, it might arrive to the Hub (& SmartThings) as “hold, hold, release, hold, hold”. At least I think that is quite possible…
More likely, you’d get “hold, hold, (nothing), (nothing), (nothing), hold, hold, release”. So what if you are trying to steadily ramp up a light, what do you do with the “nothing” period? Assume the button is still being held? Or assume it was released? … Or pause the dimming until you get the next “held” message (meanwhile the user thinks that dimmer is stuck and releases the button…).
That’s why this type of functionality need to be handled as locally as possible (specifically: in the device itself).
###However:
It could be practical / possible for a device to send: [held, duration] as a single message. Then you could use this to dim or brighten by a specific delta based on the duration. Wonder if anything like this is in the ZigBee or Z-Wave spec; or it should be an enhance requiest.
…Terry.