Second Z-wave netwerk or slave controler

[Edwin1972]

I have a VeraPlus and would like to purchase a second z-wave controler. Is it possible to build a second z-wave network next to an existing z-wave network? Slowly I want to move devices form Vera to the new z-wave network. Is it more advisable to install the second z-wave controller as a slave controler?

[akbooer]

I run multiple Zwave networks (up to four of them, in fact) without any problem.

You definitely don't want a slave controller as that will become part of the original network. Integration between them can be done at a higher level (using openLuup, for example.)

Bear in mind that Zwave is a mesh network topology, which benefits from a fairly dense set of nodes. By having two separate networks, they won't share the same mesh, but they do all live in the same RF bandwidth. I've never found this to be an issue.

[Edwin1972]

Thanks for quick response! I think I wil also run a multiple zwave netwerk for testing devices.

[parkerc]

@akbooer said in Second Z-wave netwerk or slave controler:

Integration between them can be done at a higher level

Hi @akbooer

What are the options, and what are the pros/cons of each ?

I’ve personally just used the http request option..

[rafale77]

As I posted elsewhere, my analysis using a zwave zniffer shows that:

1. You can run multiple zwave networks but it is not recommended because zwave functions only on 2 or 3 channels depending on your region and each zwave controller makes use of all of them. This means, 2 zwave controllers/network devices will interfere with one another causing latencies as they will therefore have to retry when the RF messages are come scrambled.
2. The vera chattier than any other controller due to its insane and broken self management scheme so larger networks, your chances of running into problems will be even more amplified.

On openLuup you really can go either way. A second zwave network really makes sense only if it is not located in such a way that two networks would interfere with one another. If your network is relatively small (less than ~30 devices) it probably doesn't matter which way you go but anything larger than that, I would recommend the secondary controller option which eventually can open the option to just transfer the primary role to the secondary controller without having to exclude/include any devices. That's how I along with @DesT and others for example did it. I have over 150 nodes and really didn't want to exclude/include the entire network.

[Edwin1972]

