Hi,
Below is a suggestion on how to make multi-tap better. It would apply to the dimmer, switch, and anything with a button.
We all know that the 700 msec delay is not ideal. Need proof? There is an option to remove it. Why? Because waiting almost a second before a switch does anything is not perfect. Fine, turn on the “instant on” you say. But now you lose the 2,3,4,5 tap controls. Can we have it both ways? Can we have the feeling of “lights turn on right away” and also the “multi-tap”? I think yes.
Let’s create a configurable variable called “tapTimeout”, and let’s set it to something smallish: 150 msec likely would work.
Have a variable called “tapCount” and set it to 0.
When a button tap happens, do
-
stop the timer that was started 2 lines below
-
increment “tapCount”
-
start a timer for “tapTimeout”.
When the timer for “tapTimeout” expires, then “tapCount” will tell you how many taps happened. And you will “act” on a tap quickly.
If you need to tap 5 times, you will get long enough. If you only need to tap once, then you wait only a short amount of time.
A little tuning will find the value for “tapTimeout” that is factory default, and this value is user configurable.
Thoughts?
Kirk
Hey @kirk_korver – great suggestion! We are also about to drop a firmware update that will allow you to configure the ms delay in increments of 100ms starting at 100ms and ending at an infuriating 900ms for those people who love playing pranks on guests.
This should also restore scene control, but also giving you more control over the delay.
I’ll let @EricM_Inovelli speak around the tapTimeout as anything coding related is way above my head 
We’re trying to fix a separate issue with this firmware around smart bulb mode – so that’s why we haven’t released it yet. Hopefully any day now!
4 Likes
@kirk_korver This makes sense. So it’d always be 150ms from the most recent tap before an action happens. tapTimeout could also be user-configured.
I never use more than 3 taps so don’t really need this. But for people who use 5 taps, it makes sense. You might only want to wait 300ms for 2 taps but 750ms for 5 taps and this helps make the wait variable with a maximum wait.
Great to hear @Eric_Inovelli. I’ve been checking the forum every now and then to see if it’s dropped. Didn’t want to ask so as not to pressure you guys! Great to hear it’s now very close!
To confirm, please does the configurable delay also apply to the hold or is it only going to be for taps? Would be awesome if it’s both!
Yeah no worries – we’re excited to launch it!
What do you mean for the hold too? I guess I’m confused as to how the hold would play into the delay. Sorry it’s been a long day lol
1 Like
The switch has to wait for some time to determine whether you’re holding the paddle or simply meant to tap it. That’s the hold delay.
As an example, let’s call the 2 delays tap delay and hold delay. Let’s assume tap delay = 400ms and hold delay = 200ms.
If I:
1a. At time 0ms: Press the top paddle and release in 300ms (larger than hold delay)
b. 200ms after release: I press the top paddle and release immediately, then do nothing after
c. The switch would have 2 sets of events: A hold and release event AND a single tap and release event.
On the other hand, if I:
2a. At time 0ms: Press the top paddle and release in 150ms (less than hold delay)
b. 200m after release: I press the top paddle and release immediately, then do nothing after
c. The switch would have only 1 set of events: A double tap and release event.
Hope that helps. My question is whether that hold delay would also be configurable and my guess is no 
since you’re asking for what it is!
You understand exactly correct. And, yes tapTimeout should be user configurable. I suspect 125 msec to 150 msec will be right. But I would have to try it to know for sure.
Kirk
Ok, so I will admit, I’ve read this 5x and this GIF sums up my ability to understand it:
Just to clarify, this is in regards to the LZW30-SN (On/Off Switch) per the title, correct?
Let me get some fresh eyes on this tomorrow lol
1 Like
Yes, this is for the switch. Though it would apply to dimmers as well.
Above was the pseudo code. Here is how it works.
When you press a button, wait a little bit of time before doing anything
If you press the button again, reset the time to wait even more time.
Repeat until you have waited long enough without a press.
It is like winding a watch. As long as I wind the watch soon enough, I get more time. If I wait long enough, something happens - the watch stops working. We just need to count how many times someone winds the watch.
I want a short amount of time after the press for the opportunity to press again. If I keep pressing, I want more time to press again. Each press gives me a little more time.
Did that make sense?
Kirk
It’s for both I believe. Using the dimmer as an example, if you hold the up paddle on the dimmer, it doesn’t start brightening the light until a few ms (hold delay) have passed. I believe the explanation given was that it’s not sure about whether you want to dim or if you want to simply turn on the light (but are pressing for too long). It’s the same story with sending the zwave hold events. It waits for the same amount of time.
I believe a bunch of folks felt that the switch waits for too long before it starts dimming up or down and wanted that delay to also be configurable. Hope that makes more sense.
BTW, because the On/Offs also have the zwave hold events, we were hoping to be able to configure the delay for the on/off also.
I should also add that I previously asked @EricM_Inovelli about this and he said he believes the configurable delay would be for both:
1 Like
Just wanted to say we will be adding this shortly as we wanted to perfect this on the dimmer before adding it to the On/Off switch.
On the dimmer, you have the ability to change the delay in 100ms increments to fine-tune the delay between multi-taps.
@EricM_Inovelli – can we make sure to add this to the On/Off switch when moving to production?
@Eric_Inovelli - any updates on this front? Been a few months since your last note on reducing the 700ms to a configurable 100-700ms value for the LZW30/LZW30-SN. Been eagerly looking forward to this update - any news you can share?
@EricM_Inovelli – do you know where we’re at on this?
Honestly we have been pushing the development team to finish the LZW31 before starting on the LZW30. They had some internal promotions and we ended up with a new engineer that is still trying to hit his stride. The good news is that I am hopefully that they should finish the updates on the LZW31 within the next week or so and we can move on to other projects.
1 Like
Thanks! Will continue with my install (I have about 50 switches going in), and will check in in a few weeks to see if there’s an ETA (even rough). Appreciate the work!
1 Like
@Eric_Inovelli @EricM_Inovelli any chance this feature will/can come to the LZW36 as well? I love being able to use the multi-tap but not a huge fan of the 700ms delay and would love to configure it on that switch as well.
1 Like
Yes, absolutely. This is something we plan to bring to all of our “switches”.
1 Like