ZWave Scene Support (i.e. multiple clicks)

[coreyo]

Increasingly more zwave switches and remotes support zwave scenes in the form of multiple button presses. The possibilities for attaching rules and scripts to multiple button press combinations are endless. Here are some examples of such devices:

• https://inovelli.com/shop/smart-light-switches/z-wave-dimmer-switch-scenes-repeater/
• https://shop.homeseer.com/products/hswd200?variant=1027694264332
• https://aeotec.com/z-wave-wireless-switch

[dhylands]

0.7.1 has better scene support. I have a wallmote quad and verified that it works. I'll need to see more devices to see what might or might not be further improvement.

[pgbross]

I have been experimenting with a Fibaro key-fob (FGKF-601) and a POPP Wallcontroller (009303). In both cases they send Central Scene Notifications for various key presses, long presses, and releases. I have been using Gateway v0.7.0, with zwave-adapter v0.7.1.

After getting to grips with understanding/debugging zwave-adapter, node-openzwave-shared and openzwave, I have been able to add the devices as things, and after minor tweaks to the zwave-classifier, add rules so that I can control switches with various combinations of presses and press & hold.

I am now at a stage trying to understand the philosophy of the zwave-classifier in respect of Central Scene Notifications. I see that in adding the Aotec Wallmote Quad it has chosen to add properties such as an "onProperty". I can see this might be convenient in some ways, and the documentation for the Wallmote discusses the idea that a button has an on/off property (I do not possess a Wallmote to see in detail which command classes it responds to or supports). I do not really see, however, why it is the responsibility of the classifier to add the property, when central scenes are essentially reporting events. If a device such as the Wallmote has an on/off property then surely that ought to be supported as a Switch, Multilevel Switch, etc. without the requirement to synthesise one in the Gateway (how would you know if its state was on or off when starting the Gateway if it was not a real attribute of the device).

So for a generic device/wall controller what should the classifier do by default? It could read the device configuration and find the list of buttons, and then add events for each of them (either explicitly with the Dev version of OpenZwave library or implicitly with the Master version of the library - the dev version has the values for scenes be a list rather than an int property). If that is the "generic" approach how does one handle specific devices like the Wallmote with more advanced functionality . My hope is that the classifier would see there was a Multilevel switch and a Basic Switch and that the classifier would handle that without needing Central Scene support, but one could also imagine a set of custom handlers for classifying certain devices.

Not sure if this is the best place for discussing this, but it seems closely related to Adding the Aotec Wallmote and the question on Scene support in general.

[dhylands]

When you query the wallmote, it says that it has the on/off command class, but it only uses that command class when you use associations (i.e. the wallmote is directly controlling a device).

When using the wallmote with a gateway, it seems that the only notification that you get are the central scene notifications.

The classifier create an on property because this is something that the user is comfortable with. The device also generates events, which is probably more in keeping with the central scene notifications.

Since it only adds a small amount of code, I decided to have the wallmote support both state and events, and the user can choose to use whichever they're more comfortable with.

[pgbross]

That makes sense. I guess the question then is how to handle devices like the Fibaro Key fob which has 6 buttons, in the current code. This has a minimum of 6 scenes and can generate more if sequences are taken into account, Is it sufficient to just iterate over the values returned from the node (read fro the xml cache file??) and create the events and pseudo properties?

At the moment the code distinguishes its code paths with an if based in the scene count, 2 for a simple controller else it assumes the wallmote - so perhaps it needs to check for known devices first (e.g the wallmote has swipe, though I am not sure if that is its own scene). Then if it is not special, just do something for each scene id.

Is this something that you are considering? Is it likely to be of any help if I experiment and come up with a PR of some kind?

[dhylands]

I think we should probably generate events for each possible button/single/double press that can be done.

With a 2 button device, having one button represent on and the second button represent off kind of makes sense to me. And then long-press on one of the buttons increases brightness and decreases on the other.

For more than 2 buttons, we could make a press be a toggle of the on/off state (which is what the wallmote does).

So what we could do is have a table of labels which are manufacturer specific, along with a function that could be called. For the wallmote, we'd put the addSlideProperties, and config items into that function (and it looks like the levelProperty as well.

We could then use generic labels if no specific ones are found and have the toggle/events per button for devices with more than 2 buttons.

PRs would be welcome!

[dhylands]

We already have a quirks table at the top of the file for configuration, adding some items for labels and/or classification would probably make sense.

[pgbross]

Sounds good to me.
Not quite sure when I will next get to look at this (the next couple of weeks are looking busy), but if I get time and make progress I will try and make it a PR.