Refresh Z-Wave network?

[jojo1967 1]

I´m not shure, if "refresh" is the right work for this, but I included all my devices (window sensors etc.) in my living room with a laptop and installed them later in the other rooms. Maybe this was no good idea, because I read that the devices connect to the HC2 and to other devices nearby, to get a stable network.

Now I have some dead nodes in my HC2. I tried to exclude and include these devices again in the correct room, but I still have the dead nodes, although there are other devices with a repeater- / extender-function for Z-Wave nearby (Philio 4in1) which are still not marked as dead nodes.

Is there a function or or script in LUA to refresh the Z-Wave network? To be more exactly: A function, that all Z-Wave devices search for the next devices and the HC2 again without demounting and including each of them again....

[Krikroff 199]

jojo1967,

fibaro:call(1,'requestNodeNeighborUpdate',1)

will rebuild mesh for all devices

[anonymous66 9]

jojo1967,

fibaro:call(1,'requestNodeNeighborUpdate',1)

will rebuild mesh for all devices

What about the battery powered devices?

If I have many of them , I have to wakeup all them to rebuild the network structure

correctly?

Thanks

[wasil 0]

Correct

Please login or register to see this image.

/emoticons/default_icon_wink.gif" alt=";-)" /> Or You can wait longer time and they (battery devices) will do it automaticaly

Please login or register to see this image.

/emoticons/default_icon_biggrin.gif" alt=":-D" />

[Dalle1985 16]

jojo1967,

fibaro:call(1,'requestNodeNeighborUpdate',1)

will rebuild mesh for all devices

What about the battery powered devices?

If I have many of them , I have to wakeup all them to rebuild the network structure

correctly?

Thanks

It will request the node to update as soon as it wakes up. But I'm fairly certain you have to do it for each individual device (the first 1 in above code is the device id). I have a scene which rebuilds the entire mesh each night to avoid dead devices. I haven't seen any dead nodes after i made that scene.

[jojo1967 1]

Could you share it please?? Because I ran the script but still have trouble with dead nodes...

Please login or register to see this image.

/emoticons/default_icon_confused.gif" alt=":-?" />

[Dalle1985 16]

I'll share it once I get to a proper computer

[anonymous66 9]

Correct

Please login or register to see this image.

/emoticons/default_icon_wink.gif" alt=";-)" /> Or You can wait longer time and they (battery devices) will do it automaticaly

Please login or register to see this image.

/emoticons/default_icon_biggrin.gif" alt=":-D" />

Ok but... <> has a timeout or it will wait for

all devices wakeup?

[Dalle1985 16]

Okay, as promised, here is my scene for checking for dead nodes and updating the routing table. So what this code does is that it checks all devices for being dead. If the device is marked as dead, it will send a wake up command and then request all nodes for a routing update.

Please login or register to see this code.

*** EDIT ***

After reading up on the function, I have found that updating device 1 (the HC2) will rebuild the entire mesh. So the code has been remade to just update that one device after waking up dead devices.

*** EDIT2 ***

Added a sleep command to the node update command based on suggestion from A.Socha.

[Rami 0]

any idea how to do this on HCL ?

[jojo1967 1]

@Dalle1986: One question about your edit - does that mean, that your script has to be changed, or is it still a good workaround to avoy dead nodes?

[robmac 173]

*** EDIT ***

After reading up on the function

Hi,

Where did you find the documentation to read? Would love to have a look. Is there more about other functions?

regards,

[Dalle1985 16]

*** EDIT ***

After reading up on the function

Hi,

Where did you find the documentation to read? Would love to have a look. Is there more about other functions?

regards,

It was something that Andrew wrote in another post, that updating routing for device 1 would update the entire routing table.

[ Added: 2014-06-03, 09:28 ]

@Dalle1986: One question about your edit - does that mean, that your script has to be changed, or is it still a good workaround to avoy dead nodes?

The above code is still good... I changed it to reflect my updated knowledge.

[robmac 173]

It was something that Andrew wrote in another post, that updating routing for device 1 would update the entire routing table.

Thanks for the response. That now makes sense. Always looking for more official docs.

Please login or register to see this image.

/emoticons/default_icon_smile.gif" alt=":-)" />

I don't think you have edited the code in your post. I guess you are now using something like

Please login or register to see this code.

Which is not far different from what I use.

but for belt and braces

As some of my sleeping devices are set to long wake intervals, I have increase the time to wait for route update to twice my max device sleep time.

