LZW30-SN - Multi-tap improvement

Suggestions & Wishlist
#1

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

  1. stop the timer that was started 2 lines below

  2. increment “tapCount”

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

#2

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 :slight_smile:

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
#3

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

#4

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!

#5

Yeah no worries :slight_smile: – 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

#6

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 :grin: since you’re asking for what it is!

#7

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

#8

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
#9

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

#10

:grin:
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