How to distinguish between single and double-tap on device without central scene?

[nmpu]

This discussion is not specific to a particular device, but we can use 14287/ZW4002 as an example. This device does not support central scene. Assume the fan control is already on.

If I tap up, I'll get:

38-0-currentValue

That's nice, but it's the same event you'd get any time the device changes state. If I associate group 2 with the hub, I'll also get:

32-0-event

which will only occur for a local tap. This is what I want.

However, this is the same game that's used for double-tap. If I associate group 3 with the hub, then I get the same 32-0-event for either single or double-tap. I'd like to be able to tell them apart.

Is there some way to tweak the event's endpoint or value so that I can distinguish between single and double tap?

[AlCalzone]

That's nice, but it's the same event you'd get any time the device changes state

This is a HA issue. node-zwave-js emits value updated events, whether the value changed or not. So if you were able to detect that the value was updated without changing, you would be able to detect the tap up in the on state. However, HA ignores value updates without changes.

Is there some way to tweak the event's endpoint or value

No. We only expose what the device sends. I'm afraid the solution is to only associate group 3 and lobby the HA devs to add some way to trigger on unchanged value updates.

[kpine]

Double-taps for this device are already supported in HA the same as all other GE devices are, using 1) Scene notification events, or 2) event entities (Event value).

[AlCalzone]

Double taps, yes. Pressing up once when the device is already on doesn't get exposed, although the information is there.

[kpine]

Even if HA supported that, you still can't distinguish local tap events from Z-Wave commands.

[kpine]

If you want to handle value update events outside of HA's entities, you can use the zwave_js.value_updated platform trigger. You can use the 38-0-currentValue value as the trigger and it will execute anytime Z-Wave JS sends a value updated event, even if the device is already on.

You will still have the problem of detecting local taps vs. Z-Wave commands. For example, if you turn on the fan via HA, Z-Wave JS will send an optimistic value update, and then it will send another value update for the manual refresh. These will be indistinguishable from a local tap. You would need some additional automation logic to try and detect whether a Z-Wave command was just sent. Maybe the trigger state context has that information.

For HA to emit a state trigger when the entity's current value is set, but doesn't change, would require modifying the integration to enable the force_update attribute. This is already done for sensor entities. Enabling this for fan/light/switch may receive push back from HA devs though, your best chance would be to submit a PR and have it rejected/accepted, or ask devs on HA Discord regarding the idea and see if anyone from Core responds. Enabling this would possibly break people's existing automations if they aren't using a from clause in their trigger, as they may be assuming the current behavior.

[nmpu]

@AlCalzone, as @kpine has mentioned, HA does expose all the events. The problem is that 37/38-x-currentValue also appears every time you set a new target value. The sequence looks like this:

Value updated: 38-0-targetValue 10 => 47
Value updated: 38-0-currentValue 10 => 47
Value updated: 38-0-currentValue 47 => 47

This means it's impossible to distinguish a local tap (without elaborate context tracking). I'm not suggesting this is a bug in either Z-Wave JS or HA. It's just how things work. Another difficulty is that 37/38-x-currentValue can arrive multiple times due to imperfect communications.

When Value notification: 32-x-event arrives, can Z-Wave JS distinguish between Group 2 and Group 3 association? If not, could Z-Wave JS snoop on a dedicated proxy node used as the target? Just trying to understand what's possible. I see there are now 'virtual' nodes. Would there be some way to associate with a virtual node and have that virtual node signal the controller?

I currently have automations to detect U0, U1, U2, D0, D1, D2 with or without central scene. U0/D0 are local on/off. HA can just barely keep up with the burst of events. Unfortunately, the update triggers do not have a unique timestamp so I have to rely on the (shared) automation timestamp and use parallel mode. Queued mode would be more robust. Everything works. I just have to discard some sequences when things become ambiguous. Since these are all local, it's no big deal to just repeat the tap sequence. I currently use 32-x-event for both single and double-tap. This 'local' marker gives me another data point to key off. The single-tap up/down must agree with the latest 37/38-x-currentValue. If I could distinguish between Group 2 and Group 3, I could immediately detect U2/D2 without context (or delay).

Thanks to both of you for entertaining this discussion. I know it's way off the beaten path. Obviously, this would all be non-issue if I got rid of anything that's not central scene.

[AlCalzone]

can Z-Wave JS distinguish between Group 2 and Group 3 association

No. We only receive the report, no information which association group sent it. Even if that were possible, most groups have no meaning to Z-Wave JS.

Would there be some way to associate with a virtual node and have that virtual node signal the controller?

This could theoretically be possible with a controller based on the Bridge Controller Library, with a virtual node that you set as the association destination. However Z-Wave JS doesn't support this currently - and neither does any application. I'm not sure how HA would even model these virtual nodes.

Other than that I could imagine making this work by adding context to the value update - whether the update was expected (optimistic, response to a GET, ...) or unsolicited (sent by the device without any action from the controller). This would require HA to add support for this flag, but could potentially help with similar automations.