How to make Fibaro Walli switches toggle remote Wallis quickly? (maybe using scenes?)

[Nebukadneza]

Hi all,

I´m not completely sure I´m right here, but … let´s try ^_^.

I have a lot of Fibaro Walli switches in my house. They work like a charm with ZWave-JS-UI in Home-Assistant! Except for … one little thing. In quite some places I have one mains-powered Walli with no local load attached. I´d like to use it purely to toggle(!) a remote Walli switch.

I found (supposedly) three ways of doing this:

• Associations
  • Pro: Very fast acting, works when coordinator down
  • Cons: No toggle supported, the sending switch always sends its current on/off-state to the remote switch.
• Automation in Home-Assistant
  • Pro: Works, including toggle mechanics
  • Cons: Very slow (~2-4sec), which sucks for a light switch. Doesn´t work when coordinator or HA down
• Z-Wave Scenes
  • Pro: Promises to be fast and working without coordinator
  • Cons: Very little to no documentation on what a scene is and what it comprises of. Completely lost how to configure a Walli for it

So … What I´d like to get to work are Scenes. I know I can create a Scene in ZWave-JS-UI. I can create "association"s in Scenes, which seem to be able to set just about any parameter to a target value on the associations target device. e.g. the switches state. I can set it to "on" as a target, which isn´t exactly toggle, but … lets see where this leads.

Now let´s say i created that scene. How the heck to I configure the "sending" switch, to actually send that scene. This is the documentation for the device. Searching for scene I find:

Parameter 40: First buttonscenes sent
This parameter determines which actions result in sending scene IDs assigned to them. Values can be combined (e.g. 1+2=3 means that scenes for single and double click are sent). Enabling scenes for triple click disables entering the device in learn mode by triple clicking.
Size: 1 Byte, Default Value: 0

Setting Description
1 Key pressed 1 time
2 Key pressed 2 time
4 Key pressed 3 time
8 Key hold down and key released

Supported Command Classes
Central Scene V3

mh … well. Yes, I suppose I´d like to trigger a scene ID on a Key press 1 time.

But where do I tell it which scene a certain button pressed 1 time should trigger? Is that part of the scene? of the device? is it device-specific or a standard? What does the "Central Scene V3" Commandclass even mean? In the ZWave-JS-UI Configuration section i see a lot of undefined readonly values, and "Send held down notifications at a slow rate" as a parameter. Mhmm.

I realise asking for a specific device is a tough nut, but I´m desperate here. I´d appreciate any help I can get either to understand the basic zwave and zwavejsui concepts that might help me solve this, or even better specific tips for the precise device.

Thanks for reading! Best,
-Dario

[kpine]

So … What I´d like to get to work are Scenes. I know I can create a Scene in ZWave-JS-UI. I can create "association"s in Scenes, which seem to be able to set just about any parameter to a target value on the associations target device. e.g. the switches state. I can set it to "on" as a target, which isn´t exactly toggle, but … lets see where this leads.

Now let´s say i created that scene. How the heck to I configure the "sending" switch, to actually send that scene

This is not a "Z-Wave scene", it's a "Z-Wave JS UI scene", purely configured in the software. It's exactly the same thing as using HA Automation Scenes but is limited to whatever ZUI supports, and this kind of scene has no relation to the Z-Wave protocol or devices. You trigger these scenes via MQTT, either using a manual MQTT topic command or as a switch entity in HA using MQTT discovery.

Supported Command Classes
Central Scene V3

As the name denotes, "Central Scene" uses a centralized controller/hub/gateway, aka Home Assistant or ZUI. The device will send the command on those button presses and the gateway decides how to responsd with your configured automations. In other words, this is your "Automation in Home-Assistant" line item. The benefit is that it doesn't act as a on/off device and you can react based on what kind of key press was performed. Sometimes there is a slight delay since the device needs to figure out whether you're doing a scene or setting the on/off state, so dedicated scene controllers may work faster.

Real "Z-Wave Scenes" require the use of the Scene Activation CC / Scene Actuator Configuration / Scene Controller Configuration command classes. These are mostly outdated, IMO, you won't really find support in new devices. They're also very difficult to configure. Central Scene support has mostly replaced this. To use with your Walli it and the target devices would need to Support those command classes.

If you want to keep using the Walli, Central Scene sounds like the best option, with an automation via Home Assistant. A 2-4 second delay sounds like either device limitations or network problems. I have several GE switches I use in this fashion and actions are mostly instantaneous (double tapping the dimmer light sets it to a fixed brightness).

[Nebukadneza]

Hi @kpine ,

thanks for the extensive and detailed answer. This explains a lot, and I believe that the complex z-wave-scene functionality is what i can still see some remains from in the Wallis configuration.

So just to be sure I understand your suggestion: You would create a zwave-js-ui-scene, and have a HA automation listen for buttonpress triggers, to then activate the scene? I´ll try that and see how the delay compares.

I´ve also rebuilt the routes, and I´m now down to ~1-1.5sec, which is still a bit much for a lightswitch, but better.

One final question though - can you (or anyone) think of any trick to implement a "toggle" functionality using associations? The "sending" Node in the association only offers Lifeline, On/Off, Dimmer as Groups. Both sending and receiving nodes have Root, Endpoint 1 and Endpoint 2 as possible endpoints. As far as node configuration goes, I can only configure the two local/physical buttons to either work as "one toggles relay 1, the other relay 2", "both toggle both", or "up turns both on, down turns both off". It seems like in the on/off case, it only sends out an event if the local relay state is actually toggled (otherwise that´d be it!). The device also allows setting the On and Off values sent as integers, so I could do some creative reversing or something.

So … there´s a couple of building blocks that miiiight help if used with associations, in the right combination. I just can´t think of anything that´d work, hence my asking …

Thanks for the great help again!
Best,
-Dario

[kpine]

thanks for the extensive and detailed answer. This explains a lot, and I believe that the complex z-wave-scene functionality is what i can still see some remains from in the Wallis configuration.

According to the manual at https://manuals.fibaro.com/walli-switch/, this device only support Central Scene CC, not any of the other scene functionality (Scene Activation, Scene Actuator Configuration / Scene Controller Configuration CC).

So just to be sure I understand your suggestion: You would create a zwave-js-ui-scene, and have a HA automation listen for buttonpress triggers, to then activate the scene? I´ll try that and see how the delay compares.

Nope, as an HA user I have no reason to use ZUI scenes. You can accomplish the same thing in HA Automations. Just listen for the button-press in an HA automation and activate whatever devices you want. If you have several devices all receiving the same command, you could look into using multicast to reduce the "popcorn" affect.

One final question though - can you (or anyone) think of any trick to implement a "toggle" functionality using associations?

I don't see how that would be possible unless the device supported it via some configurations like you mentioned. There's no native "toggle" command or value in Z-Wave for lights/switches, it's either set off (0), on to some value (1-99) or on to last value (255). The device would need to keep its own internal state for a toggle and send the correct command.

[Nebukadneza]

Hey,

thanks again for the in detail thoughts and explanation! Then what I do is already pretty much the best possible … a bit of a bummer, but I guess I’ll get used to it.

Otherwise, I think asking the manufacturer for a more complete feature-set is never wrong - even though I realize chances are next to non-existant.

Thanks a bunch!