It would be great to have some migration guides from Raspberry Pi with Razberry 7 pro to Home Assistant + Zwave.js and a USB dongle (including some recommendations which USB sticks work).
Something like this
1. add USB-Controller to existing Z-Way with RaZberry
2. do controller switch in Z-Way
3. extract S0,S1 & S2 keys
4. install HA & zwave.js to new device (would like to keep existing Pi as fallback).
5. insert USB-Conroller into HA
6. dicover devices
7. add S0,S1 & S2 keys
8. reconfigure rules & automations in HA
Z-Wave.Me future (discussion)
-
seattleneil
- Posts: 223
- Joined: 02 Mar 2020 22:41
Re: Z-Wave.Me future (discussion)
The approach you've describer will mostly work, but it's not ideal for the following reasons:
1. The controller switch approach will cause the new controller to have a node ID that is not 1. While a controller with a ID node that's different than 1 should work, it will introduce some subtle problems. For example, the Lifeline association in a device is frequently hard-coded to send messages to node ID=1.
2. S2-included devices won't work with the new controller. This is because the S2 keys are used to create a device-specific key during the S2 inclusion process. The S2-derived device-specific keys are not transferred on a controller switch.
There's a fairly complicated procedure for adding a new controller with the same network ID as an existing controller and node ID=1. You can read about the approach here: https://github.com/zwave-js/zwave-js/discussions/6786
For many users, my sense is that it will be easier to exclude/re-include their Z-Wave devices with a new controller.
An alternative migration approach is for @PoltoS to provide a Razberry 7 backup tool that dumps the NVRAM into a format the Zooz ZAC93 and ZST39 controllers support (see: https://www.thesmartesthouse.com/collec ... ontrollers) using zwave-js-ui. This approach allows @PoltoS to create a simple migration path: (1) Run backup on RazBerry, (2) Use zwave-js-ui to restore the backup onto either a Zooz ZAC93 or ZST39 controller. Ideally, the Razberry Gen 2 (500-series) would have a similar migration approach.
1. The controller switch approach will cause the new controller to have a node ID that is not 1. While a controller with a ID node that's different than 1 should work, it will introduce some subtle problems. For example, the Lifeline association in a device is frequently hard-coded to send messages to node ID=1.
2. S2-included devices won't work with the new controller. This is because the S2 keys are used to create a device-specific key during the S2 inclusion process. The S2-derived device-specific keys are not transferred on a controller switch.
There's a fairly complicated procedure for adding a new controller with the same network ID as an existing controller and node ID=1. You can read about the approach here: https://github.com/zwave-js/zwave-js/discussions/6786
For many users, my sense is that it will be easier to exclude/re-include their Z-Wave devices with a new controller.
An alternative migration approach is for @PoltoS to provide a Razberry 7 backup tool that dumps the NVRAM into a format the Zooz ZAC93 and ZST39 controllers support (see: https://www.thesmartesthouse.com/collec ... ontrollers) using zwave-js-ui. This approach allows @PoltoS to create a simple migration path: (1) Run backup on RazBerry, (2) Use zwave-js-ui to restore the backup onto either a Zooz ZAC93 or ZST39 controller. Ideally, the Razberry Gen 2 (500-series) would have a similar migration approach.