Zensys zwave tool & zwave issues

I have so many issues with my zwave network, and I have a feeling that it is getting worse and worse. After a restart of OH, I will not have a working for many hours (well it can work, but very randomly and slow). Sometimes, I need to restart OH a couple of times, to get the zwave net up and running at all - the debug logging simply stops when it does not work.
So, I decided to try to clean up my controller node list a bit. I have about 75 working nodes and about 5-10 nodes that are missing due to them breaking down, or otherwise removed. Maybe they are part of the problem?!
I suspect that another problem is the fact that my two story house has a concrete slab between the floors, and other non-optimal rf environment, especially in the basement/ground floor (concrete and brick walls, chimeys etc etc).

So I started the zensys tool, and afict, there’s no manual or help on this software - but I found some information on the net, suggesting to select the dead node, and simply press the “remove failed node” button.
However, this does not work - e.g. my node 2 and 3 are long gone, but when I select node 3, the software reports back that it failed to remove the failed node;

Am I doing this the wrong way? I have also tried to select a dead node, and then press the ‘Is Failed’ button - sometime the node text then turns red. But it still fails to remove it.

And even stranger - I just now selected node 2, which also is missing since a couple of years, and pressed ‘Is Failed’ - where the tool responds “Selected Node is normally running”! But it cannot, and looking at the Topology map, it is totally red - no nodes know about it!
I tried a couple of times, with the same outcome. Then I tried to set Basic ON/OFF on the same node a couple of times, after finally, I could set the node as Failed. But cannot be removed using the ‘Remove Failed’ button.

If anyone have any suggestion why this does not work, or really, any kind of help at all :slight_smile: I’d appreciate it!

Edit: It seams that I need to be persistant in trying - after about 10 tries, I can remove my first node! :slight_smile:
This is the exact way of doing (in my case I had to try many times) Remove a ghost Z-Wave Node from HABmin?

OK, so in order to try to understand the Zensys tool better, I have now arrived to the routes tab - setting up routes.
In my case, some randomly selected nodes comes up in the “Setup Routes” tab. They seem to be battery devices, but not all of my battery devices are here.

Is there a way to add other nodes here, in the left (source) window? Especially the battery nodes that are orphaned in the Habmin network view?

The Topology map is really useful in Zensys tool.

Sorry for the rambling. :slight_smile:

This has always worked for me:


yes - works perfectly for me too

Thanks guys!

This was the guide that I ended up using. And after removing the dead nodes, starting up OH seamed much faster, and it started up on first try, so I hope this made a difference! Time will tell, maybe I just was extremely lucky with this start-up.

Any comments on my second post? I still have a few nodes that are orphaned;

Some of them are controllers, which may never get a true neighbour? (@chris Is this a proper conclusion?).
But node 86 and 88 are Fibaro smoke detectors, they should be in the haystack. But as you see in my second post, they are not in the Setup Route Source list, so I’m no sure how to add them??


Controllers should still have neighbours I would expect.

Remember that this graph has nothing to do with routes - the routes list that I think you are talking about (although I’m not sure as I’ve never use the software) is a list of source routes that the binding will normally set. This is generated by looking at all the associations - so if not 3 is associated to node 2, then the binding sets a route from node 3 to node 2 - this is not linked to this graph at all and it is up to the controller to select the route.

1 Like

I read in a rather old pdf from zensys, that controllers make up their own neighbour list, but it wasn’t conclusive if the main controller would get/ask for that list. (5, 64,75 are controllers)

Maybe someone has wall controllers or keyfobs in the haystack, and can chime in?

But battery nodes 5,64,75,86,88 are the ones missing - exactly the ones that are orphaned in HABmin. And I do not have any associations on most of them, apart from to controller, which most if not all my battery nodes have.
I.E. I do not think this is related to associations, but to routes. But just for fun, I’ll add an association to one of the controllers.
The Zensys software is a bit complicated/very technical, though it has its own tab for associations.

Yes, this is true, but I would still expect controllers to respond when asked for their neighbours.