I also have a loop around the dead check with a 3 minute pause. It retries the wake 3 times as HC2 still has those random pauses when no outbound traffic goes out. This prevents sending a route update to a dead node but I don't often get a debug indicating it has needed to loop.

[Dalle1985 16]

It was something that Andrew wrote in another post, that updating routing for device 1 would update the entire routing table.

Thanks for the response. That now makes sense. Always looking for more official docs.

Please login or register to see this image.

/emoticons/default_icon_smile.gif" alt=":-)" />

I don't think you have edited the code in your post. I guess you are now using something like

Please login or register to see this code.

Which is not far different from what I use.

but for belt and braces

As some of my sleeping devices are set to long wake intervals, I have increase the time to wait for route update to twice my max device sleep time.

I also have a loop around the dead check with a 3 minute pause. It retries the wake 3 times as HC2 still has those random pauses when no outbound traffic goes out. This prevents sending a route update to a dead node but I don't often get a debug indicating it has needed to loop.

No, the code in my initial post is the one I'm using. If you run the code as you suggest, you would end up asking the entire mesh to rebuild each time it finds a dead node. So if the script wakes up after 6 minutes and runs through it's routine and then discovers three dead nodes in one run, it will request that the routing be updated for the entire mesh three times.

My scripts uses a trigger (request_update) which is set to one by any dead node. If request_update is 1 it will request a single update of the entire mesh once it is done checking you full setup for dead nodes.

So even if it finds 50 dead nodes in one run, it will stil only trigger a single mesh rebuild.

As to the part about waiting twice the max wake up interval, I don't think that is necessary. Because the requestNeighborNodeUpdate call will only set a value in the properties of the devices to 1 to let the controller know that a network update should be completed when the device registers in as woken up. HC2 will then trigger a rebuild of the mesh to that node once it wakes up. So there is no need to wait for the wake up interval to ensure the device respawns before triggering the rebuild.

[robmac 173]

I believe

Please login or register to see this code.

would only update the single node that is not supposedly contactable as i is the node that was discovered.

I try not to update the complete network as I have found it can make things worse but possibly it has improved since I tested.

My script is slightly different. I have never worked out if this helps as I am not convinced it is a routing issue but more that the controller outbound queue gets in a deadlock. Hope v4.x fixes the issue properly.

[A.Socha 133]

robmac, that script can kill zwave

Please login or register to see this code.

better do if device is going 3 times dead to set reqest_update to 1

for one device timeout in requestNodeNeighborUpdate' is 21m for battery device time to wake up + 21m

[robmac 173]

robmac, that script can kill zwave

Please login or register to see this code.

better do if device is going 3 times dead to set reqest_update to 1

for one device timeout in requestNodeNeighborUpdate' is 21m for battery device time to wake up + 21m

It is not the script I run but explain more.

[ Added: 2014-06-03, 14:19 ]

From what I can understand there are three versions of the call but as there is no documentation...

a) fibaro:call(1,'requestNodeNeighborUpdate',1) --updates all nodes in the network

b) fibaro:call(1,'requestNodeNeighborUpdate',anode) --updates anode in the network

c) fibaro:call(anode,'requestNodeNeighborUpdate') --updates anode in the network

where anode is the id of any node.

I tend to use a) rarely and b) if one node is not working. If that does not fix then I go back to a).

so in simple terms

I use:

a) if I have moved a node and know it needs to rediscover all nodes to find it

b) if one node is not behaving but use a) if that does not fix

but I thought c) would also work but possibly not?

It is listed in actions against nodes from the api but proper documents would help.

[A.Socha 133]

process to refresh mesh on one device can take max 21m so you should do that timeout because if you gonna send too many request can this block controlling devices so let say you got 1 really dead device, so every 1minute you will send request action

[Dalle1985 16]

Okay, so if I run the code I should timeout for 21 minutes to avoid any issues?

[1152 33]

robmac, that script can kill zwave

Please login or register to see this code.

better do if device is going 3 times dead to set reqest_update to 1

for one device timeout in requestNodeNeighborUpdate' is 21m for battery device time to wake up + 21m

It is not the script I run but explain more.

[ Added: 2014-06-03, 14:19 ]

From what I can understand there are three versions of the call but as there is no documentation...

a) fibaro:call(1,'requestNodeNeighborUpdate',1) --updates all nodes in the network

b) fibaro:call(1,'requestNodeNeighborUpdate',anode) --updates anode in the network

c) fibaro:call(anode,'requestNodeNeighborUpdate') --updates anode in the network

where anode is the id of any node....

Wouldn't c) also act as a) if anode=1 ?