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
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.
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!
@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.
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.
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!
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.
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:
@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?
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.
@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.