I don’t know what you mean by this? It’s certainly not related to associations, but associations are what the binding uses to decide what devices to set routes to. But this does not influence the graph.

Devices do not know how to derive routes - the controller tells it. The controller looks at what devices want to talk to each other, and sets routes between them, otherwise they don’t know this by themselves. The controller uses the list of associations to build this routing list. Again though - this is not related to the graph which shows neighbours - not routes.

Maybe I also don’t understand you, but here goes:-

Yes, I understand this is all in the controller - since Zensys only has this at hand (no binding here). But the Route tab seams to me like a way to add routes from the battery nodes, to the nodes on the right hand. I one select one node on the left (source pane), and one on the right pane, “assign” lits up. But I guess I am not fully convinced by my own guess, since the user interface could have been made so much easier, should this be about manually adding neighbours.
I should have checked if an added route comes up as a neighbour in the “Topology map” of the same program. I never checked this, and it is too late now to do this, since I don’t want to stop OH during the evening, since there’s a lot of rules and so going on.

I do not think these existing nodes are available because some (earlier) associations I simply think this is the representation of battery nodes, of which one can manually add routes (neighbours) to, and somehow the controller are missing the 5.

Some people reportedly used the Zensys tool to add orphaned nodes (in Habmin network view), unclear how they did this.

Again, the plot in HABmin shows neighbours - not routes. Really.

Are you talking about the representation in the ZenSys software or HABmin? I assume HABmin as that’s the plot you showed above and asked me about. This plot will normally show links to battery nodes in HABmin - if they have responded to the neighbour request.

No. Sorry, but I’ll say again. Routes and neighbours are not the same thing. You can not add neighbours - this is something the device detects. You can add routes, but this is handled through the controller. When you add a route, the controller will look at the best ‘route’ through the network, using the list of neighbours from each node.

In HABmin, yes I know!!

I’m talking about Zensys tool, this is the thread… The only connection and relation is that the nodes in HABmin that are orphaned are exactly the ones that are not listed in the “route tab” in Zensys. I refferred to my second post whith the screen shot of the “Setup Route” tab.

OK, so then we are back to the question why these 5 nodes does not respond to the neighbour request.

Still it seams that some people have succeeded in getting them into the haystack (what I call the network view in HABmin), by either reinitialize the node, or using the Zensys tool in some (to me) unknown way.

This is what I’m humbly trying to do.

If they are battery devices, then maybe they haven’t woken up - this is always a problem with battery nodes.

This can only be through doing a node neighbour update - as far as I’m aware (having read a LOT of the official Sigma documentation) there’s no way for force a neighbour. It also makes no sense to me to do it as neighbours are added by the node - only the node can tell what devices it can hear. RF propagation within a building is not simple or obvious.

Is there’s some way of knowing if they have woken up? I know I have sen’t NIF 1000 times, but maybe this does not always wake all nodes.
I.e. is there something in HABmin that indicates this?

Yes - the last wakeup time is shown in HABmin thing properties.

I don’t know what the Zensys tool does, but if it doesn’t continue to wait for a wakeup, and then ask for the neighbour update, I’m guessing it won’t update. I don’t know this though. The binding does wait for the device to wake before sending this command (if I remember correctly…).

OK, then I think I know how to proceed;
I simply reinitialize one of the bad nodes, and log until it is woken up, then check to see what they say about neighbours.

Looking in the log, all of the three controllers has responded “NODE xx: No neighbors reported”.

The two smoke detectors I’m not sure about, will wait a couple of hours to make sure they have actually woken.

This is an interesting document that I found years ago (surprised it’s still available… but more surprised that I could find the link!) when I was trying to figure out Zensys Tools. It’s a user manual from Sigma Designs for the UZB3-U zwave controller, but they describe some of the functionality/use of Zensys Tools (Sigma purchased Zensys).


I happened to be poking around the Aeon Labs support site to determine what was included in the G1 HEM firmware update that came out in Sept, and found this post. It looks like their OTA firmware installer app is a rebranded (updated?) Zensys Tools. I downloaded it but have not tried it yet. The pics looked like some of the functionality was removed. But in case the other download links dry up…