I was wondering if somebody could either direct me to some description about Habmin and especially the Z-Wave viewer or could be so kind to explain a bit how to interpret what I can see there.
Prior to upgrading to OpenHAB 2.4 stable this was pretty easy - seeing green lines between the Z-Wave Controller and the various Z-wave nodes which either were green (all good), had red circles (battery devices) or were red (not available).
Now I faced quite some misbehaviour after some weeks of fine operation (no changes on the Z-Wave network whatsoever) I could see green lines as well but also tons of red arrows ein various directions (even back to the same node). The Z-Wave Controller wasn’t directly connected to all the nodes anymore but it looked like it really became a mashed network (Sorry, I missed taking a screenshot).
Having done a reboot (4am, so I understand after the nightly heal?) I can now again see the Controller as a central point but all lines to the various Z-Wave nodes are red.
What does that mean?
Could now add a screenshot for better illustration.
Whats really confusing is that while Node 1 is the controller it is Node 38 - a battery operated device - that seems to play a central role?
And what is with Node 30 - a simple Wall Plug switch - showing an arrow to itself…?
I’m not expert on zwave so what I’m about to say may be wrong. First of all, I have no idea what the red arrows represent.
But what I do know is that the map doesn’t show you what you think it does. The map is not showing you how the messages are routed through the mesh network. It only shows neighbors. Your battery powered node 38 is playing a central role because it’s physically located where it is close to lots and lots of nodes which it counts or that count it as a neighbor.
But just because lots of nodes see one particular node as a neighbor doesn’t mean it plays any particular role in how messages get routed. As a battery device, clearly it doesn’t route messages.
The fact that so few devices count the controller as a neighbor though does point to potential mesh problems. You might add another mains powered device physically located between the controller and the rest of your nodes so there is at least one more node that is a direct neighbor of the controller which should open up new routes for messages to flow and improve the mesh. I don’t know if I’m correct, but I would read this to mean that all your messages to and from the controller are being routed through node 34 since it is the only mains powered node that is a neighbor of the controller.
Thanks a lot Rich for your input! It’s always very helpful to get other insights - thanks a lot!
Nevertheless, this is really super confusing…
The point is, that the node 1 / controller is located in the basement - yes I know it’s probably not the best place - very close to node 38 - a flood sensor.
Node 34 - a wall mounted switch - is located in the 2nd floor - so 3 stories above - with ferro-concrete ceilings between.
Especially Nodes 25 and 27 are way closer - just one / and 2 stories above (actually on the direct way from the controller to Node 34.)
The majority of nodes which looks like being connected to Node 38 currently are also pretty much evenly distributed all around in this little townhouse…so I had hoped that there should be plenty of mains powered devices (actually I only have 5 that arent - 25, 26, 27, 28 - and 38)
This really looks so confusing…
In my limited experience, zwave has 30 meters of range horizontally but vertically that range is significantly less. For example, I have my controller on the top floor. Only the outlet immediately below it on the main floor was listed as a neighbor. But devices that are much farther away with more walls in between them on the same floor are listed as neighbors. I added another mains powered device on the same floor as the controller and now all my devices have at least two neighbors to the controller that they could route through.
This is of course assuming that messages are routed only through listed neighbors which I don’t know whether that’s the case.
Also, wireless can be impacted by all sorts of weird conditions like interference, barriors, etc. I would not at all be surprised that nodes that are closer to the controller are
Not connected. It just that those nodes saw Node 38 is near by. That is why I emphasized the fact that the graph is not a routing graph. It just shows which nodes each thinks are their neighbors.
I really can’t imagine that there would be a lack of nearby devices - related to the controller.
I just checked and I do have (besides Node 38 (Battery)) 2 mains powered devices in even the same room (20 & 24).
Nodes 21 & 5 are just one room asides.
Nodes 15, 16, 17, 18 are only one story above (maybe 4 meters max)
I would have expected that at least those devices would consider the controller being a direct neighbour - but checking the things attributes they truly aren’t.
Trying to narrow down the issue that to me seems like suddenly started this Monday / Tuesday (I am not aware of any change at my side) I would be wondering if maybe the controller or Node 38 might go nuts.
Is this a valid thought or pure nonsense?
First question is are you actually seeing any problems with the performance of your zwave devices? Extended delays after issuing a command or lost command for example?
Or are you just concerned about the chart? If it’s just the chart I recommend to not worry about it. Don’t borrow trouble. IIRC Chris has said that that chart is not intended to be used to diagnose networking issues. It’s entirely possible that the chart isn’t working correctly in 2.4 release. It definitely was not working correctly in 2.3.
Well, yes I started to investigating for I really had quite significant delays on commands and pretty slow update of devices status (switch state, power consumption) which pretty much started out of a sudden.
Partially I had to manually initiate a switching command until updates coming from the node itself were again shown.
I by now shut down the raspi, replaced the Aeotec Gen 5 controller with the “backup” device (a copy of the other one) and moved the nightly heal from 2 to 4 am (just to avoid potential issue with the wifi traffic my son might still cause.
Let’s see how things might evolve now… things are coming up again slowly…
This Z-Wave stuff can be pretty confusing and worrying.
Just to be complete this is how the chart now looks like:
So this morning the situation seems to be pretty stable again.
Some seconds delay on issued Z-Wave commands and as well for seeing updates on associated channels, but first impression is, that this is in bounds (as far as I can judge).
Also looks like that once a device has received a command it reacts quicker the next time.
To be complete I still also want to share how the Z-Wave Viewer presents the situation now:
Zwave controllers definitely benefit from periodically doing a soft rest, which IIRD means a full power cycle. Some computers, I’m not sure about a Pi, do not power cycle the USB ports when restarted. I usually shutdown and remove the stick, just to be sure it’s not getting power. It’s a good thing to do as a first step in troubleshooting zwave issues.
Although, your other controller could also be having issues. Might want to swap it back in to make sure, before you need the spare.
Wifi will have no effect on zwave… totally different frequencies. Well… unless maybe if the radios were on top of each other, but…
Actually the active one was the “Backup” of the “Original” that had worked for more than a year without any hiccups (but certainly some power off and on cycles).
I haven’t had any changes (nodes added or removed) for last 1.5 years or so - I just created a second stick to be on the safe side if one would die.
From your experience - are the backups of the Z-Stick Gen5 Backup Tool reliable?
Would be a pain if it would turn out that Backup Sticks created with this tool weren’t true Backups (ok… the Backup worked here flawlessly for ~ 1.5 Months)
What I noticed though is, that the backup of the “backup” stick (taken right after having been created) differs from the backup of the “original” stick which has been taken right in advance (doing a file compare)…not a lot but still not a 1:1 copy…
The tool is flaky at times, and not all backups were successful. IIRC, sometimes they were half the size. I’d do another one, and it would be the right size. At times the tool needed to be restarted to get it working properly. I always get the latest version available, when doing backups.
I used a backup of my Aeon Zstick, and restored it to a Nortek HUSBZB-1. I tested this several times before finally putting the HUSBZB into use. Others reported trouble doing this, but it worked for me, and I’ve done backups/restores to another spare HUSBZB. The backup is a memory dump, so I can understand there being slight differences… there is a lot going on behind the scenes in managing the zwave network. Even powering it up could change things slightly, as it pings devices or updates routes, assuming the route table is included in the backup.
Just backup and restore to your other stick, then use that one. Then you’re sure the backup is good, and still have the original if it is not.
Yep, guess I will switch back to the “Backup” by chance and see how things are going.
Glad to have another spare stick here that I could use as well as a last resort - backup files all having the same size and at least worked once for restore.
I assume if the restore fails it fails - but wouldnt work for more that a month…agree?
Would you have any other link for the lastest Z-Stick Gen5 Backup Tool then this one?
I agree… if it works right away, then it should be good. But the hardware may still be bad. It’s electronic, so expect something will burn out after a few years… maybe not fatally. I didn’t realize the backup tool hasn’t been updated since 2016… but that’s what I’ve got 18.104.22.168.