UZB/RaZberry Firmwares - Update

[kfxo]

I currently have Z-way (RaZberry) as a secondary controller as outlined above. I am looking to make Z-way my primary controller and ditch vera completely. As I understand it I have a few options.

1. Controller Shift from Vera. If I do this Z-way will not be node 1. How important is that? How can I tell if I have devices that can only report to node 1? The only one I have that I know about are Aeon MiniMotes.

2. Clone from vera using UZB as outlined in other posts. How would I then get it from the UZB to RaZberry? Just backup the UZB and then restore to RaZberry? Any disadvantages to this method? I am concerned that Vera may have not configured devices properly and to their full capabilities and this may carry over to Z-way.

3. Rebuild network by excluding and including all devices. I am heavily leaning towards this method, as there is something about starting fresh. However, I have 83 devices and this seems like it will be quite the undertaking. Anybody ever done this? Any best practices to completely rebuilding?

What method would you recommend? Are there other options?

[rafale77]

@kfxo said in Adding Z-way as secondary controller to vera zwave network:

I currently have Z-way (RaZberry) as a secondary controller as outlined above. I am looking to make Z-way my primary controller and ditch vera completely. As I understand it I have a few options.

1. Controller Shift from Vera. If I do this Z-way will not be node 1. How important is that? How can I tell if I have devices that can only report to node 1? The only one I have that I know about are Aeon MiniMotes.

Difficult question to answer. If you have z-way as secondary, first try to add your current z-way nodeID to everyone of them as lifeline. If you find devices which don't respond then, either they accept only one lifeline node association which will make it difficult for you to switch, or they don't accept any other node but node 1 as their lifeline. Only some of the fairly old devices (non zwave plus) appear to be that way but you may have problems in the future depending on what you will want to add.

2. Clone from vera using UZB as outlined in other posts. How would I then get it from the UZB to RaZberry? Just backup the UZB and then restore to RaZberry? Any disadvantages to this method? I am concerned that Vera may have not configured devices properly and to their full capabilities and this may carry over to Z-way.

This is exactly what @DesT has done. He took the uzb, put it in z-way. ran a backup, removed it, and restored that backup on the razberry. No clear disadvantage that I can see. I don't really know which one of the razberry or the uzb have the better antenna. The uzb has a tiny onboard coil while the razberry has a PCB antenna. You can (re)configure everything on z-way to your taste except for security command classes which require exclude/reinclude.

3. Rebuild network by excluding and including all devices. I am heavily leaning towards this method, as there is something about starting fresh. However, I have 83 devices and this seems like it will be quite the undertaking. Anybody ever done this? Any best practices to completely rebuilding?

It depends on the size of your network. For me it wasn't worth it as I have over 150 nodes. If you only have a dozen... maybe. No advantage with this method though unless you have a lot of S2 security devices which require to be re-included with S2 anyway.

What method would you recommend? Are there other options?

If your final setup is razberry based, I would recommend method 2. I don't recommend method 1 because you risk future problems even if it may be ok with your device set. Who knows what you will be including in the future? Why restrict options?
The vera has a very good hidden zwave nvme backup/restore program. It took me some trial and error to figure out how to use it but it works. Why not use that?

[kfxo]

Thanks. Looks like method 2 is the way to go. Now I need to get a uzb. Another question. When you have the networked cloned, can both z-way and vera control the network as if they are both primary controllers? Curious as this would allow updating automation without any downtime.

[rafale77]

Strangely you can!
But it will be chaos. The analogy would be... to have two twin brothers with the same name and you call their name and both respond at the same time... That's what happens when the devices respond to the controller.
Say a sensor trips. It sends the message to the controller. The first controller gets the message and says "roger" the second controller gets it too and wants to respond too... you get a very chatty network with lots of frame collisions... I tried it. It's fun for 2 minutes then it gets old really quick.

[kfxo]

Do you know if I will need a Z-Way license for UZB to accomplish cloning vera network, backing it up, and restoring on Razberry?

[rafale77]

The cloning from the vera for sure does not require a key. Saving that data on z-way is the only action which potentially would require a key and I honestly don’t know. Restoring the data to the razberry does not require a key either. Maybe @DesT can answer that?

[iblis]

@rafale77 said in Adding Z-way as secondary controller to vera zwave network:

