I want to know how to setup double click actions for various switches I have installed now. I presume this must be relatively easy with CoRE but it isn’t readily apparent from the piston configuration UI. The only other thread I’ve found hinges on “fibaro dimmers” - not something that’s relevant to me.
What’s the right way to do double-click actions or clickhold actions? For example:
single click = this switch turns on (nothing special from CoRE)
double click = this switch + other switches turn on (via CoRE)
clickhold = this switch fades on (I’m not sure if this requires CoRE or is native?)
click-clickhold (aka “doubleclickhold”) = this switch + others fade on
If you were talking about a device that reports double clicks, typically it will be using a device type handler that identifies it as having capability.button and then the different actions will be reported to core as different button presses.
For example, a minimote has four physical buttons but reports as having eight, where buttons 5–8 are doing long hold physical actions of buttons 1–4.
This is how the homeseer wall switch works, for example.
It all depends on the device type handler for the device reporting the number of buttons and the appropriate button presses.
For the record I’m guessing I could do this with some globals and an elegant click handler “check this variable state, pending the boolean value begin a countdown timer or perform an action” etc etc. I’m hoping someone else has a nice clean way to do this before I head out to write code.
When the switch itself doesn’t capture the click pattern and send a code, which that particular GE switch does not, then you have to try to do it with timing in the cloud.
People have been doing this since smartthings was first created, using a double tap smartapp, but it’s just hardly ever works well because of the cloud latency. So you’ll see a whole bunch of different smartapps where it says “this double tap works,” “ok, this double tap works,” etc., but then when you read the thread, you’ll see a lot of people reporting that no, it doesn’t work consistently. Getting that timing right in the cloud is just really really hard.
You can try it, and see if it will work for you, but honestly I’m not optimistic.
The reason the minimote and the homeseer wall switch work is because it’s the firmware on the device itself that captures the tap pattern and then sends that information to the hub, so there’s no cloud latency issues in getting the pattern recognition right.
Use the quick browse list in the community – created wiki and look on the lighting list for smartapps and you’ll see the existing options if you want to try to replicate the idea.
The devolo is another good example of a device where it is the device itself which captures the click pattern, and in this case uses the “central scene command” Z wave command set to send a single code to the smartthings hub for each different pattern.
Those kind of devices can definitely work great. There are quite a few of them.
But you as a customer can’t add that capability to a device that doesn’t have it, like the OP’s GE switch. Because it’s in the firmware of the switch itself.
Interesting, I didn’t realise the Minimote had this capability. I did try the above handler with a Minimote but didn’t get anywhere if I remember correctly and didn’t seem to be able to find any other handlers.
EDIT: unless you’re just referring to push and hold
I should also mention the issue of mesh latency which is one of the reasons why central scene commands were created in the first place.
Mesh topologies, including zwave and Zigbee, do not guarantee forced sequencing.
Messages can and do bounce around the network, and they can take different paths to the hub at different times.
It’s entirely possible that if you open and close a door very quickly, the “sensor closed” message might be received by the hub before the “sensor opened” Message. It happens.
The same thing can happen with multiple clicks on a single switch. There isn’t really any way to guarantee that the first message will be received by the hub before the second one. And you can’t get super precise timing, since the messages may take different paths on different attempts.
All of this is why the official SmartThings documentation tells you that you can’t schedule something closer than one minute apart and be certain that it will occur as you expect.
Core does allow you to design a piston with shorter increments, there’s just no guarantee that it will work that way every time.
So a person might tap the switch in exactly the same way four different times but the Precision timings received by a smartapp in the cloud might be different for each of those four attempts.
Again, you can try it and see what happens, just be aware that the performance overtime may vary.
Yes, for the minimote it’s push and hold for each of 4 buttons. The DeVolo handler won’t work with a minimote because it’s using a different Z wave Command set. The Devolo, the Homeseer, and a couple of others are using the “central scene” command set. The minimote is just reporting press and long press.
But in both cases it’s the device telling the hub what happened, not a smartapp trying to calculate timing between duplicate events.
You can try it and see what happens. You never know. There are a lot of different factors. If the switch is within one hop of the hub, that would help a lot. Just don’t put anything super critical on it.