Z-Wave do's and don'ts

There have been many discussions about Z-Wave do's and don'ts, in this community lately, so I thought it would be a good time to share one of my favorite blogs written in 2017 by a Silicon Labs engineer.

In his blog "Seven Habits of Highly Effective Z-Wave Networks for Consumers" Eric said this:

"One of the big problems in Z-Wave network maintenance is eliminating “dead” nodes. When a device fails or for whatever reason is no longer in use, then it needs to be removed from the controller. If it remains in the controller then the controller will try to route thru this dead node on occasion resulting in delays in delivering messages. Eventually the self-healing aspects of Z-Wave will make this less likely but various devices will on occasion attempt to route thru it.

Since the node is dead, that wastes valuable Z-Wave bandwidth and potentially battery power of sleeping devices.

Occasionally running a Heal on the network will remove the node from the routing tables but it will remain in the controllers routing tables. It is best to completely remove this dead node."

5 Likes

It would be a great help if the feature of Z-Wave dead node removal could be added to the platform, not merely the current, rarely working, “Remove” button for a failed device, but a button that would do the “ghost node” removal that, at present, requires firing up a Z-Wave USB stick with SiLabs PC Controller.

6 Likes

What utilities does HE provide to do this?

The "Remove" button on the Z-Wave Details page.

https://docs.hubitat.com/index.php?title=Z-Wave_Manual#Remove_a_failed_Z-Wave_node

I have been thinking something along these lines in my layman head. I get the hubitat wants to remain compliant with zwave certification.

Would it be possible to build an alternate stack that works more like pc controller software with the choice to choose between them? If not possible on the c7 could such a feature be made to work on a second c5 hub?

I honestly do not understand everything involved, but thought it would be nice to use a second available hub for this stuff, rather than purchasing another product.

1 Like

What about non C7 customers?

I honestly believe a lot (but not all) of the issues users have with zwave, have to do with zwave devices that report: temperature, humidity, power usage, and to a lesser extent motion. The manner in which these items are reported are fundamentally different than how you report on/off, dim.

When a switch turns on/off or dims to a certain level, it is one event that takes place at a certain time. The switch receives the command, does what it is suppose to do, and reports back. Many of the switches in my house might do this 1-3 times a day, some might do it upwards of 10-15x times a day. All in all not much traffic for the zwave network. (as an aside this is the same for Lutron, there is simply never all that much traffic over the Clear Connect network and as a result it is very reliable).

Now throw into the mix zwave devices that report: temperature, humidity, power reporting, and to a lesser extent motion. These are things that are constantly changing (the temperature in the room I am in is currently 22.032568 degrees Celsius, the temperature one second later was 22.032579 degrees Celsius). So for these devices you need to decide how often they should report these parameters. I believe many users have these parameters being reported WAY to often. From the article above it states this: "Remember that if you have 60 Z-Wave devices and you poll each one once/min then you are polling once/second and the network is hammered!"

So from the above article once a second reporting "hammers the network". I have seen users post logs to this forum where one device was reporting its power usage every 1-3 seconds, this is to say nothing of the other devices. I actually think this is Silabs and the manufacturers fault. A zwave device should not be able to send info like this, in time frames of under one-minute and even one-minute is probably too short.

I have always had a zwave network that has worked 100%, no problems at all. This weekend I am going to see if I can get my 4 inovelli switches to report power usage to the hub every second and see what happens to my zwave network. I will report back my findings.

I don't think that's the primary reason it's reliable. Lutron devices are all made by Lutron, and no doubt extensively tested with each other in all sorts of combinations. I worked for almost 6 years with the person who is now Director of RF engineering for Lutron, and I can tell you that he is extremely knowledgeable and very thorough.

In contrast, z-wave devices are made by numerous companies, and z-wave certification is (in my opinion) a joke. If z-wave devices were rigorously tested to be in compliance with the specs, then it only stands to reason that there would be few to no z-wave interoperability issues. But that's not reality.

I have a hard time believing that small packets of information sent by a device once a minute could bring down a network. But if that's truly the case then why would such a device be "certified", at least with defaults that are not practical? You would expect that SiLabs has enough data to know what an average network looks like, and creates certification tests accordingly.

I hear you, and I also use a Lutron Pro Bridge in my system (just got it, and using it for Pico implementation), but this currently active thread and several older threads speak to the delays that happen when Clear Connect is asked to deal with a lot of traffic:

Maybe as someone who knows the director of engineering for Lutron you can help with the delays that are described in the above thread and other threads on the same issue.

I am serious about doing the above test, my zwave network has always worked 100% (not 99%), all my devices are zwave plus and all but 2 are mains powered repeaters. None are joined with any type of security. I will see if the driver in my inovelli switches allow for reporting of power usage every one second, if so I will implement it and see what it does to my zwave mesh.

If I am allowed to set the frequency of reporting to this level and it gives my mesh problems, it speaks more to the zwave certification standards and the manufacturers' firmware implementation than anything else. But we will see.

Unfortunately, I don't have any contact with him anymore. When the company we worked for (in Florida) was starting to shut down, he got the position with Lutron which is in Pennsylvania. That was 7 or 8 years ago now. If I was still in contact, I'd ask if he could get me some stuff to play around with :yum:

Given some of the horror stories I've seen, I guess I'm also fortunate that my z-wave network has given me virtually no problems either, with several different controllers and a variety of devices over the past 10 years or so.

Now that I think of it, I have a few switches in my rental house that report power usage. Enerwave ZW500DM's. No idea how often they report, but they've had no noticeable effect on the stability of the zwave network.