I know for a certain fact I have a switch that is close to the hub that is not directly connected to the hub. It uses a switch close to it for routing.
Problem is that other things use this switch as a router and then gives a latency I want to get rid of.
But I can’t find any way to optimize just repair. Repair does not change this routing.
Any tips on this?
The whole point of mesh is that it does its own routing. You can’t force it to take a particular route. Optimization should be automatic.
You can fool it, but only until you do the next zwave repair.
Fooling a zwave device in order to force a different route
So let’s say you have switch A, which is the one that has been using switch B as a repeater and you don’t want it to. Both of the switches are physically close to the hub and to each other.
Start by removing switch B from the network all together. Now it won’t be available to use as a repeater.
Run a zwave repair. This will cause all of the other devices to update their neighbor tables, and this time they won’t have switch B as a repeater option.
Wait at least four hours, and preferably 24, to make sure all the address tables get updated.
Now add switch B back into the network, but do not run a network repair. This should mean that switch B stays invisible to switch A, although the Hub will know that it exists.
You would have to repeat these steps every time you wanted to run a zwave repair in the future.
Looking at the problem again
Having said all that, the problem that you are describing shouldn’t happen to begin with, Since switch A is physically close to the hub, it should be communicating directly to the hub and not going through a repeater. So I’m not really sure what’s happening.
By any chance is switch B an energy reporting switch? I am wondering if it is flooding the hub with messages and that’s why a second route is being chosen.
I think the first thing I would try is to remove switch B from the network and run a repair and see if you really do get an improvement in latency by doing so. ( remember that because of the time it takes to update the address tables on each individual device you might not see improvements until the next day.)
If you do see less latency with switch B off the network, I would tend to suspect either that switch B is a defective device or that it has a feature, like energy reporting, which is causing traffic jams on your network.
Thx a lot for tips @JDRoberts , my next step was to do a exclude and include after repair.
But I wanted to try to find a way before I did that to try to get a grip on what tools is available in ST for this kind of matters.
Look at the picture here, node 38 and 39 are buttons and therfore not a part of the mesh. node 3 is aprox 3 meters away from the hub.
It is a routing switch with reporting, but it does not flow the mesh with data, done the live log.
The result is that a scene triggered by a switch running throug nr 3 is a turn return 3-4 seconds delay before a Core piston does it trick.
Brand and model of node 3? ( which is switch A in the previous example, right?)
Is this by any chance a secondary controller?
Fibaro dimmer 2 as node 3, ST as node 1
Node 2 is a z-way as a pure node.
So only one controller.
Might be smart to do a factory reset of the dimmer.
1 Like
He…l of a work, had to disjoin and join lots of fibaro dimmers.
Something must have gone wild once i rebuilt my z-wave du to a hub replacement.
But I got a good mesh now @JDRoberts thx for tips btw.
99% of ST users would never be able to se this info, thats to bad realy.
ST need some real z-wave tools to be public.
1 Like
What tool is that?