Adding Z-way as secondary controller to vera zwave network
-
-
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. -
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. -
Sorry @therealdb, I haven't seen that you specifically said thát...?
-
Only for non-configuration parameter... Things like wakeup intervals, configuration parameters etc... the vera will not know unless you make the vera poll them and the vera does not make it easy to just do a poll of parameter since mostly the "set parameters" command is implemented as part of its configuration process.
Status (variables) which update regularly to their lifeline controllers will get updated on the vera if vera is in the lifeline association. -
Sorry @therealdb, I haven't seen that you specifically said thát...?
@sender
I have auto configure to off and while I wait the summer for more time and promote my zway to primary, I'm using it as secondary to configure devices. I can fiddle with parameters and prevent reboots.So, as rafale said, it's OK for configuration parameters, not for wakeup and such.