Why is Z-wave such a hassle?

Community Playground General Discussions
#1

I’ve only had a Vera Plus for a short time, but my observations are that Z-wave, when it works, it works, but inclusion for me (at least) seems to be a knock-down, drag-out, battle every time.

I am careful to pair them, literally, 3 feet from my Vera.

I have yet to have one Z-wave device pair “out of the box” smoothly. It is typically some combination of:

Device being added, but missing features, even if I let it sit. eg. battery powered sensors missing a battery percent indicator.

Having to go though an unpairing process to reset the device after the out-of-the-box attempt, that in it of itself offers little feedback, and if/when it “works” the device isn’t removed from the interface until I Delete it, even though the instructions say it will be removed in a few minutes.

“Failed at: Setting user configuration…” or other annoying messages in Red shortly after for no apparent reason, but never happen again after a 2nd (or 3rd, or 4th) attempt at pairing.

Is this just how it is or did I make a mistake choosing a Vera?

Once I get them paired, they work. But, man, I’m tired of taking 30-60 minutes fighting with a new device when it seems it should just work - because isn’t that the point of Z-wave? I see why people here are so sensitive when a firmware update alters their device and they have to re-pair it!

3 Likes
#2

You are not alone. Rather than the exception, it’s been the rule for me that whenever I try to Pair a new device, my Vera does see it. So I Unpair. Or Delete. And re-Pair, which seems not to work, but then all of a sudden the device pops into existence during the final Unpair.

Does not inspire confidence, does it? I honestly don’t know how non-enthusiasts put up with it. At least back in the days of (comparatively basic) X10 devices, you literally plugged and played. And users contented themselves just turning stuff ON and OFF, without caring how many watts their dishwasher might be using 1000 miles away. :smiley:

Maybe the realm of Home Automation, despite its recent growth and innovation, will always have a tinge of “voodoo magic” associated with it. Unquestionably, Z-Wave carries that reputation far more than other protocols, which is ironic, considering the extra price we all pay for the “strict standards and interoperability guaranteed” by the licensing company behind it.

#3

I am going to try to answer this as briefly as possible…

It’s not a zwave problem… for the most part. What you are observing is actually the fruit of vera’s implementation of zwave.

I have run a multitude of zwave controllers and can tell you that, though zwave has it’s quirks, the vera’s implementation has made it significantly worse. The vera probably has the best UI of them. Also one of the best community and plugin architecture (not perfect but one of the better ones). It is however sitting on an abysmal zwave implementation for stability and very lacking zigbee stack implementation.

There are a number of reasons why inclusions fail.

This is a PM in which I replied to this question another member asked me: Sorry I am getting lazy and don’t want to retype what I have already shared.

There aren’t too many things which can go wrong.
The vera mixes two levels or two steps of the device pairing into 1.

  1. The zwave chip level data exchange. This is controlled by the zwave radio chip. It assigns the node id and the home id. It assigns security protocols. Generally if your vera shows the device on the UI and the device itself is not behaving as if it in factory settings (it is already assigned a network) this step is complete.
  2. The controller level configuration. This is when the vera firmware comes into play (besides providing the security key for which it intervenes in step 1). This is where the device responds to a NIF (node information frame) from the vera and responds with all the available command classes and then the vera frivolously sends its weird default settings. It is when the mesh information is supposed to be established as well as the wakeup (device parameter), polling (vera parameter), Association (lifeline and others if needed all device parameter), special settings (device parameter). Device parameters are stored in the device’s zwave chip’s NVM. Vera parameters are stored in the vera’s user-data. And then the vera either uses a configuration it knows by recognizing the device or blurbs a default device on the UI when it doesn’t know what kind of device it is from the command classes it got.

Generally the part which fails is step 2. It is a part which is fully recoverable through vera device configuration. When you exclude the device, you go back to step one which… really rarely is the problem. You may need to either improve your mesh by doing a couple of heals or target the specific device to have it do a nnu (neighbor nodes updates).

Another long thread on the zwave network is here Zwave Network On Vera Explained

Added to this is the observation that vera is having some regression in their inclusion process with some devices no longer able to get included.

2 Likes
#4

I don’t mind the copy/paste, thanks for the replies!

You may need to either improve your mesh by doing a couple of heals or target the specific device to have it do a nnu (neighbor nodes updates).

I’m not sure what that means. I don’t have any other wired devices that would act as a mesh, just the vera and a handful of battery devices (no repeaters). I try to pair close to the Vera, like I said. So, I’m not sure how to “fix” a device that fails to get device info exchanged properly in part 2.

I appreciate the detail on how it works! My Vera is just a Zigbee/Z-Ware gateway to my Home Assistant install. Since I run HA on a NAS in Docker, I didn’t want to mess with Z-wave USB sticks and wanted a device easy to integrate with HA (Vera is simple for that!)

My switches, plugs, and smart power strips are all Tasmota/MQTT based so I got a little spoiled with the easy of those, I guess.

