I think you are misunderstanding how associations work.
Zwave itself does not have an association limit, but each device does. The limit for the inovelli switches is 5.
Association groups are a way to allow 1 device to directly control other devices (bypassing the hub).
Associations only work in a single direction. If switch M1 is associated with switch S1, then pressing the on button on M1 will cause it to tell S1 to also turn on. However, turning on S1 will NOT cause M1 to turn on because S1 is not associated with anything.
In order to get a virtual 3-way going, we also need to set up an association on S1 (so it also controls M1). Now, buttons on M1 will also control S1, and buttons on S1 also control M1. This gets us most of the way there, but has an unwanted side effect: If M1 controls S1, and S1 controls M1, then the devices get stuck in an infinite loop trying to control each other. To fix this, we use parameter 12 (on teh red series dimmer) to prevent zwave commands from being forwarded.
I think there is a problem with your table. You have the same switches listed multiple times. I did my best to correct it based on what I think you are trying to illustrate:
| Switch |
Association |
Number of Associated devices |
| M1 |
M2, V1, V2 |
3 |
| M2 |
M1 |
1 |
| V1 |
M1 |
1 |
| V2 |
M1 |
1 |
In the example above, switch M1 is associated with 3 devices (M2, V1, V2) and the other switches are only associated with 1 (M1). This does not exceed any limits or cause any problems.
See above. “Association Group” is probably not the best term to use here, because you are not really creating a logical group of devices.
Not really. However, its rare to need to in the first place (your example from above would work just fine because you are not associating more than 5 devices to a single switch). The 5 device limit tends to be more of an issue if you are trying to control smart bulbs. For example, if I have a switch and want to use it to control 6 zwave smart bulbs, I would not be able to do it with associations (because I can only associate 5 of them). I would instead need to control the bulbs with my hub. The switch would send events or scenes to the hub, and the hub would then control all the bulbs. This method generally works fine, but it can cause minor delays due to latency if your hub relies on the cloud, and would not work if your hub goes offline for some reason.
You always need a hub (controller) with zwave (it is used to include devices into the zwave network, and the hub is used to actually set up the associations between devices). However, you can still control the switches locally or with other associated zwave devices in your network if your hub were to go down (provided you didnt change a bunch of config settings to disable local control or something). Zwave was not designed to run without a hub, but basic functionality will still work.
The hub can control any device on the zwave network (it doesnt need any special associations). Technically, if you are using your hub to control devices based on pressing buttons on a switch, it is not as fast as direct association (because a message is being sent to the hub, and then another message from the hub to the target devices), but I cant really tell the difference).
With direct association, the switch is directly controlling other devices.
When going though the hub, you are basically setting up an automation. When the switch sends a status update to the hub because you pressed the on button, the hub then fires an automation of your choosing that does whatever you tell it to do.
You may or may not experience a popcorn effect. The popcorn effect is typically caused by one of 2 things: how your hub decides to send the command, and signal strength.
- When sending commands to multiple devices, there are 2 options for the hub: It can send multiple commands (one for each device), or it can send a special multicast command with multiple addresses. I am not sure if Home Assistant supports multicast yet, so you may still experience this. Zwavejs is much much faster than the old zwave integration though, so even if you do experience the popcorn effect it is nowhere neat as bad as it used to be.
- Inovelli switches do support multicast though, so if you use association there is a much lower chance of the popcorn effect
- If a command cannot reach its intended target directly (due to signal strength), the device may need to route the command through a nearby node on the mesh. Although not typically noticeable, it does add some latency and may result in the popcorn effect.
I would argue yes. One of the main uses of smart switches is for automation, and automation will always require some sort of hub to do all the processing.
Most of the switches in my house use zwave. If my local network goes down, there is no direct impact because zwave does not use wifi. I may temporarily use functionality of some of my automations, such as triggering outside lights at night when my phone connects to wifi, but I still have full control over the lights from the switch itself. If my hub goes down, I can still control the lights locally, but I do lose some automations, such as automatically turning on the bathroom light when motion is detectged and it is night.
