MULTI_CMD_CLASS class is not advertized by OZW when it responds to a node info request

[gdurand]

When a device is included into the network it may send a node info request to the controller. The response is used to determine if the controller supports MULTI_CMD_CLASS so that the device can report its statuses in one frame only (very useful to prolong the life of battery-operated devices).
OWZ does respond to the request but advertizes no command class. It should advertize at least MULTI_CMD_CLASS.

This is a follow-up of this post: https://groups.google.com/d/msg/openzwave/NzszXcHE_bM/y9-bYsGhCQAJ

[Fishwaldo]

The NI response is done by the Controller and not directly by OZW. As Sigma did not release the SerialAPI Spec (the protocol to talk to the controller), we don't know how to update the controller with advertised CC's. This needs some reverse engineering to figure out.

[gdurand]

I could log some serial exchange with the controller. The info about supported classes is not provided to the controller when it receives a request from a node: the controller answers autonomously without communication on the serial port. This info is provided by the stack on startup at some point (upon request from the controller perhaps).

Here are 2 logs excerpts where the stack advertizes the command classes 5e 73 86 72 55 56 23 5f 61 22 98 8f 85 59 5a. I included some surrounding frames for some context. We can see that the corresponding frame is preceded by the same long one coming from the controller, but it can be seen elsewhere without the response of the stack about the command classes, so I don't know if the stack really replies to it.
Hope this can help. Tell me if this info is valuable and if you need more. I won't be able to work often on this though.

281051942 R 06 01 25 01 02 06 08 1d ff e3 f9 ff ff 7f 00 3c 00 00 00 00 00 08 1f 00 00 00 00 00 00 00 00 00 00 00 00 00 00 05 00 7e
281052029 W 06 01 04 00 41 01 bb
281052033 R 06 01 09 01 41 d3 96 01 02 02 07 f5
281052046 W 06 01 03 00 02 fe
281052055 R 06 01 25 01 02 06 08 1d ff e3 f9 ff ff 7f 00 3c 00 00 00 00 00 08 1f 00 00 00 00 00 00 00 00 00 00 00 00 00 00 05 00 7e
281052146 W 06 01 16 00 03 03 02 07 0f 5e 73 86 72 55 56 23 5f 61 22 98 8f 85 59 5a 97
281052152 R 06
281054005 W 01 09 00 a0 00 01 0f 02 01 98 c3
281054006 R 06

281325631 R 06 01 04 01 56 01 ad
281325642 W 06 01 03 00 02 fe
281325648 R 06 01 25 01 02 06 08 1d ff e3 f9 ff ff 7f 00 3c 00 00 00 00 00 08 1f 00 00 00 00 00 00 00 00 00 00 00 00 00 00 05 00 7e
281325737 W 06 01 03 00 02 fe
281325741 R 06 01 25 01 02 06 08 1d ff e3 f9 ff ff 7f 00 3c 00 00 00 00 00 08 1f 00 00 00 00 00 00 00 00 00 00 00 00 00 00 05 00 7e
281325836 W 06 01 16 00 03 03 02 07 0f 5e 73 86 72 55 56 23 5f 61 22 98 8f 85 59 5a 97
281325844 R 06
281325851 W 01 05 00 60 06 02 9e
281325853 R 06 01 04 01 60 01 9b
281325872 W 06

[gdurand]

I've just noticed in the frame 281052033 that the sequence 02 02 07 corresponds to the basic, generic and specific devices classes of the controller, so I guess this frame is part of the exchange of information when the stack first connects to the controller.

The first excerpt is from the "startup" of the stack, and the second some minutes after.

[gdurand]

after further investigation, something tells me the applicative frame 03 03 02 07 0f 5e 73 86 72 55 56 23 5f 61 22 98 8f 85 59 5a is composed of the command 03, a flag 03, the generic device type 02, the specific device type 07, the length of the rest of the info 0f, and the rest of the info.

[Fishwaldo]

This capture is from the RF side right? That doesn't help. As we don't know the Serial API command to set it. So at minimum we need Serial API captures of the i utilization of the controller.

[tobiasgraf]

I think the above is a serial capture.

You're saying command 03, which is FUNC_ID_SERIAL_API_APPL_NODE_INFORMATION. This makes kind of sense. The command is already send in Driver::HandleGetSerialAPICapabilitiesResponse()

	Msg* msg = new Msg( "FUNC_ID_SERIAL_API_APPL_NODE_INFORMATION", 0xff, REQUEST, FUNC_ID_SERIAL_API_APPL_NODE_INFORMATION, false, false );
	msg->Append( APPLICATION_NODEINFO_LISTENING );
	msg->Append( 0x02 );			// Generic Static Controller
	msg->Append( 0x01 );			// Specific Static PC Controller
	msg->Append( 0x00 );			// Length
	SendMsg( msg, MsgQueue_Command );

so locking at your frame
281325836 W 06 01 16 00 03 03 02 07 0f 5e 73 86 72 55 56 23 5f 61 22 98 8f 85 59 5a 97
0x0F would be the length followed by the supported command classes.
So I just tried to change this to

	Msg* msg = new Msg( "FUNC_ID_SERIAL_API_APPL_NODE_INFORMATION", 0xff, REQUEST, FUNC_ID_SERIAL_API_APPL_NODE_INFORMATION, false, false );
	msg->Append( APPLICATION_NODEINFO_LISTENING );
	msg->Append( 0x02 );			// Generic Static Controller
	msg->Append( 0x01 );			// Specific Static PC Controller
	msg->Append( 0x01 );			// Length
	msg->Append( 0x8f );            // Multi CMD Class
	SendMsg( msg, MsgQueue_Command );

Added a Danfoss and this is what happens:
2017-03-03 07:19:52.939 Detail, Node124, Received: 0x01, 0x1c, 0x00, 0x04, 0x00, 0x7c, 0x16, 0x8f, 0x01, 0x04, 0x03, 0x80, 0x03, 0x64, 0x06, 0x43, 0x03, 0x01, 0x42, 0x08, 0x02, 0x04, 0x46, 0x08, 0x00, 0x7f, 0x02, 0x84, 0x07, 0x58
It now sends MultiCmd, so this seems to work.

Is there a way to get all OZW supported command classes?

[gdurand]

Easy to implement then. Great news.
For ease of use, here is the detail of the command classes reported by zware:
5E - COMMAND_CLASS_ZWAVEPLUS_INFO
73 - COMMAND_CLASS_POWERLEVEL
86 - COMMAND_CLASS_VERSION
72 - COMMAND_CLASS_MANUFACTURER_SPECIFIC
55 - COMMAND_CLASS_TRANSPORT_SERVICE
56 - COMMAND_CLASS_CRC_16_ENCAP
23 - COMMAND_CLASS_ZIP
5F - COMMAND_CLASS_ZIP_GATEWAY
61 - COMMAND_CLASS_ZIP_PORTAL
22 - COMMAND_CLASS_APPLICATION_STATUS
98 - COMMAND_CLASS_SECURITY
8F - COMMAND_CLASS_MULTI_CMD
85 - COMMAND_CLASS_ASSOCIATION
59 - COMMAND_CLASS_ASSOCIATION_GRP_INFO
5A - COMMAND_CLASS_DEVICE_RESET_LOCALLY

[tobiasgraf]

@Fishwaldo what do you think about this? Just add some command classes to that list or implement something like CommandClasses::getSupportedCommandClasses() and add all commandClasses that are registered?

[Fishwaldo]

I'll be able to look at this next week.

[Fishwaldo]

But we can't add "all" commandclasses, as most don't respond to a "set" function. (Controlling versus controlled)