I will probably have to had a Z-Wave plug or extender or two for some areas, I admit.

1 Like
#5

Huh sorry, forget this recommendation. It was aimed at a specific problem this member was having… unrelated to your discussion on device inclusions.

If you want to play with this, knowing that you are already using Home Assistant as your main controller, you might want to consider bypassing the vera layer altogether.

I played with this and replaced the vera zwave control with the zwave2mqtt component.
I also used this to move the vera’s zigbee serial signal and used home assistant’s zha component which is widely superior to vera’s zigbee implementation. You won’t have inclusion issues anymore…

2 Likes
#6

woah… that’s pretty sweet. I don’t have time for that right now, but next time I take a few extra days off…

#7

Download a free copy of Homeseer and discover first hand how fast Inclusion is.
As rafale notes it’s a product of Vera and it’s implementation, pairing etc of Z-Wave that is the problem.

#8

Anyone with an Atom Here? How is The zwave stark there?

#9

I have an Atom, It is impossible to know because it has no API or even a GUI to interact with. Impossible to include in an established network. Impossible to configure devices manually with so practically useless. It makes for a nice usb led light.

#10

@Domoworking Ezlo products (including Atom) has a brand new Zwave Stack written with stability and efficiency in mind. I use them at home personally and happy with the Zwave stack performance.

@rafale77 Pre-ALPHA Ezlo LUA API Documentation
API documentation - Pre-Alpha - For Ezlo controllers
Happy to receive your further feedback so that you have all the access you need.

#11

7 posts were merged into an existing topic: MIOS Acquisition

#16

Are there any performance specifications published to compare the performance of one against the other with the same devices and quantity? It would be interesting to see the comparison.

1 Like
#18

If Atom had EU frequencies support and integration with Home Assistant, I would be please to test the zwave stack

#19

not sure if there is an independent organization that does that. Of course we have our internal ones.

#22

Full LUA running in that “Cheap Hardware” that does not have enough power :wink:

Happy to have proper technical conversations and performance discussions about how well LUA is executing within Ezlo Atom.

1 Like
#23

I also had much frustration with ZWave, using an Edge, and also after “upgrading” to a Plus. Tried for a few years to get it all working. Now I have HA (Home Assistant) running on a Raspberry Pi, using an Aeotec Z-Stick as the ZWave interface. I find this works extremely well, especially after discovering and adding the NodeRed plug-in for an easy way to program triggers, timed events, etc. The built-in HA “Lovelace” GUI is pretty nice too, and highly tailorable. I have 100+ devices on the system now.

Things I learned along the way, perhaps they’ll help someone:

  • there has been occasional discussion of “polling” in the Vera world, but I have learned that it is much more important than I thought. Polling can easily saturate the ZWave network, which leads to all sorts of problems. With HA, I found that it is much easier to see what is happening, and to configure the polling so that it does what you need without causing problems. In my HA setup, such problems typically appear as sluggishness in response, e.g., lights that take several seconds to turn on after a sensor triggers, which is an indicator that the network is saturated.

  • All my lights and switches are fine now, and even the Sonos audio, but not everything works yet in HA. E.G., my Scene Controllers are not yet supported, so they’re non-functional. However, that functionality is controlled by the separately developed “Open ZWave” (OZW) library that HA uses. OZW has a large and active user/developer community (as does HA and NodeRed). The latest version of OZW has added support for Scene Controllers - which means it will likely appear in the next release of HA as the newest OZW is integrated (perhaps Vera should consider using OZW??..)

  • I had several ZWave wall switches that would no longer work remotely despite many attempts at resetting, excluding, including, etc. I concluded that the radio part of the wall switches had failed and was going to get around to replacing them (not easy). I was wrong. When I tried to include them into my HA network, they all just worked again. This was possibly associated with the polling issue in my Edge/Plus setup. Don’t know, but they work fine again now.

  • Including and excluding is especially easy if you use an Aeotec Mini-mote to do the exclusions. The Mini-mote has the ability to do some kind of all-encompassing exclusion (I forget what ZWave’s terminology is) when the Mini-mote itself is not included in any ZWave network. To remove a device from a network, you’re supposed to use that network’s controller to exclude it, but that’s pretty difficult when the old controller won’t work any more. So to move a device from the old ZWave controller to the HA/Zstick setup I would simply first use the Minimote to exclude the device from any old network it might have been added to, and then use the regular “Add Node” function in HA to add it to the new network. Worked very fast and reliably.

  • I still have my Edge and Plus, and may try to use them to get the scene controllers back online. It is possible to integrate HA and the Edge/Plus worlds, but I haven’t gone down that path yet.

  • the user-interface and programmability capabilities, especially with the NodeRed module added, and other pieces such as MQTT, are impressive. Very active user and developer communities too. I’ve barely scratched the surface, lots to learn.

Good luck,
/Jack

#24

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.

Best Home Automation shopping experience. Shop at getvera!

© 2021 Ezlo Innovation, All Rights Reserved. Terms of Use | Privacy Policy | Forum Rules