Mesh reconfig

[Neo Andersson 230]

Hello

I have tried several times reconfiguring a device mesh, as it seemed to loose connection occasionally.

However it still seems that there was not any mesh difference at all after the reconfig.

The device still tried to use neigbours that are far more distant than others in device neighbour.

I have tried to get some info about this functionality, but still could not get any direct answer,

Maybe @m.roszak can you please assist here a bit.

It is still a dark hole to me, as it never get changed. Doing the device mesh reconfiguration process (either from regular web user UI or installer web) never changes anything on the device's communication track.

It still remains as it was.

Many times we see, that device tries to hop to the Gateway, but fails, so we tried reconfig becuase there were a lot of neighbours that could be used as hop points, but never worked.

Is it working at all? If so how?

[Tim__ 126]

You may know this already, but for those who don't, a battery powered device can not be used as a zwave repeater. 

 

For HC2, I update the zwave mesh for problem devices only, starting with those closest to the HC. Then I move to the next problem device. This gives you some control over the changes.

[petergebruers 1,268]

In Z-Wave there is this devious thing I sometimes see as the cause of "silly routes", it is called "Explorer Frames" - a good idea that can go wrong if it is triggered by network saturation, or communication during BEAM-ing of (distant) devices. Those are broadcasts sent when devices think they have no valid route to the destination and they can appear on large saturated networks. They do not always mean trouble but sometimes they make a device learn a long and "silly" route. Especially when part of the network is "BEAM-ing" this can be tricky to diagnose. Devices like FGT-001 need BEAM packets but even without these devices networks can exhibit BEAM packets. It depends on the age of the SDK used to build the device. Details are undocumented and information is also not "open".

 

14 hours ago, Neo Andersson said:

The device still tried to use neigbours that are far more distant than others in device neighbour.

 

Z-Wave has no concept of "distance" like human beings. Two devices are either "neighbours" or they are NOT-neighbours. So to speake, they are either "close enough" or "too far away"

 

If, like me, you analyse Zniffer logs for more than 200 hours you will notice that the "standard" Z-Wave routing mechanism prefers low node IDs. I speculate that the routing info is sorted by Nide ID in memory and when the algorithm tries to find a route, it simply goes through this table.

 

BTW Z-Wave has 3 different routing mechanisms (4 if you count priority routes as a different concept)

 

- no routing at all, direct packets without repeaters...

- source routed packets with routes *defined* when you do a mesh update... Each device can hold 4 such alternative routes. The controller gives the routes to the device. The devices can learn through "routed NAKS" which of them is (in)valid

- explorer frame routing: This is the "newest" and runs if all other options fail. This is in layman's terms a broadcast mechanism with route information and data at the same time, so data should travel to the router and when confirmed the device learns a new route.

 

IMHO devices tend to "stick" to the last known working route. If you do a mesh update a device might get routa ABC and use it, until something makes that route fail, it then tries XYZW which seems longer and in efficient but succeeds... The device wil then "cling" to XYZW

 

Without spending 2 hours onsite and analysing your actual problem I cannot give you good advice.

 

Something to keep in mind though is that for larger setups (I consider > 50 nodes rather large) it might make sense to have two controllers. AFAIK Fibaro has this excellent master/slave which I have never tried because it is usually to late to implement it, it requires empty HCs to setupI! I do know multi-controller setups based on open source and it simply increases bandwidth, increases reach and reduces contention so overall a more reliably experience than trying to, let's say, optimize a single 150 node Z-Wave network.

 

 

 

 

I have worked with @robmac many times and discussed routing in great detail. He wrote this excellent summary targeted at a wider audience

 

Please login or register to see this link.

Please login or register to see this link.

[Neo Andersson 230]

4 hours ago, petergebruers said:

In Z-Wave there is this devious thing I sometimes see as the cause of "silly routes", it is called "Explorer Frames" - a good idea that can go wrong if it is triggered by network saturation, or communication during BEAM-ing of (distant) devices. Those are broadcasts sent when devices think they have no valid route to the destination and they can appear on large saturated networks. They do not always mean trouble but sometimes they make a device learn a long and "silly" route. Especially when part of the network is "BEAM-ing" this can be tricky to diagnose. Devices like FGT-001 need BEAM packets but even without these devices networks can exhibit BEAM packets. It depends on the age of the SDK used to build the device. Details are undocumented and information is also not "open".

 

 

