Vera PushOver notification with image

[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:

https://www.aliexpress.com/item/1005001319215760.html?spm=a2g0o.cart.0.0.237f3c00wfq7Rj&mp=1

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.

[LibraSun]

Is there any way I could leverage an unused ezlo Atom (v2) to act as a repeater in my Vera Plus setup?

I do not foresee using the Atom in any other way, and since it's a plug-in, it could be handy (I think!) for extending the range of my Z-Wave network a bit.

Something tells me this -- asking a controller to act as a device -- is not even possible. But still had to ask!

[rafale77]

It would have to have a firmware to do that so as to act as a routing node. Given the nature of the device... not sure if it is possible. You already know what I did with mine...