Adding Z-way as secondary controller to vera zwave network
-
@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!
@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 networkI 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 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?
@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.
-
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?
@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 @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.
-
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
-
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
@therealdb That's an amazing price!
Bought my UZB1 including license for 80 EUR just a couple of weeks ago. -
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
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
-
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. -
-
Took the bit and bought it...
Stick plus license... will be here lots of time next week :-)...
-
@DesT libcrypto for that ssl error? I managed to revert to ubunto 18 and have z-way running. Or was your answer to my question on how to auto start z-way? I think not?
It looks like you are going through the “learning” on linux and you are doing it pretty fast. The libcrypto was for the error you were showing on the screenshot. Not a response to your last post.
I am running this on ubuntu as well along with openLuup.
The issue with z-way-server is that it was set to be installed on a rPi first and therefor assumed the preinstallation of a number of dependencies like libcrypto there are others and we have to install them one by one, looking at the error thrown at us when attempting to start the z-way-server. Different linux distros and versions have different packages pre-installed but they generally have access to mostly the same packages.
I autostart my z-way-server with systemd. I will post how to do it here a bit later. -
Ok ,on-topic again. If z-way is secondary controller with
<TryToBecomeSIS>0</TryToBecomeSIS>
<Autoconfig>0</Autoconfig>Can I use z-way to do device config there? And will Vera also "see" the values then?
So I can use z-way to get rid of the horribe "waiting for wakeup to configure device messages? (hope z-way will do fine however :-)) -
You can configure the device a lot more clearly and in more details on z-way than on the vera for sure.
The "waiting for wakeup" thing for the vera is internal to the vera and has little to do with the actual configuration of the device.
The vera wants to push its auto-preset device configs to the device or it is just a flag mistakenly tagged to that device requiring to wakeup for it to reconfigure the device when it was the vera's own data which was messed up. Really a nice piece of garbage if you ask me. But no it won't remove these tags because the vera won't know that another controller already did the job. To eliminate that from the vera you need to remove the auto configuration.