Using zwave.subscribeToIncoming() and zwaveCommandRec()

Hi All,

I've been playing around lately with a plugin using indigo.zwave.subscribeToIncoming() and zwaveCommandRec(). This isn't the next great plugin, but instead a way for me to learn more about the Z-Wave protocol and to learn more about writing Indigo plugins. With that in mind, here is an example of one of the functions of the plugin - sending a request and decoding the response:

Sent:
(Node 37): 01 0B 00 13 25 04 70 0C 00 04 25 60 FB (True)

Response:
(Node 37): 01 1B 00 04 00 25 15 70 0D 00 04 02 52 65 76 65 72 73 65 20 74 68 65 20 64 65 66 61 94
(Node 37): 01 1B 00 04 00 25 15 70 0D 00 04 01 75 6C 74 20 4F 6E 2F 4F 66 66 20 72 6F 63 6B 65 F4
(Node 37): 01 14 00 04 00 25 0E 70 0D 00 04 00 72 20 73 65 74 74 69 6E 67 99

The command sent is a Configuration Command Class / Configuration Info Get. This gets information (a description) of what a parameter is used for. This is similar to the Configuration Name Get which requests the name of a parameter. The 3 response frames are all Configuration Info Report commands. The ascii message is spread across 3 frames and combined translates to "Reverse the default On/Off rocker setting". Byte 12 of each of the response frames indicates how many reports (frames) are remaining. Byte 12 of the first response frame is 2, byte 12 of the second response frame is 1 and byte 12 of the third response frame is 0 (indicating that it is the last report).

Questions

1. Should the plugin confirm that the checksum of a frame is correct or does that happen before the frame is received via zwaveCommandRec()?
2. Is it possible/likely that the 3 response frames received would be out of order?
3. Related - Is it possible/likely that a frame was lost?
4. Related - If the answer to either of the last 2 questions is yes, how would a plugin know it received the complete response (all 3 of the frames in the example above)?
5. If multiple commands (requests) are sent to a device at about the same time, can the plugin assume that all response commands for one of the requests will be received before responses from another request are received?

Much of my confusion is not so much about the Z-Wave protocol, although some is, it's more about what is happening under the hood with Indigo before a frame is obtained by zwaveCommandRec().

Thanks in advance for any help!

We'll need @Matt for this - I've somehow missed the thread but those Zwave questions are beyond me.

[matt (support)]

I missed this thread as well. Not sure why it didn't show up in my unread feed....

Should the plugin confirm that the checksum of a frame is correct or does that happen before the frame is received via zwaveCommandRec()?

Indigo tests the checksum and sends a NAK if it doesn't match (which will hopefully cause the module to re-send the response). Your callback won't be called unless the checksum matched.

Is it possible/likely that the 3 response frames received would be out of order?

I'd say it is either impossible or at the least very unlikely.

Related - Is it possible/likely that a frame was lost?

Z-Wave's retry mechanism is pretty robust. If it fails (either no frames or partial frames) the module is likely very close to out-of-range or there is severe congestion (misconfigured or malfunctioning module). In general I think you'll get all the report packets or none of them (module not reachable).

Related - If the answer to either of the last 2 questions is yes, how would a plugin know it received the complete response (all 3 of the frames in the example above)?

You would have to set a timer and just bail if the response doesn't arrive in a reasonable amount of time. I'm not sure what the ideal reasonable amount of time is, but during module syncing we give up if we don't get a response (often a report) back within 8 seconds.

If multiple commands (requests) are sent to a device at about the same time, can the plugin assume that all response commands for one of the requests will be received before responses from another request are received?

I don't know the exact answer, but I'd recommend serializing your queries to the module. During Indigo's sync process isn't doesn't send an additional query until the last one is complete (or the timeout occurs).

Thanks, Matt. This is all very good news as it makes decoding a little easier. Even though the plugin is filtering what responses it gets, I was worried about all the various conditions that might occur.

Is it possible/likely that the 3 response frames received would be out of order?

I'd say it is either impossible or at the least very unlikely.

Related - Is it possible/likely that a frame was lost?

Z-Wave's retry mechanism is pretty robust. If it fails (either no frames or partial frames) the module is likely very close to out-of-range or there is severe congestion (misconfigured or malfunctioning module). In general I think you'll get all the report packets or none of them (module not reachable).

Good! I guess this is really a Z-Wave protocol question. Suppose that somehow the first frame didn't show up or maybe it showed after the other 2 frames, but after the plugin quit waiting on responses. Is there some way to know that there was an Info Report frame missing?

[matt (support)]

Good! I guess this is really a Z-Wave protocol question. Suppose that somehow the first frame didn't show up or maybe it showed after the other 2 frames, but after the plugin quit waiting on responses. Is there some way to know that there was an Info Report frame missing?

Not that I can think of. Really the frames should include two bytes to indicate the frame position (current frame and total frame) but they didn't ask me for input.

Hopefully it is the case that the module only sends the next frame in a sequence after it receives an ACK for the current frame. However, from what I can see the protocol doesn't appear to detail that requirement.