That’s it... It will take a few seconds but and the vera will sluggishly luup reload and show a new controller device which will say that it needs to configure. Disable auto configuration for this device on the vera. Your z-way now should see all the devices on your network. You can even set SUC/SIS roles from it and do all kinds of things the vera cannot, or at least not easily.

I have a couple of suggestions when adding z-way as secondary controller. If you edit the file [z-way-server root]/config/Defaults.xml you can set some default options for z-way that's not available in the gui.

<TryToBecomeSIS>1</TryToBecomeSIS>

By default this option is set to 1 meaning z-way will always try to become SUC/SIS in a network. If that is not preferable (specifically if you are planing to exclude z-way from the network at a later state) you should set this option to 0.

<SecureInterviewAcceptedWithoutSchemeInherit>0</SecureInterviewAcceptedWithoutSchemeInherit>

This option is by default set to 0 to comply to the z-wave protocol guidelines, if set to 1 z-way will not fail secure interview as secondary/inclusion controller if Scheme Inherit is not received.

<WakeupInterval>3600</WakeupInterval

This option is by default set to 3600 seconds that means every time z-way is reconfiguring a node it will change the default wakeup time to 3600 seconds. If you don't want to alter your default/preferred wakeup settings on nodes you can set this option to 0.

<KeepMeInformedInsteadOfSIS>1</KeepMeInformedInsteadOfSIS>

If you prefer that the primary controller should keep getting wakeup notifications from nodes after z-way is included as secondary controller you should set this option to 0.

Examples of what I did: Look at routing, assign lifeline associations, survey and modify wakeup intervals. Check on device
command classes hidden on vera. Verify routing health.

One feature in the zway expert gui that is heavily used here for troubleshooting is the Timing Info page. There you can quickly spot which node is having latency issues and in need of some tender love.

Be careful with associations as by default z-way will want to add itself to the lifeline associations when you try to check them. I often had to delete z-way. There is a way to prevent that but requires editing some files and is probably not worth doing since you can just modify associations directly from z-way.

You can disable this feature by setting the following parameter to 0 in Defaults.xml

<Autoconfig>1</Autoconfig>

Since you're already exploring the Defaults.xml at this point it's a good idea to change the FragmentSize for firmware updates if your z-wave controller is gen5+.

<FragmentSize>32</FragmentSize>

The default option is set to 32 to be backward compatible with older gen3 controllers. You can safely set this option to 40 if your controller is UZB/gen5.

Just remember that your new customised Defaults.xml is NOT persistent during a software upgrade. So be sure to make a backup of the file outside the z-way-server root directory and copy it back after an upgrade.

[DesT]

@rafale77 said in Adding Z-way as secondary controller to vera zwave network:

The cloning from the vera for sure does not require a key. Saving that data on z-way is the only action which potentially would require a key and I honestly don’t know. Restoring the data to the razberry does not require a key either. Maybe @DesT can answer that?

What I did back in time, I clone my Vera network to a UZB stick like @rafale77 told me using Vera "restore" function.

Then, I put back my UZB in zway, wait a couple of minute to make sure I can see everything, then I backup the zwave network in Smarthome, to restore it on the RaZberry!

[kfxo]

@iblis said in Adding Z-way as secondary controller to vera zwave network:

<TryToBecomeSIS>1</TryToBecomeSIS>

By default this option is set to 1 meaning z-way will always try to become SUC/SIS in a network. If that is not preferable (specifically if you are planing to exclude z-way from the network at a later state) you should set this option to 0.

I have since added z-way as secondary and plan to exclude it before I clone the network. Since I did not do the above, is there anything I should look out for or that I can correct before I make the change?

[rafale77]

@DesT said in Adding Z-way as secondary controller to vera zwave network:

What I did back in time, I clone my Vera network to a UZB stick like @rafale77 told me using Vera "restore" function.

Then, I put back my UZB in zway, wait a couple of minute to make sure I can see everything, then I backup the zwave network in Smarthome, to restore it on the RaZberry!

I guess the question was wether you needed a a-way license key to do it....
@kfxo said in Adding Z-way as secondary controller to vera zwave network

I have since added z-way as secondary and plan to exclude it before I clone the network. Since I did not do the above, is there anything I should look out for or that I can correct before I make the change?

This should disable the automated behavior for the z-way to try to add itself to the devices lifeline association list.
So before you exclude the z-way, check all the devices associations and make sure the z-way controller node is removed. Funny I was just talking to the @therealdb about this.

