Prevent "optimize neighbours" on node fail

Hi,

I need to optimize alot of battery devices and they tend to not wake up when I need them to.
If I have started optimization for that device and it does not wake up (even if I try to wake it, it happens) Indigo starts to optimize known neighbours, and I have ALOT of them for every battery device. Is it possible to have Indigo NOT start the known neighbours optimization process and just wait for wakeup?

Best regards, L

[matt (support)]

Not currently, but that is a good feature request so I've added it to the list.

OK, thanks.

I have notised that issuing a "stop optimize" does not stop the neighbour optimization, is there some way I can cancel that w/o reloading the interface?

//L

[matt (support)]

No, and I'm not positive that reloading the interface really cancels the currently active neighbor scan. It might cancel Indigo's awareness that it is being processed, but I suspect the Z-Wave controller is still internally doing the operation regardless.

OK, thanks!

So I guess the only thing I can do is unplug the controller then

//L

I have been reorganizing and replacing alot of nodes now to get my network to be stable but running the "optimize" function is kind off messy.

- A high % of my Fibaro Wall connectors fail optimize if I don't do a status request a few seconds before optimize, that prevents the "optimize all" from working.
- All of my Fibaro Smoke (FW 2.01) and Water (FW 23.23) detectors does not play well w/ optimize funktion, allways fail. Only one Smoke detector (FW 3.03) worked and that is my newest one.

Is there some other way to have a node re-discover their neighbours? re-sync does not do that what I can see. Adding the node to a new device an sync, does that trigger a search? And then back to original device in Indigo. I do not want to exclude the problematic nodes and re-include them, my ID's is running out!! I'm on 191 now, what happens if I pass 255??

Is there some way to list devices that do not support "explorer frames"?

//L

[matt (support)]

Is there some other way to have a node re-discover their neighbours?

Instead of selecting All Devices on the optimize, select the individual device you need to optimize (find neighbor nodes). Note all optimizing does is request that the controller (Z-Stick/etc.) issue a command to the module to find its neighbors, which then causes the controller to rebuild routes (if neighbors change). The ability to repair/optimize/fix routing is pretty much limited by the controller to just asking that it have a module rediscover its neighbors. Indigo has very little control over the process.

Adding the node to a new device an sync, does that trigger a search? And then back to original device in Indigo. I do not want to exclude the problematic nodes and re-include them, my ID's is running out!! I'm on 191 now, [b]what happens if I pass 255??[/b

Excluding and re-including (and re-syncing) will also cause the controller to rediscover the best route to the module. Don't worry about the address limit, it should start re-using old addresses if you hit the end.

Is there some way to list devices that do not support "explorer frames"?

No, Indigo doesn't store that information about the devices.

Thank you!

Instead of selecting All Devices on the optimize, select the individual device you need to optimize (find neighbor nodes). Note all optimizing does is request that the controller (Z-Stick/etc.) issue a command to the module to find its neighbors, which then causes the controller to rebuild routes (if neighbors change). The ability to repair/optimize/fix routing is pretty much limited by the controller to just asking that it have a module rediscover its neighbors. Indigo has very little control over the process.

I always do them one at a time, but the optimize function does start to optimize known neighbours if it fails and that process talkes forever with 100+ known neighbours (that in turn fails as well). For my battery devices it almost fail atleast the first 1-3 attempts so it takes forever, thats why I would like skip the "optimize known neighbours" part.

//L