I have this PR binding working on a 24 node Rpi3 and a 34 node Rpi4 with 700 controllers on SDK 7.18. I have also tested it successfully on a Windows Linux partition with my old 500 controller and one battery node. As noted before, I started with the other 700 controller PR, but have pretty much replaced all the code. The other PR worked, but short-circuited transaction advance process. A recap;
SerialMessage - Two changes: Added the BridgeApplicationCommandClass (A8) and changed the Node destination byte from 5 to 6, if the message is "Bridge" A8.
ZWaveController - One change: Created a public static integer from the controller initialization process to identify a 700 controller (Library =7). This is used in the ZwaveCommandClassTransactionPayload class as noted below (number three).
ZwaveCommandClassTransactionPayload class - One change: Using the Library integer, I switch the Expected Response SerialMessageClass between the BridgeApplicationCommandHandler and the ApplicationCommandHandler so this will work with both 500 and 700 chip controllers.
ZWaveTransactionManager class - Two changes: As in the other 700 PR both the “Bridge” and “non-Bridge” are now allowed options. However, I reworked the byte removal to remove the specific extra byte. With one less byte the “Bridge” message can be processed like the “non-Bridge” message is currently.
Zwave Transaction class - No changes: With the destination node (serial message class) and reply class (TransactionPayload) matching the commands proceed through the stages to DONE.
Zwave Controller Handler - One change: As reported earlier (in my closed PR) the 700 controller can't heal itself, so I excluded it from the network heal process. I could import the Library method so as to keep that for a 500 controller, but from the zniffer logs provided earlier, the 500 controller doesn’t heal very well either.
Signed-off-by: Bob Eckhoff katmandodo@yahoo.com
apella12
commented
7 months ago
I have this PR binding working on a 24 node Rpi3 and a 34 node Rpi4 with 700 controllers on SDK 7.18. I have also tested it successfully on a Windows Linux partition with my old 500 controller and one battery node. As noted before, I started with the other 700 controller PR, but have pretty much replaced all the code. The other PR worked, but short-circuited transaction advance process. A recap;
SerialMessage - Two changes: Added the BridgeApplicationCommandClass (A8) and changed the Node destination byte from 5 to 6, if the message is "Bridge" A8. ZWaveController - One change: Created a public static integer from the controller initialization process to identify a 700 controller (Library =7). This is used in the ZwaveCommandClassTransactionPayload class as noted below (number three). ZwaveCommandClassTransactionPayload class - One change: Using the Library integer, I switch the Expected Response SerialMessageClass between the BridgeApplicationCommandHandler and the ApplicationCommandHandler so this will work with both 500 and 700 chip controllers. ZWaveTransactionManager class - Two changes: As in the other 700 PR both the “Bridge” and “non-Bridge” are now allowed options. However, I reworked the byte removal to remove the specific extra byte. With one less byte the “Bridge” message can be processed like the “non-Bridge” message is currently. Zwave Transaction class - No changes: With the destination node (serial message class) and reply class (TransactionPayload) matching the commands proceed through the stages to DONE. Zwave Controller Handler - One change: As reported earlier (in my closed PR) the 700 controller can't heal itself, so I excluded it from the network heal process. I could import the Library method so as to keep that for a 500 controller, but from the zniffer logs provided earlier, the 500 controller doesn’t heal very well either. Signed-off-by: Bob Eckhoff katmandodo@yahoo.com