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 …
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.
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”.
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.