Using zwave.subscribeToIncoming() and zwaveCommandRec()
Posted: Wed May 13, 2020 12:42 pm
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
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!
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
- Should the plugin confirm that the checksum of a frame is correct or does that happen before the frame is received via zwaveCommandRec()?
- Is it possible/likely that the 3 response frames received would be out of order?
- Related - Is it possible/likely that a frame was lost?
- 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)?
- 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!