@rafale77, Thank you for your response. I have read your blog on GitHub (https://github.com/rafale77/Z-Way/blob/master/README.md) with full interest. Thank you for the time you put into it. I have taken the following steps:

• Buy a Pi 4
• Install OpenLuup / Reactor on Pi4
• Install VeraBridge plugin for OpenLuup
• Migrate all my reactor sensors from Vera to OpenLuup
• Delete al scenes and Plug Ins on Vera
• Use OpenLuup to make new reactors

Now I have come to the point of purchasing a UZB1 stick. I want to use it with the help of home assistant or domoticz.

My vera has a problem. Everything works perfectly, but when I log in via home.getvera sometimes I see the following message on different devices:
• Please wait! Polling node
• SUCCESS! Successfully polled node
• Can't Detect Device
• Error: node is not configured

I had contact Vera support about the problem. I must reset my Vera completely and build from scratch again!

I don't want to include this problem in my new zwave installation. That is why I want to start building from scratch with UZB1 stick. I have about 40 devices. It's a lot of work, but I hope to build a stable system. That's the reason I want to build a new zwave network.

Sorry for the poor English but I am using google translate.

[rafale77]

Hi Edwin,

I am not a native english speaker myself and your post was very clear.
The vera errors are mostly caused by the vera "maintenance" features.
It's important to understand that there are two layers of configurations which the vera mixes in their management system. One is the software level which is done by the luup engine or in more generic terms the host controller software, and another layer which is the zwave chip level. They each store different device data and the vera reads the data both from the zwave chip non volatile memory and the user configuration file (user_data.json). Your issues could be caused by either one of the configuration but.... When you transfer your network to another controller, other controllers, unlike the vera, can very easily get the device reconfigured without excluding and restarting the whole process. The vera support advice is what I call "shotgunning" at the problem without trying to understand what is wrong which is completely unacceptable to me. They are just hoping that starting from scratch will fix the problem. Kind of like the vera restarts and reloads. It is a recommendation out of ignorance and despair. I would completely ignore their advices. They are inaccurate and not a scalable solution.

The only case of real required exclusion/reinclusion for z-wave is the security key exchange which is allowed by the devices only during the inclusion process. The rest is all data corruption which can easily be recovered through a reconfiguration either with a NIF/Discovery call at the zwave level or a reconfiguration of the host controller data. The root cause for most of these data corruption is rarely at the zwave level (It can only happen if there are some corrupted data coming from the zwave RF which usually are caused by data collision from overly chatty networks), it is often due to the host controller software. The vera is very prone to both these problems because of its "maintenance" design which is not scalable beyond a handful of devices.

[Edwin1972]

@rafale77, Thank you for your comment and sharing your knowledge
Do you have a suggestion to solve the problem with my VeraPlus?

If I understand correctly, I can set my UZB dongle as slave of VeraPlus and later on I can move the VeraPlus devices without moving the problem to the UZB dongle.

I'm still not sure if I need to set up a separate Pi4 for use UZB dongle with home assists or Can I connect the UZB dongle to my existing Pi4 running OpenLuup, Node-Red and Grafana and install Home assistant.

[sender]

@Edwin1972 I would go the route to install openzwave (QT), natively in home assistant with a UZB or other zwave dongle (I have aeotec gen5). Then integrate vera in homeassistant and that way you will have "2" zwave networks. Any device failing in Vera include in openzwave and any new devices also. Logic can be done in homeassistant natively or node red (what I use). Rocksolid, superflexible and bringing back fun in home automation.
I only have to worry about "other stuff" not working (automations, wifi, etc.) and not about a vera, openluup, zway, etc... .

The community.home-assistant.io forum is "alive"! For me it feels like the early Vera forum days, before I was banned for 1000 years there. I never looked back!

[rafale77]

@Edwin1972

I don't share @sender's level of enthusiasm for home-assistant/openzwave and it's good to have a diversity of inputs.
Home-assistant is becoming a bit of a mess and becoming more and more difficult to manage with all the container/supervisor structure. openzwave is also work in progress and is still very far from the stability and control you get from z-way.
I run home assistant but started my own fork because it has areas of inefficiencies and gaps in functionality while providing an outstanding integration base.

You understood correctly, you can add the uzb dongle as a secondary controller to your vera network if you so desire to see how it works out for you and when you decide to migrate, you can just exclude it and do what I did as I described on my github page and on my blog page. Basically have the vera replace its internal zwave chip with the uzb and then take the uzb to whichever controller you want be it z-way or openzwave.

As sender said, you can use practically any other usb zwave stick, the aeotec would be the only ones I would not recommend because of its proprietary non upgradable firmware. The gen5 is stuck on a very old SDK which won't support any of the zwave+ new features and Aeotec just released a gen5+ with still an older SDK than what the uzb currently has.
The uzb presents the advantage to work on both z-way and openzwave amongst many other platform and being very up to date in terms of firmware.

[akbooer]

@rafale77 said in Second Z-wave netwerk or slave controler:

The uzb presents the advantage to work on both z-way and openzwave

...did you mean "openLuup"?

[rafale77]

No, I did mean z-way and openzwave as the zwave host controller.
openzwave would then be bridged into home assistant and z-way into openluup. These are two possible approaches...
Obviously if one has largely invested into the vera in terms of automation (scenes) openluup-z-way is the much simpler/easiest approach but if someone wants to start from scratch like @sender did... well I would still pick the same approach but some people may prefer going to the more integrated but less complete in z-way term home-assistant approach.

There is something to the complexity of managing linux dependencies which has lead to the whole container approach. Some people really prefer this immediate ease of implementation. I really don't as I think in the long run, it is replacing an immediate inconvenience with another higher level of inefficiency and complexity which eventually will be even more complex and tedious to run. It is where home assistant is at today and why I forked my own version and won't run it "supervised" nor will install any containerized integration on it.
It is philosophically not so different from the downspin of the vera trying to do unnecessary maintenances thinking it would improve customer convenience without thinking about the scalability and the opportunity cost of the approach.

[Edwin1972]

@rafale77. Thanks again for your information. If I understand correctly, I am on the right track with UZB-stick only you advisor to purchase the z-way software. I think this can be done by purchasing a UZB stick, including license. I think there is also a bridge between Z-way and openluup and I can use openluup as logic (reactor from Rigpapa) for my automation.

The question remains whether I can run openluup, node-red, grafana and also Z-way with UZB on my RP4 or is it better to run a new Pi4 with UZB-stick and z-way next to the existing Pi4?

[rafale77]

I think you can run all of them on a single rPi4. They are not resource intensive at all. The only thing I would caution with the rPi is the sd-card which is notoriously unreliable. I would try to run everything from a larger SATA SSD. There are many tutorial showing how to do this online. You could also even run all this on a rPi3B which has less of a overheating problem.

If you don't already have one purchased, I would recommend to buy something like this:

US $122.5 34% OFF|Quad Core Mini Pc for Gemini Lake N4100 4Gb 64Gb Support M.2 HD MI/VGA Dual Display 1000M for Computer, EU Plug|Computer Cases & Towers| - AliExpress

Smarter Shopping, Better Living! Aliexpress.com

Which would give you a lot more configurability, ease of installation, reliability, lower power consumption, lower heat, more processing headroom and will come out to be cheaper than the rPi4 at the end after you take the power supply, the storage and the case under consideration.