Multicast

[jdiegmueller]

All--

Hello!

I am attempting to use Zwave multicast in order to update up to ~35+ Inovelli LZW-31SN (Red Series Dimmer) LEDs, and I'm not sure if I'm doing something wrong or if multicast support simply isn't there yet -- I've seen conflicting information here in Github.

So the following strongly suggests there is multicast support, seeing as it gives an example:

• https://zwave-js.github.io/zwavejs2mqtt/#/guide/mqtt?id=api-call-examples

However, when I use the above example (fixing the lack of comma after the nodes[] array), nothing happens (confirmed with Zniffer). Here's what I publish based on the example:
Topic:
zwave/_CLIENTS/ZWAVE_GATEWAY-jdtest/multicast/set

JSON:
{ "nodes": [50, 55], "commandClass": 112, "endpoint": 0, "property": 14, "value": 1 }

I see there is an API call named writeMulticast. When I use this, the configuration parameter DOES get set -- but singlecast messages are used (again, confirmed with Zniffer).

I know these Inovelli switches support multicast, as I can use PC Controller 5.x with the exact same Zstick and successfully set configuration parameter 14 using multicast (again, confirmed with Zniffer).

Insight welcomed. Thank you!

[jdiegmueller]

I see there is an API call named writeMulticast. When I use this, the configuration parameter DOES get set -- but singlecast messages are used (again, confirmed with Zniffer).

Forgot to include, for writeMulticast I am publishing to the following topic:
zwave/_CLIENTS/ZWAVE_GATEWAY-jdtest/api/writeMulticast/set

Using the following JSON:
{ "args": [ [ 50, 55 ], { "commandClass": 112, "endpoint": 0, "property": 14 }, 5 ] }

This "works" but is itereated singlecast, as opposed to multicast.

Thanks.

[robertsLando]

I don't think multicast works for command class configuration, @AlCalzone ?

[jdiegmueller]

I don't think multicast works for command class configuration, @AlCalzone ?

Oh, well that's a bummer.

Truth be told, my sole reason for for kicking the tires on zwavejs2mqtt was to try and do exactly this. Do you have any other projects/suggestions I would be able to set configuration parameters using Zwave multicast?

PC Controller 5.x can do it with the exact same Zstick, so I know it's technically possible from a Zwave perspective. But since Hubitat doesn't (currently?) do multicast at all, and since I don't know of any means to remotely command PC Controller 5.x to do it for me .. I'm searching for alternatives.

Thanks either way.

[robertsLando]

Using multicast maybe nope but sending those values one node by one it's working why is that a problem?

[jdiegmueller]

While my example technically works, in practice it doesn't:

I have ~35 of the switches, and changing a configuration parameter (or two, in some cases) on each -- all at once -- essentially freezes the Zwave mesh for a number of seconds. Long enough that it definitely gets noticed by users, maybe 3-6 seconds. The workaround I implemented was to whip up a rudimentary queueing system, so all these commands are spaced out and not sent all at once. This "works", but makes it unrealistic to drive the LEDs as notification devices given the frequency I would like to change them at.

For example, I currently use green vs yellow vs red to indicate if the room has my "Motion Lighting Mode" enabled, or if it is disabled locally or globally. I'd love to add other notifications, like alternating between red/yellow/green and, for example, purple every ten seconds to tell me if I've left a door open or whatnot. Doing this would require sending configuration parameter 13 once every ten seconds to change the color of the LED, which isn't realistic since that would keep the Zwave mesh busy pretty much 100% of the time.

Less important technically, but nice-to-have from an end user perspective: Doing this all with multicast would make the LEDs change color (13) or brightness (14) at the exact same time, as opposed to seeing them change one-by-one. Currently, depending on what room you're in, it's very obvious that they are being changed one-by-one. When I multicast from PC Controller 5.x, they all change instantly and in tandem. Very cool.

Maybe I need to take another approach?: Is it possible with zwavejs2mqtt to send raw Zwave frames if I know how I want to format them? Using a Zniffer I could figure out exactly the small number of variations that I need, and then just feed zwavejs2mqtt the frames.

For example, I have a motion sensor (node 79) which multicasts to both my primary (node 1) and secondary (node 30) Zwave controllers on movement. A Zniffer shows me the raw Zwave multicast frame looks like so:
EF F5 37 A2 49 02 01 30 1D 01 00 00 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 71 05 00 00 00 FF 07 08 00 B2

While I do see my home ID, source node, destination nodes, etc as hex in the above, using this method I wouldn't even need the know-how to decode the frame; I'd just send the command I want from a Zstick in PC Controller 5.x, capture the contents of it, and then use that to send the specific multicast frame I want to send.

[robertsLando]

@jdiegmueller About the possibility to send custom raw packets I think it is possible but before going into that I would prefer asking @AlCalzone if there is a better way

[AlCalzone]

Technically it is possible. The CC API in node-zwave-js is currently limited to singlecast though because it will look up the value size for you, which is device-specific and could be ambiguous for multicast.

If you know the value size, you can send the command yourself:

const cc = new ConfigurationCCSet(driver, {
	nodeId: [50, 55],
	parameter: 14,
	value: 5,
	valueSize: /* whatever the value size for this parameter is */,
});
await driver.sendCommand(cc);

