Z-Wave JS Failed Nodes (but working and Active)

Hi all,

I’m pretty new to HA/Z-Wave JS because I’m migrating from SmartThings. So far I have managed to setup some of my Z-Waves nodes using Z-Wave2mqtt.

I have a weird situation; I have 3 nodes that are marked as Failed, however they are also marked as Alive/Awake and when I try to use them they work correctly.

What could be the problem here?

1 Like

Another interesting to note is that I don’t think the Z-Wave Graph is showing as it should. It looks like all my devices are disconnected (?) except the three that are failed:

Of course, I have restarted HA/Z-Wave JS and the whole VM to see if it’s a temporary problem but it looks like this issue remains

Hi, I’ve got the same problem with one node. It works normally (ecolink door/window sensor) but shows red/failed. Did you ever get an answer to this?

Same problem happening here as well (zwavesj2mqtt user)… the nodes marked failed are not really failed, and trying to remove the failed nodes returns an error to the effect that nodes cannot be removed because they responded to a ping (makes sense to me).

Of interesting note, is that this seems to only happen to a few of the Ecolink “DZWAVE25” door/window sensors. The issue appears to be intermittent, as I have many more of these sensors that are not showing as failed. In addition, some of the failed sensors have been included since before I switched to zwavejs, others have been re-included. Of the ones on my list of failed nodes, 2 have been reincluded (just yesterday actually), and 2 are very old inclusions (circa original zwave integration). The fact that the older inclusions are showing failed may be interesting to those who know the software well. My suspicion is this has to do with zwavejs2mqtt, or rather it seems if zwavejs read nodes as failed they would not work and not show as “ready”.

OTOH, I have reincluded some other type devices without issues (for example my thermostat works fine after re-including it yesterday, and so are my aotec g5 recessed door sensors).

Not sure this is related, but all of my recently reincluded ecolink door/window sensors have had issues with the tampering cover being reset to idle when the cover is replaced (state remains “open/unsafe” until I change it using dev-tools). I noticed there seems to be what looks like a fix for this recently in zwavejs (not released to HA users yet).

I am curious if this failed node thing magically goes away when that patch is in place?

Did you run a “Check All Failed Nodes” command, or run “Check Failed” command for individual nodes any time recently?

Yes I did do that, which I believe is what flagged all those nodes as failed to start with. I can’t be sure though, but I didn’t notice any failed flags until after I did a “Check Failed”.

Yes, that’s exactly what caused it. In summary, you can simply ignore the status for battery nodes. When you ping battery operated nodes they never respond unless they are awake (they are usually asleep), so the controller considers them failed. Restarting zwavejs2mqtt will clear its copy of flag until you do it again.

OK thanks freshcoast, you’re always so damn helpful! :wink:

I did a reboot did in fact clear all those failed flags, however it seems like this is a bug that should be fixed. Unless I am missing something fundamental, it seems Zwavejs2mqtt should update itself with the correct status as soon as the nodes awake, which it does not do. Incidentally, I also tried “reinterview” and that didn’t change the failed flag, despite the interview process being succesfull otherwise.

It also makes me wonder if I tried a network heal with failed flags like this… would that mess up the network? I assume I should probably do another network heal, since I did one while these nodes were listed as failed.

When you are checking if a node is failed, you are just asking the controller if the node is in its failed list (stored in the controller memory). The driver doesn’t track this information, and when you call the function zwavejs2mqtt just simply caches the result and reflects the value in its UI. AFAIK, it doesn’t have any relevance anywhere else, except internally with the controller.

It’s probably debatable if it’s a good idea for zwavejs2mqtt to actively refresh the failed status. You could submit a feature request and see what they say. A node could wake up, then zwavejs2mqtt could check if it’s failed, and in some circumstances it could still say it’s failed. I’m not really even sure there is any value in showing or checking if battery nodes are failed. :man_shrugging:

EDIT:

Sorry, NVM. I didn’t see you responded in the other thread.

Unless the battery operated node is actually failed but it isn’t (never) showing as failed in the control panel so that the failed node can be removed.

Any advice on removing a failed node that doesn’t show as failed in zwavejs2mqtt?

I’ve factory reset it and pinged it a half dozen times over a couple of days. I even pulled the battery and let it sit.

Where can I do that from?

I didn’t find it in the main controller actions list. I only found the one for the individual node and I used that many times too and the node never changes from asleep to failed so I can remove it.