Complex system upgrade OOP

🛎️ Get Help
1

My ask is for suggustions on order of operations for upgrading a hub share network currently consisting of a c7 and two c8s.

My goals are:

  1. Minimize down time.
  2. Avoid resetting individual zigbee devices. There are 100+ with many over 30ft high.
  3. Completely change out zwave (fsk) switches for zwlr (dsss) switches.
  4. Migrate all 3 existing hubs to 3 c8 pro.

Background.
6 year old custom home designed with smart lighting has zigbee lighting inside and out and zwave switches used as signaling devices ( no loads) to control lighting via 3 networked hubs.

The primary driver for this upgrade are the 42 nutone NWT00Z zwave (non plus) switches. These have proven to be unreliable and slow with a large number of intermittent and complete HW failures. Failure modes include channel jamming (jabber), micro switches and internal power supply/overheat. In the best of times, the very slow data rate of frequency shift keying (fsk) modulation and complex multihop mesh made some pathways very slow.

Several years of failures and replacemts left the meshes riven with ghosts with zwave repair reporting many unreachable nodes even though many still somehow function.

The replacements are long range ZEN71s programmed in scene mode (relay disabbled). ZWLR's star topology combined with wide band, direct sequence spread spectrum modulation performed well in our qualification of a single unit.

When replacing the NWT00Zs, we have been creating vertual switches, swapping them into apps, dissociating the failed hw switch (not always possible), replacing hw switch, swapping back from vertual. Not looking forward to using that method 42 times. We would also like to end up with a pure zwlr star with no mesh and no ghosts.

Since we have to touch the entire system to deal with the switches, it seems like the right time to refresh the hubs also.

Been thinking about setting up the new c8 pros in parallel just to set up switches and creating clean zwlr only databases. Then somehow merging the clean zwave with the zigbee when we migrate the hubs.

This would mean powering up all 42 switches on a bench (lots of wire and lever nuts) however, since zwlr is a star, there are no routes to consider.

However, we don't know how to merge the databases and if we blow up the zigbee databases it will take a week on ladders to fix.

Ideas welcome.

Thanks,

Kent

1 Like
2

Unfortunately there is no way to merge multiple hubs into one. I went through this earlier this year moving from 4 protocol based hubs (lan, Zwave, Zigbee, and coordinator/apps) to 2 C8 Pro hubs where I combined the 2 radio hubs on to one C8 Pro hub and the coordinator became my lan and apps hub with all radio devices meshed to it.

I personally chose to migrate my Zwave hub via migration process to the new C8 since I have several pain to exclude/pair Zwave devices and then I manually reset and paired my Zigbee devices to this hub. It was a pain but worth it in the end.

1 Like
3

You can just include the new device first, then swap direct from old to new, then exclude the old device. Much less steps in HE. You can bench include the new switch before physically swapping them in the wall.

1 Like
4

Thanks for your reply.

Sorry I was not clear,

We are starting with 3 seperate hubs (c8, c8, c7) which are linked via hub mesh and migrating to 3 hubs (c8p, c8p, c8p) in the same topology.

C8 -> c8p
C8 -> c8p
C7 -> c8p

The merge of databases I was asking about are zwave and zigbee data bases on each hub.

In the case where a merge were possible the steps might be.

  1. Cloud backup old hub for zigbee and rules skipping old zwave database.
  2. Bench associate zwlr switches with new hub using same switch names as were used in old hub rules.
  3. Take old hub offline,
  4. Rename new hub to old hub name and assign new hub IP to old hub IP (for hub mesh)
  5. Selectively restore (migrate) zigbee and rules to new hub.

Intended result, new hub has old zigbee and rules database merged with new zwlr database.

This would be repeated for each old to new hub migration.

What we are not clear on is step 1 (skipping old zwave database) and step 5 (selectively restore). The major concern is that zgibee and rules make it from old to new intact and properly linked to new zwlr database.

Please feel free to sugest different steps, order and expand on anything I missed.

Thanks.

5

That is great news, thank you.

I think buliding the new star zwlr database requires the use of smart start instead of the the include method. Is that right?

Thanks.

6

Cloud backups will include any active radios on that hub and in the cloud backup list you will see a check mark for the radios included in that backup. When restoring a cloud backup or migration backup on a target hub you can select what you want to restore specifically. So if your backup includes Zwave and you wish to exclude, you can uncheck the box and it won’t get restored on that hub. But please be aware that the database backup will include the device entry for those Zwave devices that you will need to delete or swap with your new device.

1 Like
7

This would not work, the database restore would remove all of your included z-wave devices from the hub DB (leaving them on a radio with no associated device).
You would need to restore whatever backups you want FIRST, then you can manually migrate other devices after that.

Correct LR requires a SS include with security to work.

1 Like
8

Let me see if I understand this.

A radio database contains device information for the media layers (osi 1,2,3). In zwave this would include things like zwave or zwave+ or zwlr, the topology such as mesh or star and device IDs.

Then there is a seperate device database that contains the configuration of each device. If I am understanding right, this is where the apps are logically connected with the device IDs.

Because we are texting please forgive my building on the above (which might be wrong).

I wonder what happens to the device IDs in the device database when the device database is restored to a hub with an existing zwlr database with different device IDs (12 bits). How would this be reconciled? By device name?

If the old device database link to new radio database thing is a real issue, a work around might be to swap all the zwave devices with virtual counterparts before the cloud backup of the old hub. Then there would be no physical device IDs to reconcile during the restore to the new hub. A final swap resolves the new zwlr device IDs with the old device database. Lots of swapping though.

However, I might have this totaly wrong, please correct as needed.

Thanks.

9

Correct

Very bad things

It wouldn't be, you would just have a giant mess.