I think zwavejs2mqtt has a way to let you do that.

The concern is valid though - I've raised zwave-js/node-zwave-js#2651 to track this.

[robertsLando]

@jdiegmueller Using latest z2m version this should finally work:

const {ConfigurationCCSet} = this.require("zwave-js");
const cc = new ConfigurationCCSet(driver, {nodeId: [50, 55], parameter: 14, value: 5, valueSize: 1}); 
await driver.sendCommand(cc);

[jdiegmueller]

@jdiegmueller Using latest z2m version this should finally work:

const {ConfigurationCCSet} = this.require("zwave-js");
const cc = new ConfigurationCCSet(driver, {nodeId: [50, 55], parameter: 14, value: 5, valueSize: 1}); 
await driver.sendCommand(cc);

Ok, so this doesn't appear to be doing the trick for me. I did a git pull, npm i, npm run build, and restarted zwavejs2mqtt. I'm using MQTT topic:

zwave/_CLIENTS/ZWAVE_GATEWAY-jdtest/api/driverFunction/set

with JSON payload:

const {ConfigurationCCSet} = this.require("zwave-js"); const cc = new ConfigurationCCSet(driver, {nodeId: [50, 55], parameter: 14, value: 5, valueSize: 1}); await driver.sendCommand(cc);

I do get a response back:

{ "success": true, "message": "Success zwave api call", "args": [] }

But my Zniffer shows no activity, neither multicast nor singlecast.

Here's the debug-level snippet from zwavejs2mqtt.log:

2021-05-24 13:26:13.057 INFO MQTT: Message received on zwave/_CLIENTS/ZWAVE_GATEWAY-jdtest/api/driverFunction/set, 'const {ConfigurationCCSet} = this.require("zwave-js"); \nconst cc = new ConfigurationCCSet(driver, {nodeId: [50, 55], parameter: 14, value: 1, valueSize: 1}); \nawait driver.sendCommand(cc);' 2021-05-24 13:26:13.059 INFO ZWAVE: Calling api driverFunction with args: [ [length]: 0 ] 2021-05-24 13:26:13.064 DEBUG MQTT: Publishing to zwave/_CLIENTS/ZWAVE_GATEWAY-jdtest/api/driverFunction: { success: true, message: 'Success zwave api call', result: undefined, args: [ [length]: 0 ] } with options { qos: 1, retain: false } 2021-05-24 13:26:13.062 INFO ZWAVE: Success zwave api call driverFunction { success: true, message: 'Success zwave api call', result: undefined }

Just to be sure I'm on the right branch, and because I am not great at it, here's what git is telling me:

root@raspberrypi:~/zwavejs2mqtt# git status On branch master Your branch is up to date with 'origin/master'.

Thanks for any help.

[jdiegmueller]

Ok, well, I forgot to put the code you provided in to args and actually make the JSON in to JSON. So ignore what I said above.

That said, I modified the JSON payload to:
{ "args": [ "const {ConfigurationCCSet} = this.require('zwave-js');const cc = new ConfigurationCCSet(driver, {nodeId: [50, 55], parameter: 14, value: 1, valueSize: 1}); await driver.sendCommand(cc);" ] }

And now I get this in return:
{ "success": false, "message": "Message dropped because of an unexpected error: The node for this CC does not exist or the driver is not ready yet", "args": [ "const {ConfigurationCCSet} = this.require('zwave-js');const cc = new ConfigurationCCSet(driver, {nodeId: [50, 55], parameter: 14, value: 1, valueSize: 1}); await driver.sendCommand(cc);" ] }

Did I dork something up, here?

[AlCalzone]

No, you didn't - I tried it too and get the same error. The CC command itself assumes that is belongs to a single node. So you actually need zwave-js/node-zwave-js#2651 for this to work. Sorry.

[robertsLando]

Ok so let's wait for that PR

[AlCalzone]

zwave-js/node-zwave-js#2695

[robertsLando]

Cool snippet 😆 Likely I added the driverFunction to test such things. I have edited your snippet to match the one he can send, require must be accessed from context using this.require

[jdiegmueller]

Pulling this out of the wayback machine:

So it took me 8 months, but I did finally get around to standing up a HomeAssistant instance. I have tied zjwavejs2mqtt on a Pi 4B in via the HA WS integration. I'm using the HA service zwave_js.multicast_set_value, and triggering that in a variety of ways to do the multicast configuration sets. Works great.

I still want to eliminate the ACK request on the multicast set (I understand the implications). Is there an option I can pass along to HA via the service call to request this, or does this still require the custom mojo you guys were trying to show me above?

[robertsLando]

Is there an option I can pass along to HA via the service call to request this, or does this still require the custom mojo you guys were trying to show me above?

Nope AFAIK

[jdiegmueller]

Hmm ok.

Should the HA service be sending multicast and then immediately follow up with a unicast to each node? Seems like that defeats the purpose of the multicast:

[jdiegmueller]

Disregard; I now understand the choices are "multicast with unicast follow-up" or "multicast without unicast follow-up"; I mistakenly thought "request ACK" was a flag in a multicast message.

[tommyjlong]

Hi,
May I ask what is the difference between ../multicast/set and ...api/writeMulticast/set ?
Thanks

[robertsLando]

They do the same :) Just the payload is different