Thanks for your insights @iblis and welcome!

[iblis]

@kfxo said in Adding Z-way as secondary controller to vera zwave network:

@iblis said in Adding Z-way as secondary controller to vera zwave network:

I have since added z-way as secondary and plan to exclude it before I clone the network. Since I did not do the above, is there anything I should look out for or that I can correct before I make the change?

Yes, there is a couple of things you should check to make the secondary controller exclusion less painless.

• Make sure Node1 is SUC/SIS, if not do the change and wait until every node in your network is updated with the new routes (manually wake up sleeping nodes if your in a hurry)
• Remove all secondary controller associations from nodes in the network before exclusion. This is not a problem if the primary controller also is running z-way-server since z-way automatically removes any association to a node that is no longer present in the network. This is one of the reasons Z-Way can be considered the Gold standard in Home Automation and unfortunately not many z-wave controllers on the marked today do this kind of maintenance by them self and what you end up with is more latency in your network due to nodes trying to communicate through association with hardware that is not present causing unnecessary traffic on your network (remember that according to z-wave protocol standards every node should try to communicate up to 4 times without getting a proper response before moving on to the next route).
• On your battery devices make sure the primary controller is set as the controller receiving wakeup notifications. If you did not make the <KeepMeInformedInsteadOfSIS> option change above before including z-way as secondary controller z-way will automatically set itself up as the receiving end after finish the first interview with your battery nodes.

[DesT]

@kfxo said in Adding Z-way as secondary controller to vera zwave network:

Do you know if I will need a Z-Way license for UZB to accomplish cloning vera network, backing it up, and restoring on Razberry?

As far as I remember, the license is "included" in the UZB... but I can search in my old invoice with them if you need a real confirmation!

[rafale77]

@DesT typically if it is included, you would have to manually type it into z-way. "Included" normally means it is on a piece of paper. If you don't remember doing that and you didn't buy it used then I think you did not need the license.

[kfxo]

@rafale77 @iblis @DesT I appreciate all the input. I have successfully removed all association to the secondary controller (z-way) and also set all battery devices back to vera (node 1) for receiving wakeup notifications. I believe that Node1 is SUC/SIS but I just want to make sure. Vera's settings show "Node 1 Suc 1" and "Role: Suc SIS: YES PRI: YES". Z-way setting show "SUC/SIS in network: 1 (SIS)". Does that look correct? I think I am ready to exclude z-way as secondary controller to prepare for cloning.

[rafale77]

Yes looks good! You can now exclude z-way and do the cloning.

[therealdb]

I can confirm ZWay is cool. I did a couple of maintenance actions on my devices and I can't think about all the time I lost trying to do the same thing with Vera. I'm still using it as a secondary, because I need to plan a smooth transition (Alexa, Nest, and many other things to figure it out), but I'm glad I got mine for only 9 EUR, license included

[iRobot]

@therealdb That's an amazing price!
Bought my UZB1 including license for 80 EUR just a couple of weeks ago.

[rafale77]

@therealdb

When you will move it to a primary, you may well see yet another benefit:
Extended battery life of all your battery operated devices...
On the vera, disabling polling and nightly heal helped with the battery life of the FLiRS.
Disabling nnu helped dramatically with the battery life of the non FLiRS battery operated devices.
But the vera continues to do wakeup polling which is something I requested to remove as it is useful for only some very rare specific devices and of course I was ignored for almost a year now.
Z-way doesn’t do any of this craziness and it is very noticeable that all my locks and sensor battery lives have noticeably extended. I use NiMH rechargeable batteries everywhere I can and have recharged batteries only once in 9 weeks with z-way while I used to have to recharge a few sets a week before 7.30 and then about once every week or two after 7.30 and disabling all the vera bloatware they let us. I have 72 battery operated devices and FLiRS...
So much time and money saved from not having to go swap and recharge batteries...

This helped with the WAF... @CatmanV2

[therealdb]

I remember your battle to disable and I'm glad something was introduced.
I have no FLiRS devices, only less than 10 battery operated one. I hate batteries and I tried to avoid them as much I could. it's just a couple of door/window sensors and two motion sensors where it was impossible (or I missed) to plan a wired one.

[rafale77]

I wish I was that lucky! I practically have no choice for these devices ranging from security door and motion sensors, to locks, HVAC vents etc... Thus the move to rechargeable batteries except for the doorlocks which are high drain and take lithium.