❤ Love the new parameter 51, anything for the LZW36?

Wow, updated all my switches&dimmers this weekend. The new “no delay” option is great! They feel like super switches now. This is great for me, as i don’t use any scenes, only the config button for automating stuff.

I’m not sure if it’s possible for the Fan&Switch, as the button is used for config, but are you planning on doing something similar with them, maybe with an alternate firmware?

3 Likes

This. Pretty please?

Lol, at least you put a heart in your title, so it softens the blow :slight_smile:

Yes, we’ll talk to the engineers about this – we’ll have to brainstorm some ideas around how this influences scene control, but maybe I’ll put a poll out to see what people think!

Curious to what people are wanting no delay on. Light, Fan or combo? Figure the light would be the “sensitive” one and fan could continue with the delay. No fan goes from 0-100% in .5ms anyways…

Yeah, I suppose that could be a decent fix. Maybe we remove scenes (except for single-tap) with the light portion and leave the double, triple, etc on the fan portion.

1 Like

What can I say…I’m a genius.

1 Like

The fan&light is already a hit it my house, maybe I word it wrong, I meant no offenses. Blame it on the second language thing.

I agree with harjms, the delay option on the light make most sense, as the fan is mostly always on, but the light get on/off on enter/leave the room.

Now I need to convince my better half that I need to replace my remaining first gen dimmers…

1 Like

Lol no you’re good - there was another post similar to yours. I sincerely liked the heart :slight_smile:

Please excuse my beginner’s knowledge of Z-Wave, but it seems that the necessity of a Parameter 51 actually exposes a problem with how button events are generated. Maybe the current method is an integral part of the Z-Wave spec, or maybe it is merely the way companies happen to do things.

On HomeSeer 4, which from the log does not appear to be masking out anything, with the LZW36 (v1.34 and v1.36), a press/release of 001 or 002 generates a Pressed 1 Time event. Pressing & holding & releasing generates a Hold event then Release event. Press & release of 003 - 006 generate the Pressed 1 Time event, though a Hold generates no event at all (they do however still change the output level, so sort of not nice).

It would seem that any button should always generate a Press event and Release event, and be generated as soon as they occur. Any other button events would then be constructed from those events based on Parameter settings. E.g., a Hold event is generated from a prolonged Press, based on a Parameter specifying min time (or zero for disable), and the sequence of events that one would expect is:
Press
Hold
Release

A single-click would likewise be generated from a Press and Release that is too short to be a Hold:
Press
Release
Single-Click

A double-click, configured by a Parameter indicating maximum ms between Press/Release pairs that also do not conform to a Hold:
Press
Release
Press
Release
Double-Click

And so on. This means one can rely on quick response Press/Release events, and optionally use or turn off the other event types.

In my current non-Z-Wave system I make use of both a Press event and Hold event on the same buttons. In one scenario, the Press turns on the lights in the room (immediately), and if the button is held for the required time, thus generating the Hold event, the default audio source is also turned on (a subsequent Press turns everything off).

Anyway, it is mostly just about having both timely button state events plus the extra generated events to perform additional functionality.

The reason they need the delay is so that you can have a double tap NOT also trigger the action of a single tap.

Just pointing out that there are other ways of doing things that support both immediate response and multi-taps. By separating out the raw press/release, and optionally allowing those to be sent, one can obtain immediate response, while also optionally sending multi-taps, holds, or a mixture of both.

Interesting, how do you go about doing this? It seems to me that if there is no delay, the single tap action would always be triggered to still get multi tap actions and maintain immediate response. What am I missing? You previous post says the difference between a single and double tap is a small delay denoted by a parameter, but how is that any different from what the firmware currently does?

As I initially wrote, I only have a beginner’s knowledge, if that, of the Z-Wave protocol, and I’m sure Inovelli is doing the best they can given the apparent limitations of the protocol.

@george , can you answer the above. Im confused about that too… How does your double tap NOT also trigger whatever is tied to the single tap?

Hi @george,
I think the main use case that people were worried about, & these parameters were intended to address, is with a load being controlled directly by the switch - so no Z-Wave or hub involved.
I’m not sure exactly what the Z-wave specifications are either - it would certainly seems reasonable to send button press/release events - but in most use cases, he hub would need to implement the same kind of delay logic to see how long the button was held for & decide whether it’s a tap, a multi-tap or a hold event - before actually doing anything.
In your particular (but I’m thinking slightly specialized) use case - where you want a hold to do the same as a press, but then something else as well, this would be faster.

Yes, having the home automation system be able to decide what to do based on multiple factors, but I am finding that Z-Wave is a bit constrained for that compared to my old system (Lonmark over high speed 4-wire multi-drop RS485), so I have dialed back my expectations. Wifi devices such as Shelly do provide this type of input, but have a much higher and low latency bandwidth available. But as mentioned, that is not your typical use case.