FGS213 / FGS224 - associations not working with sendCommand

  • openHAB version: 3.1.0 M4

I’ve got 3 lights in the staircase, each of them triggered by a toggle wall switch.

Use case:
Switch on any of the 3 lights, the 2 other lights should be switched on as well.
Switch off any of the 3 lights, the 2 other lights should be switched off as well.

Light 1: FGS213 (S1)
Light 2: FGS213 (S1)
Light 3: FGS224 (S2)

I use association group 2 to make this happen (example for 1 of the switches):

This is working fine when I use the toggle switches.

Problem:
When I use “item.sendCommand(ON)” or “item.sendCommand(OFF)” for any of the 3 lamps, only 1 lamp is being switched on/off instead of all 3 lamps.

Example:

    ZWaveNode015FGS213SingleSwitch2_Switch1.sendCommand(ON)

It seems as if the FGS213 and FGS224 behave differently when:

  • Toggle wall switch is used
  • “item.sendCommand(ON)” or “item.sendCommand(OFF)” are used

Why isn’t this working with “sendCommand”?

I think that’s exactly how it’s supposed to work.
Imagine if device X received a remote command, and passed the command along to associated device Y. Which happily receives that remote command, and passes it along to associated device X. Which receives tat remote command and …

When I use the wall switch to switch device X on…

… wouldn’t this cause the same problem?

This is the expected behaviour for z-wave devices.

Are you referring to both:

  • working with wall switch
  • not working with “sendCommand”

If yes, why is it meant to work with wall switches?
Wouldn’t this cause the same unwanted behaviour as with sendCommand?

Not at all. Each device knows the difference between a local knob being twiddled and instructions coming over the air, and responds differently i.e. only passes to the list of associated.devices when thee’s a local twiddle.

The whole idea of association in zwave is that it operates independently of any “master controller”.

Anyway, as you’ve discovered, it doesn’t work the way you want. You can mimic “associations” in openHAB in various ways, using a Group is simple.

2 Likes

Thank you for the explaination - very helpful indeed.

I had been using a Group initially with the negative side effect that there is quite some delay between the lights when switching ON/OFF - sometimes even ~5s for the last light.
Familiy members getting confused, e.g. motion sensor seem not to have triggered → pressing the wall switch thereby sending an unwanted “OFF” and so on…

That’s why I tried with associations → ~0,5-1s delay between the lights… in this case the response time is short enough.

Which other ways can you think of for such a scenario in which I’d also want to be able to use sendCommand?

You might mimic a Group pass-to-others effect with a rule. This does allow for intelligence to be applied, “only do this part if that” etc. and also to stream commands in a desired order and/or with delays between individual device commands to avoid network flooding.

It is a real drawback, sending individual commands over the mesh, instead of a single “scene broadcast”.

Not sure I understand your suggestion…

I know that rules allow a lot more flexibility. Is this what vyou’re trying to say?

How would I create such a “broadcast”?

I was using the following very simple rule for switching on the lights:

rule "Stiegenhaus (all ON when one switch ON)"
  when
    Item gWallswitchesStiegenhausON changed to ON 
  then
    gLightsStiegenhaus.sendCommand(ON)
end

gWallswitchesStiegenhausON

gWallswitchesStiegenhausON2

gLightsStiegenhaus

gWallswitchesStiegenhausON2

What would be your suggestion to improve this = shorten the response time = minimizing the delay?

Yes, that’s all. Commanding an openHAB Group results in a big splat of multiple commands to the individual member Items - just what zwave doesn’t like. You’ve no control over that, not even choosing an important one to do first.

I don’t think you can.
https://www.vesternet.com/pages/z-wave-groups-scenes-associations

Will take a closer look at the Vesternet link you posted.
Thanks a lot. Really appreciated!