Multicast best practises

[AlCalzone]

@hanskroner I've implemented multicast support a while back and users are starting to test it.

From zwave-js/zwave-js-ui#25 (comment):

I published the following json to three nodes setting them to 0. Node 3 turned off physically, but remained on in HA. Node 5 dimmed down, but did not turn off completely, and also remained on in HA. (This is odd...nodes 3 and 5 are both GE dimmers, the same model, with the same ramp rate/timing. Publishing a payload to just node 5 with a targetValue of 0 does it make it go fully off.) Running it a second time with 0 did then fully turn off Node 5. Both started at the same level 50. I've tried this a few times and Node 5 does dim down instead of going off about 80% of the time if it is starting at level 50. If starting at level 99 it did seem to go off, so maybe it is a device bug? I've seen a similar dimming instead of off problem with certain step settings with certain starting levels, so I wouldn't discount this being a bug with the device.

The part about remaining on in HA is because we don't poll after a multicast (for obvious reasons). I'm wondering about the part that some devices don't go fully off. I remember that the specs mentioned something about singlecast followup after the multicast, but that seems like it defeats the purpose of using multicast.

I know you're not used to the log format (and this time there's no serial data), but these are the messages that are being exchanged:

18:05:48.995 DRIVER » [REQ] [SendDataMulticast]
                      │ target nodes:     3, 5, 9
                      │ transmit options: 0x25
                      │ callback id:      81
                      └─[MultilevelSwitchCCSet]
                          target value: 0
18:05:49.013 DRIVER « [RES] [SendDataMulticast]
                        was sent: true
18:05:49.204 DRIVER « [REQ] [SendDataMulticast]
                        callback id:     81
                        transmit status: OK

Do you have any best practises related to multicast?

[hanskroner]

The part about remaining on in HA is because we don't poll after a multicast (for obvious reasons). I'm wondering about the part that some devices don't go fully off.

Without actual Z-Wave traffic traces, all I'd be going is guessing 😞

I remember that the specs mentioned something about singlecast followup after the multicast, but that seems like it defeats the purpose of using multicast.

The specs. mention that it's a good idea to follow a multicast with singlecasts to each node in the multicast. Because there's no ACK to a multicast, you use the follow-ups to get individual delivery confirmations. Z-Wave, for the most part, avoids "relative" changes, so the singlecast follow-up shouldn't affect the receiving node's state if it already changed (or is changing) with the multicast. The singlecast isn't defeating the purpose of the multicast, it's just there to provide a delivery guarantee without sacrificing the time-critical delivery a multicast can give.

It might be a little easier to visualize an example: the typical, exaggerated one is a room with 9 roller shutters (blinds) - but it works just as well imagining they're lights. In this scenario, you want to bring the rollers down 80% all together, at the same time, either by setting a scene or using the Multilevel Switch Command Class. If you singlecast each of them, by the time you get to the last shutter the rest will have been moving for a while - leading to a "waterfall" effect, which is not what you wanted. The effect will be even more pronounced if you're polling for state changes with GETs in the middle of all this.

Instead, you can multicast the command to all 9 shutters, so they receive it at almost exactly the same time. But what if one of the nodes was out of range? Or was jammed temporarily, maybe by another node it's neighbors with (but none of the other nodes are)? That's what the single cast follow-up is for. That one shutter will lag slightly behind the rest, but at least it will go down. The multicast tries to give the desired user experience while the singlecast tries to ensure the desired outcome.

Do you have any best practises related to multicast?

From a protocol perspective, the specs. give you the right guidance: follow-up with singlecasts if you want delivery confirmations; there's not much else to it than that. From a usability perspective, you're in a very tough spot because multicasts aren't routed in Z-Wave. As the controller, you'll be able to multicast only to nodes that are in direct range. If the controller is centrally located in a small network, that'll likely work out fine - this isn't the case for the majority of deployments though.

One approach you can take is to provide clients the ability to create multicast "groups." The library, knowing which nodes it can reach directly, limits which nodes can be members of these groups. This severely limits the usability of groups, but it aligns well with the reality of what multicast can do in Z-Wave.

[AlCalzone]

Without actual Z-Wave traffic traces, all I'd be going is guessing

I can try to replicate and debug in my production network once I get my hands on a sniffer ;)

The explanation makes sense to me. However I'm a bit confused about this part of the specs (INS13954-13, Page 111/112):

Transmit the data buffer to a list of Z-Wave Nodes (multicast frame). If the transmit optionflag
TRANSMIT_OPTION_ACK is set the data buffer is also sent as a singlecast frame to each of the
Z-Wave Nodes in the node list.
The completedFunc is called when the frame transmission completes in the case that ACK is not
requested; When TRANSMIT_OPTION_ACK is requested the callback function is called when all single
casts have been transmitted and acknowledged.
The transmit status TRANSMIT_COMPLETE_NO_ACK indicate that no acknowledge is received from
the destination node. The transmit status TRANSMIT_COMPLETE_FAIL indicate that the Z-Wave
network is busy (jammed). The data pointed to by pNodeIDList should not be changed before the
callback is called.

Since zwave-js uses the ACK flag by default, this should mean that the stick has sent a singlecast followup to each node in the list and that it has received an acknowledgement from each, since we received a positive callback. Correct?

[hanskroner]

Since zwave-js uses the ACK flag by default, this should mean that the stick has sent a singlecast followup to each node in the list and that it has received an acknowledgement from each, since we received a positive callback. Correct?

That should be the case, yes. The only way to confirm it, would be with a Zniffer.