I have 6 of the new Inovelli LZW-42 Z-wave bulbs. I paired all of them and updated the firmware. I am only putting one in service at the moment, the others will be in the box for a while. It seems like my hub significantly slowed down after I added these. Is it my imagination or is there an issue with paired but unavailable devices?
Depending on the details, yes it’s possible. If you don’t need them at all for a while, consider excluding them and then re-including them when needed.
5 Likes
Zombie devices can slow the hub down as it will try to connect to them since they are on the devices list. If you don't plan on using them or if they will be down, just remove them and add them when ready to put into service
1 Like
Yes they will. Plug them back in and exclude them. Do NOT force remove them, or you'll create a new set of problems.
1 Like
What happens if I simply "disable" them?
I am very convinced that such "phantom" devices adversely affect the performance of your zwave mesh.
Unfortunately, the only way that I know of to remove such deices (at the present time, in HE) is to use the PC Controller program, along with a secondary zwave controller, as described in this discussion:
How to get rid of Phantom (Ghost, Non Operating) Zwave Nodes
I'm not sure "disabling" in the HE sense will stop the devices from interfering with the z-wave mesh itself only HE rules processing etc. I could be wrong though..
I bought some of those bulbs as well and the jury is still out.. the updated firmware is much better so if anyone has these bulbs definitely update. Installed one for my uncle in a table lamp and it stopped responding all of a sudden after working properly for a few weeks. Unfortunately was not around to troubleshoot so it could be something he did.
Also as others have mentioned never power down the bulbs - use the smarts to turn on / off. Consider affixing a blocker to the switches to prevent inadvertent switch offs.
Simply remove them. Anything non-communicating or unplugged should be removed. It's just a good practice to be in. Adverse affects will not burden your network.
1 Like
Thanks for the feedback. I excluded the the five unused LZW42 bulbs and did a z-wave repair. That went far quicker than when I did it with the bulbs disconnected but still listed as devices. I be curious to see how the hub behaves over the next several days.
Makes sense, I believe the hub tries a few times to reach each device during the repair and waits for a response before moving on.
Let us know if you notice other improvements after excluding the unused devices.
I have had a device disabled on the devices page for almost three months. The device is not queried during a repair and nothing has ever shown in the logs. I just re-enabled the device and it came back online. I did hit the configure button to make sure the device responded and it did immediately. I then ran a repair and the device was now included in the repair process.
That device would have been sending out Zwave traffic so it did have some effect on my network even though it was disabled. The traffic would have been ignored. Personally, I think just disabling something that can be physically removed as in the bulbs would be just fine, especially if they will be put into service in a short time.
1 Like
Is that a function of the Z-Wave spec or HE? Because if it's Z-Wave then that's really good to know. If it only prevents HE from doing things with it but it remains functional to the actual mesh (like for repeating) then maybe not so good especially with a problematic device.. but you also mentioned it did not show up in repair.. so maybe all good??
I wonder if you disable a device and then do some zniffing to see if that device still still responds outside the hub environment.... mmmmm...
Disabling only stops the Hubitat driver code from executing. The original intent of this feature was to troubleshoot problematic user driver code: rather than removing all such devices or changing all devices using a specific driver, you could just disable devices that run it. If you have Z-Wave association, a secondary controller, or any other method to control the device, those should still work. I haven't tested this, but apparently disabling also sufficient to stop it from participating in a Z-Wave repair (or at least to stop anything from this device about appearing in the logs).
If the device is a repeater, it should continue to function as such; that is handled at the device/firmware level and is not something Hubitat can directly control. Personally, if I were not using a Z-Wave device for an extended period of time, I'd un-pair (exclude) it from my network and add it back when I planned to use it. That being said, Z-Wave Plus has decent "self healing," so if it sees a repeater isn't online for a while, devices should eventually realize that and stop using it. I've seen reports of people not removing devices like this and not noticing any problems. "Classic" Z-Wave devices may need a repair since they are not as capable on their own in this regard.
If anyone knows anything about Hubitat's Z-Wave implementation specifically (or what the spec might say, not that it necessarily matters since the C-5 isn't certified), I haven't seen that spelled out by staff or knowledgeable community members anywhere. My guess is that nodes that fail to respond after "a while" will get put on a "failed nodes" list until the hub/controller hears from them again. While on that list, it's possible the hub won't even try to send messages to that device (this part I am not sure of, but presumably it might try to limit things it know won't work to keep the network happy, like it appears OpenZWave does, the only implementation whose behavior I'm really aware of). Again, this is just a guess on my part--I'd love to hear what anyone might know.
Also, it seems there are two issues being conflated above: "ghost nodes" (nodes that are on the controller but don't have an associated device in Hubitat) and ... whatever we want to call nodes that do exist in both places but are out-of-service as far as the real-world is concerned. I've seen a few users, including some above, report that the former has caused problems for them, possibly hub problems (slowdowns? not sure). While the latter may definitely cause network problems (e.g., a device trying to route through a repeater that no longer really exists but everything else still thinks is there), I'm not sure if I've seen anyone mention hub problems in that regard. For that matter, I'm not really sure that the former are hub problems, as network problems might have overlapping symptoms (slowness) if all your devices are Z-Wave.
Hubitat doesn't currently provide a way to see "ghost nodes" in the former sense, but third-party software like Z-Wave PC Controller with a Z-Wave stick (either one you're already using as the hub's primary controller or one you join as a secondary) can. There isn't a good way to see "missing" nodes in the latter sense, aside from clues that device activity may give you, but those problems are usually easier to figure out: if you added a device and then unplugged it, then you already know. 
(And again, I'm not denying that this could cause problems, and it's something I avoid if I can...just pointing out that some people are talking about two different things.)
4 Likes
yep!! I am a big fan of zniffing.. uzb3 + PC Controller FTW... 
Another issue can also be if you have a flaky device - one that sort of responds now and again or has errors or is repeating at a far slower rate (like 9.6kbps) - even if you disable it at the hub it can cause problems with other devices in the network that aren't disabled. This is not really an HE problem but it may impact HE by slow performance, dropped devices etc.
disabling may give a false sense of security.. it's not a bad start of course.. especially if troubleshooting apps and such.
This is a really interesting thread for me because I have a number of zwave devices that are included in my C-4 hub, but are unplugged and not in use. I'm doubting that these devices are slowing my hub.
Now I do get some rather lengthy periods of non-response from the hub. By that I mean I will trip a motion sensor but my light won't come on for 20-30 seconds. This isn't often, but it does happen. I have a good number of non-zwave plus devices. To compensate for these I have some periodic events that either poll or refresh these devices. I would be interested in comments on what delay I could expect if I had the hub refresh say 20 devices every 30 minutes. Would the hub sequentially do the refresh without ignoring other events or would it finish the total refresh before responding to events? I do not use the polling app.
I thought that polling could cause things to slow down so maybe thats part of it. Old GE switches were notoriously bad at least according to these forums
As far as things included but unplugged - that doesn't appear to be a good idea but I dunno if it is okay within the bounds of the ZWave spec. I guess the network will eventually sort itself out but turning "routing capable devices" on and off seems like it may cause chaos at least temporarily.
I got rid of my non-plus GE switches in favor of GE Zigbee switches. With polling enabled, a Z-Wave repair took much longer to run (and I only had 3 non-plus devices to poll). I would assume polling is a burden that only gets worse with more devices needing polled.
1 Like
I have a problem that one z-wave device is causing the repair to take hours. BUT, I dont know which one.
So I would like to disable the z-wave devices one at a time to check. But I cannot fint the setting that disables a z-wave device????
Go to your devices. On the top right, click the X icon to show the disable column. You can then disable individual devices
1 Like
THANKS!!!!
Henrik