Z-Wave has no concept of "distance" like human beings. Two devices are either "neighbours" or they are NOT-neighbours. So to speake, they are either "close enough" or "too far away"

 

If, like me, you analyse Zniffer logs for more than 200 hours you will notice that the "standard" Z-Wave routing mechanism prefers low node IDs. I speculate that the routing info is sorted by Nide ID in memory and when the algorithm tries to find a route, it simply goes through this table.

 

BTW Z-Wave has 3 different routing mechanisms (4 if you count priority routes as a different concept)

 

- no routing at all, direct packets without repeaters...

- source routed packets with routes *defined* when you do a mesh update... Each device can hold 4 such alternative routes. The controller gives the routes to the device. The devices can learn through "routed NAKS" which of them is (in)valid

- explorer frame routing: This is the "newest" and runs if all other options fail. This is in layman's terms a broadcast mechanism with route information and data at the same time, so data should travel to the router and when confirmed the device learns a new route.

 

IMHO devices tend to "stick" to the last known working route. If you do a mesh update a device might get routa ABC and use it, until something makes that route fail, it then tries XYZW which seems longer and in efficient but succeeds... The device wil then "cling" to XYZW

 

Without spending 2 hours onsite and analysing your actual problem I cannot give you good advice.

 

Something to keep in mind though is that for larger setups (I consider > 50 nodes rather large) it might make sense to have two controllers. AFAIK Fibaro has this excellent master/slave which I have never tried because it is usually to late to implement it, it requires empty HCs to setupI! I do know multi-controller setups based on open source and it simply increases bandwidth, increases reach and reduces contention so overall a more reliably experience than trying to, let's say, optimize a single 150 node Z-Wave network.

 

 

 

 

I have worked with @robmac many times and discussed routing in great detail. He wrote this excellent summary targeted at a wider audience

 

Please login or register to see this link.

Please login or register to see this link.

Peter, thanks for the extended asnwer, really apprecieate it. So in general, this means, i can do nothing about this problem, I can not solve diconnetcintg devices by mesh reconfig. If i got it correctly, the only way the dvice will re-meshed when we remove it and add it again.

 

However there is one thing you mentioned, that i don't really understand , whe you talk about master/slave configuration

 

"it requires empty HCs to setup"

 

i don't think so..You can setup master/slave configuration on an existing system with an existin HC3 full of devices, and then add one more slave device (maybe i misunderstood you)

 

Anyway, thank you..

 

 

 

Edited April 29, 2024 by Neo Andersson

[petergebruers 1,268]

8 minutes ago, Neo Andersson said:

"it requires empty HCs to setup"

 

i don't think so..You can setup master/slave configuration on an existing system with an existin HC3 full of devices, and then add one more slave device (maybe i misunderstood you)

Rightttttttttt, yeah, I cannot remember the exact conditions, I may indeed have been thinking about users having two HCs, both with some end-devices on. I thing that kind of setup cannot be turned into a master/slave.

 

The configuration page won't let you make a mistake eg it also checks version numbers of potential slaves and Z-Wave engine

 

I could test but at the moment I do not have my test environnment ready, I am doing some rebuilds...

Edited April 29, 2024 by petergebruers

[Neo Andersson 230]

36 minutes ago, petergebruers said:

Rightttttttttt, yeah, I cannot remember the exact conditions, I may indeed have been thinking about users having two HCs, both with some end-devices on. I thing that kind of setup cannot be turned into a master/slave.

 

The configuration page won't let you make a mistake eg it also checks version numbers of potential slaves and Z-Wave engine

 

I could test but at the moment I do not have my test environnment ready, I am doing some rebuilds...

You dont need to test it,  I am doing it many times. Yes it won't let you go with different versions, so you need to have the same version on both systems, but that's it. You can then add a slave to an existing HC3 without any problem.

[Neo Andersson 230]

1 hour ago, petergebruers said:

I thing that kind of setup cannot be turned into a master/slave.

Yes you can, there is a button Prepare gateway to be slave (or something like that)

I can't show you, becuase i don't have any getaway in reach at this moment, but i am 100% sure, there is that possibility.