As stated multiple times now. There is NO WAY to merge two hubs together. You can restore a backup from one hub first (partial or full) and then after that manually migrate/add devices to that hub. There is no other way to do it, end of story.

5 Likes
10

Ok, so lets see if this is a proceedure that encompasses all the excellent coaching.

For each migration and switch set chage out.

  1. Swap all existing zwave devices with vertual counterparts.
  2. Reinitialize zwave radio to create a clean, empty zwave database. This removes all legacy devices and ghosts.
  3. Cloud backup old hub.
  4. Take old hub offline.
  5. Migrate to new hub.
  6. Bench associate zwlr switches with new hub using ss.
  7. Swap out vertual devices with newly installed ones.
  8. Rename new hub to old hub name and assign new hub IP to old hub IP (for hub mesh)

Note, step two is to prevent the existing zwave databases from potentially causing problems with the new hubs.

Am I missing anything?
Anything extra?

Thanks!

11

Somewhere in there after 2 and before adding the new ZW devices you will want to remove the old devices from the hubs device list (leaving the virtual placeholders with the apps attached to them alone). Resetting the radio will only clear them from the radio not the device list. If you leave the old devices in there you might have DNI conflicts when adding new ZW devices.

You could also just edit the DNI of each of those old devices (add _OLD to each) in the devices list instead of creating virtual devices and swapping to them. Then you swap directly from old to new and remove the old devices as the last step. Whatever you are comfortable with will work.

2 Likes
12

I think I see.

The device network id is unlinked with the radio database by appending _old (essentially making the dni invalid) without affecting the link between the device database and apps because they use the device name.

Later a swap moves in a new, valid dni with the new device.

If I understand correctly, this would save quite a few steps.

Thanks.

13

Yes that is basically it, the apps actually link to the device via the device uid (as seen in the url on the device page). And yes the DNI is what links it to the radio database.

Yes it would save some steps, which is why I suggested that method. Its a little more complex, but less work if you understand how to do it correctly.

14

Thank you,

I agree its conceptually more complex however, less key strokes are fewer opertunities for mistakes.

Is a device with an unlinked dni functionally similar to a vertual device?

15

Yes basically the same. The only thing that makes a z-wave device entry special is the DNI that links it to the radio device entry, a few data points in the data section, and the driver used to talk with the radio/device. Same goes with Zigbee devices, except Zigbee will retain the DNI even when radio is reset, it is more like a MAC built into the device. So Zigbee devices are very easy to manually migrate (if you have access to push the reset buttons on them). You dont have to do any removals or app swaps for Zigbee, just reset and pair again.

16

Ok, this may simplify yet another task.

The driver for the ZEN71 is somewhat more capable and complex than the generic driver for the NWT00Z.

I was planning on creating a rule to interface between the two so I dont have to touch all the existing rules.

I can just clone this interface rule, with appropriate name changes, for each NWT00Z replaced.

The interface rule would be triggered by a ZEN71 and manipulate a virtual NWT00Z to trigger an existing rule.

Seems like I can just use NWT00Z device entries that are unlinked from the radio and aviod the need to create and swap in virtual devices.

For example, a ZEN71 in scene mode sends a seperate event message for upper and lower paddle. The NWT00Z has off and on. So an interface rule would take in a lower paddle event and set an old, unlinked, NWT00Z device entry to off.

Sound right?

Thanks again.

17

May not work as intended, you would have to change the drivers on the old devices over to the virtual switch driver. Otherwise its going to be trying to parse and send commands, may cause issues.

Also, I think the ZEN71 can be configured such that the on/off state will still be updated even though the load is shut off. I am the author of the "Advanced" drivers on this forum and also that Zooz links to in their docs.

So you could use the switch on/off instead of the button numbers for the basic on/off taps. Multi-taps would need the buttons.

image

18

Really leaning alot here, thank you.

Sounds like an existing device entry can be made virtual by changing its driver to a virtual driver. If I understand that correctly, even simpler.

Does changing the driver to its virtual counterpart take care of unlinking the dni from the radio database or should I do that first?

I used the paddle example for simplicity.

Since The NWT00Z is a dimmer (zwave transceiver without load control h/w) and the zen71 is a switch,

We plan to recreate dimmer and other functions with multi tap, hold, etc in scene mode. In testing, we also used the led to reflect the switch state by color since some loads are not visible from the switch location. With the NWT00Z the indicator turns off or on to indicate load state. Having the switch dissapear when it is on in a darkened room is sub optimal.

Thanks for the reference for use of the zooz driver!

Best,

Kent

19

No, you would have to edit the DNI and change the driver, does not matter what order.

20

Ok, this is a trial close out for the oop for the hub and zwave mesh to zwlr star migration.

For each migration and switch set change out.

  1. Unlink devices from radio database by editing each zwave device entry to change device network id (dni) to append _old.
  2. Make each old device virtual by editing its device entry to point to a virtual driver.
  3. Clear the zwave radio database by reinitializing the zwave radio in settings. This creates an empty zwave database and removes all legacy devices and ghosts.
  4. Cloud backup old hub.
  5. Take the old hub offline.
  6. Migrate cloud backup to new hub.
  7. Bench associate zwlr switches with new hub using smart start via the phone app.
  8. Physically replace old zwave switches by removing them and installing preconfigured zwlr switches from last step.
  9. Create rules to interface each new device with each old device -or- if compatible, swap each old device for each new device.
  10. Rename new hub to old hub name and assign new hub IP to old hub IP (for hub mesh).

If all this looks good we are done.

If any of you ever happen to be headed toward sw Montana (near where yellowstone is filmed) send me a message, I owe somebody at least a cup of coffee!

Thanks.

20221021_195037-picsay
20221021_195037-picsay1280×720 111 KB

1 Like