@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.

Video over wifi is ok IF the bandwidth is efficient. Usually that is not the case when you start adding multiple wifi cameras to your network and you quickly understand how unreliable a wifi connection can be.

My suggestions here is always:

• Keep wifi cameras on a dedicated WLAN network.
• Calculate your bandwidth and never go more than 80% of recommended throughput depending on your wifi specs.
• If you are distributing the camera feed to multiple clients ALWAYS configure your camera/dvr/clients to use multicast.

When it comes to the topic at hand and just for informational purposes my doorbell is from DoorBird and is connected through POE and so far it's been the most reliable/flexible solution I've tried yet.

@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.

27.04.2020 v3.0.6

Fixed problem with upgrade removing Z-Way important files.

== Home Automation ==

New features:

• EasyScripting module released

== Smart Home UI ==

New developer features:

• Code highlight can now be used in apps descirption.
• Menus can now be used in apps.

== Z-Way ==
Fixes:

• Fixed interview failure of Basic inside channels

Link: https://storage.z-wave.me/z-way-server/ChangeLog