Hi, I’ve got an Aeotec stick connected to my desktop computer which is running HA on Virtual Box, and using Zwave JS UI add-on. I have added a door lock and would like to add another one; however the second one is further away and I’m unable to include it (probably 50 feet, but past several walls).
I do think that if I routed requests through the first lock, it should be able to reach the second, as they are almost line of sight. Do you know if the inclusion process tries to route through existing nodes, or does it only do inclusion directly to the controller and then try to optimize the network later? Is there any way to force the controller to route things through a node, in order to run an inclusion?
Hi.
In your specific case, as freshcoast says, just put another active Z-Wave device (i.e. a repeater device) in a suitable location between the Z-Wave stick and distant device. It needs to be a powered device (not battery). Most powered Z-Wave “activator” devices are repeaters, but not all. Z-Wave module Mains light switches & dimmers, smart plugs, etc. are usually repeaters.
Sensors tend to be very low powered, often battery driven, and so without the repeater functionality, even if USB powered (preferable for better functionality, performance and reliability).
One of the strengths of the Z-Wave platform is it’s ability to self-heal. I.e. to change it’s routing dynamically if a routing problem occurs. So if you force a routing then you’d weaken the Z-Wave network, which is counter-productive. Z-Wave will normally find the best routing anyway - if one is possible.
The other option is to put your Z-Wave stick in a different location using a USB extension cable (up to 8 metres max - unless you use a powered extender). That has several advantages. It distances the Z-stick from interference from your computer and allows you to position it more optimally. But keep it away from your WiFi access point/router (interference again). On your computer, prefer a USB2 outlet to USB3 too as USB3 may also cause interference.
If you’ve got the Aeotec stick with the strobing LED light and would prefer to switch that off, there’s a nice HA method - just ask.
One of the strengths of the Z-Wave platform is it’s ability to self-heal. I.e. to change it’s routing dynamically if a routing problem occurs. So if you force a routing then you’d weaken the Z-Wave network, which is counter-productive.
This isn’t always the case. I’ve been struggling for the past couple days to get a switch added to my network. The problem is that the switch is outside the house, in a metal enclosure. When the door to the enclosure is open, the controller can reach the switch just fine. But as soon as I close the door it goes dead. I have another zwave device outside the enclosure, literally 8 inches away from the switch, but the switch wants to connect directly to the controller instead of going through this other device.
So I finally found that I can switch from the default Z-Wave JS to Z-Wave JS UI, and with that I can go to the “network graph” tab, click on the device, and set a priority route. Once I did this and forced it to route through the other device, it’s now able to stay connected.
So it seems like Z-Wave is not good at repairing itself when a device can go from a perfectly good signal, to completely dead. It seems that once it goes dead, it cannot find an alternate route.
Z-Wave routing is not the issue here. The radio reception is.
Effectively you’re isolating the Z-Wave radio device from the external world by putting it in a metal case. A “Fariday Cage”. That’s very hard (depending on wavelengths etc. and the nature of the container) for radio waves to get through. It’s like the “mesh” pattern you see on the glass window of your microwave that stops the microwave radiation from getting to you!
You need to fix the root problem (the radio aerial in a metal container) rather than find a way round the issue. Otherwise you’re forcing your device and Zwave controller to work much harder, use more power, run any batteries down faster and the electonics to fail sooner.
The best way if you can - depends on the Z-Wave device and its aerial options - is to move the aerial outside the metal case OR else use a (waterproof) plastic case. E.g. I’ve several Z-Wave switches and dimmers in electrical boxes (enclosures), but they are strong plastic, not metal, electrical enclosures, mains voltage and IP rated. No issues with them and they’re easy to work with.
Best wishes, Ian
I have also found that Z-Wave does not always pick the most optimal routing path.
As of today, I have 42 nodes, less 1 for the stick, and 7 battery-powered devices - that’s 34 nodes that can be used for routing. Some of them are very distant. Z-Wave finds a path, but it can go through 3-4 repeaters and take 30 seconds to 1 minute for one switch to answer a command. Using static routing has reduced this time for most nodes, though it’s still not instant for all of them yet.
Anyway, I’m certainly glad the static routing capability is there in Z-Wave JS UI.
Z-Wave routing is not the issue here. The radio reception is.
That argument is silly. What is the point of mesh network then? You’re arguing that devices should never talk to each other, even if they have a better signal than the device talking directly to the controller.
Otherwise you’re forcing your device and Zwave controller to work much harder, use more power, run any batteries down faster
They’re on mains power. And we’re talking milliwatts here. My electric bill might go up by $0.01 per year.
and the electonics to fail sooner.
No. First of all, running at higher transmit power doesn’t cause it to fail sooner. It’s not like it’s being operated beyond spec. Second of all, as I mentioned the devices are a few inches away from each other. It’s actually less power for them to talk to each other than for the enclosed device to talk directly to the controller.
In any case, the root of the problem turned out to be the USB zwave controller I was using. I replaced it with a different device and it now routes correctly and has worked without issue for months.
For reference for anyone else with the routing issue, I was using a HUSBZB-1 device. It turns out this is a really terrible device. First it’s ancient, so doesn’t support any modern features or functionality. Second it actually lies to the software about when routes are set. It was responding to priority route calls with a “success” message, but then throwing that away and not actually setting the route.
I see the same here: look at the network graph below - it doesn’t make sense. The network transmitting to the range extended in the attic and then to the waterpomp and “Tuin Dimmer” & “Tuinhuis and Steiger”. Going through the range extender “Range extended tuinhuis” (following the red arrows makes much more sense as this is also using faster transmission rates)
Add to that: z-wave prefers having a -95db signal over a -90 db signal…strange. The only explanation being that it prefers to minimize hops.
I’m going to set a few routes manually as this does not make any sense
It now looks like this with one question remaining: i’ve set speed to 100 kb/s - will it automatically reduce speed if the signal degrades?
Final note: if routing optimization is really that bad we need to do something about this as this impacts network stability (signal strenght should be prioritized over # hops imho).
