Zwave unknown nodes?

shorty707 · February 2, 2019, 7:15pm

lately I see different node ids in the log with the following warning.
those are always node ids that have never been on my network.
anything plausible where something like this comes from?
cheers

20:10:59.455 [WARN ] [rnal.protocol.ZWaveTransactionManager] - NODE 148: Not initialized (ie node unknown), ignoring message.
20:10:59.466 [WARN ] [rnal.protocol.ZWaveTransactionManager] - NODE 148: Not initialized (ie node unknown), ignoring message.
20:10:59.644 [WARN ] [rnal.protocol.ZWaveTransactionManager] - NODE 148: Not initialized (ie node unknown), ignoring message.
20:10:59.738 [WARN ] [rnal.protocol.ZWaveTransactionManager] - NODE 148: Not initialized (ie node unknown), ignoring message.
20:10:59.993 [WARN ] [rnal.protocol.ZWaveTransactionManager] - NODE 148: Not initialized (ie node unknown), ignoring message.

luckymallari · February 2, 2019, 7:25pm

Maybe not with OH, but what zwave device are you using?

sihui · February 2, 2019, 7:36pm

I do see this sometimes too, but did not dig deeper yet to find the cause …

toffyrn · February 6, 2019, 10:27pm

I see this too, using aeotec zstick gen5. Has 46 of these so far this month. Some of them come from node-numbers that actually were used earlier, some of the warnings come from completely unused node numbers, and a couple times this has come from node 0.

Not yet observed any issue except from the log warning.

lsiepel · July 30, 2019, 11:46am

I experience the exact same issue:

2019-07-30 13:11:15.996 [WARN ] [nal.protocol.ZWaveTransactionManager] - NODE 6: Not initialized (ie node unknown), ignoring message.
2019-07-30 13:11:16.997 [WARN ] [nal.protocol.ZWaveTransactionManager] - NODE 6: Not initialized (ie node unknown), ignoring message.
2019-07-30 13:11:25.997 [WARN ] [nal.protocol.ZWaveTransactionManager] - NODE 6: Not initialized (ie node unknown), ignoring message.
2019-07-30 13:11:26.998 [WARN ] [nal.protocol.ZWaveTransactionManager] - NODE 6: Not initialized (ie node unknown), ignoring message.

I can’t find any reference to this node 6. It is not in the inbox (i also checked the hidden items), it is not in any .thngs or .rules .items file.

Could it be a partially removed assocation? The node still sends messages to the controller and the controller does not have this Association anymore? And everytime the node sends a message to the controller. the controler throws this warning? It is just a guess, but if so, it would be cool if the binding would be more explicit in what is going on. “…ignoring message from NODE 6.”

Edit: using openHAB 2.5.0 Build #1641

chris · July 31, 2019, 5:24pm

This is already quite explicit. It means that there was a message received, from node 6, and that node 6 is not known in the system. The message is therefore ignored.

This normally happens when you have previously had a device in the network, and you have since reset the controller, but the device is still sending out periodically messages as it was never removed from the network.

lsiepel · July 31, 2019, 5:52pm

The developer of the binding might find it explicit. For me (as end user) I was like what node? what message? It would be really helpfull if it was changed to:

NODE 6: Not initialized (ie node unknown to controller), ignoring message originating from this node.

This normally happens when you have previously had a device in the network, and you have since reset the controller, but the device is still sending out periodically messages as it was never removed from the network.

It was exactly that.

chris · July 31, 2019, 5:56pm

I personally don’t think this helps. It should be obvious that the node is not known to the binding (it is a binding logfile after all), and it should be reasonably obvious that it’s this message that is being ignored, since this is what is being logged about.

We can’t write a book in log messages, so I think you would still have asked the same question if we had added the extra 4 or so words here

Anyway, I hope my answer was helpful to you in understanding the issue.

lsiepel · July 31, 2019, 6:03pm

Well your post helped, thanks! I’m sure that i could have come to the same conclusion if the error was more clear to me, but i allready made that point.

afjk · November 15, 2019, 6:23am

thanks for the explanation, @chris - it explains well the messages of old nodes that were not removed.

But how can ist explain completely unexisting nodes? for example, my highest ever connected node is i the 80s, but I am getting spammed with messages from nodes that never existed:

ZW 14-Nov-2019 15:40:11 [WARN ] [ng.zwave.internal.protocol.ZWaveTransactionManager] NODE 172: Not initialized (ie node unknown), ignoring message.

ZW 14-Nov-2019 15:40:11 [WARN ] [ng.zwave.internal.protocol.ZWaveTransactionManager] NODE 172: Not initialized (ie node unknown), ignoring message.

ZW 14-Nov-2019 21:12:24 [WARN ] [ng.zwave.internal.protocol.ZWaveTransactionManager] NODE 108: Not initialized (ie node unknown), ignoring message.

ZW 14-Nov-2019 21:12:24 [WARN ] [ng.zwave.internal.protocol.ZWaveTransactionManager] NODE 108: Not initialized (ie node unknown), ignoring message.

ZW 14-Nov-2019 21:12:24 [WARN ] [ng.zwave.internal.protocol.ZWaveTransactionManager] NODE 108: Not initialized (ie node unknown), ignoring message.

ZW 14-Nov-2019 21:12:24 [WARN ] [ng.zwave.internal.protocol.ZWaveTransactionManager] NODE 108: Not initialized (ie node unknown), ignoring message.

ZW 14-Nov-2019 21:12:24 [WARN ] [ng.zwave.internal.protocol.ZWaveTransactionManager] NODE 108: Not initialized (ie node unknown), ignoring message.

ZW 14-Nov-2019 21:12:24 [WARN ] [ng.zwave.internal.protocol.ZWaveTransactionManager] NODE 108: Not initialized (ie node unknown), ignoring message.

ZW 14-Nov-2019 21:12:24 [WARN ] [ng.zwave.internal.protocol.ZWaveTransactionManager] NODE 108: Not initialized (ie node unknown), ignoring message.

ZW 14-Nov-2019 21:12:24 [WARN ] [ng.zwave.internal.protocol.ZWaveTransactionManager] NODE 108: Not initialized (ie node unknown), ignoring message.

ZW 14-Nov-2019 21:12:24 [WARN ] [ng.zwave.internal.protocol.ZWaveTransactionManager] NODE 108: Not initialized (ie node unknown), ignoring message.

ZW 14-Nov-2019 21:12:24 [WARN ] [ng.zwave.internal.protocol.ZWaveTransactionManager] NODE 108: Not initialized (ie node unknown), ignoring message.

ZW 14-Nov-2019 21:12:24 [WARN ] [ng.zwave.internal.protocol.ZWaveTransactionManager] NODE 108: Not initialized (ie node unknown), ignoring message.

ZW 14-Nov-2019 21:12:24 [WARN ] [ng.zwave.internal.protocol.ZWaveTransactionManager] NODE 108: Not initialized (ie node unknown), ignoring message.

ZW 14-Nov-2019 22:22:29 [WARN ] [ng.zwave.internal.protocol.ZWaveTransactionManager] NODE 67: Not initialized (ie node unknown), ignoring message.

ZW 15-Nov-2019 06:28:11 [WARN ] [ng.zwave.internal.protocol.ZWaveTransactionManager] NODE 99: Not initialized (ie node unknown), ignoring message.

ZW 15-Nov-2019 06:28:12 [WARN ] [ng.zwave.internal.protocol.ZWaveTransactionManager] NODE 99: Not initialized (ie node unknown), ignoring message.

ZW 15-Nov-2019 06:28:13 [WARN ] [ng.zwave.internal.protocol.ZWaveTransactionManager] NODE 99: Not initialized (ie node unknown), ignoring message.

I am on a Raspberry 4 on OH 2.5.0M4 and a Zwave.me Stick

ffr · July 31, 2020, 6:56pm

@chris: is there a way to reinstate such a node back into openhab / the Controller without ging through factory reset and new inclusion? - I have one of those, a battery device that was originally very hard to include. I accidently removed it from the Controller and since then it continues to send messages but the Controller does not know the device anymore.

Bruce_Osborne · July 31, 2020, 7:14pm

You have 2 options.

Factory Reset the device
Place the controller in Exclusion mode & exclude it. Any controller can exclude any Z-Wave device, even from a different network.

chris · July 31, 2020, 7:43pm

Unfortunately if you remove it from the controller, there’s no way back and you’ll need to re-include it again.

Bruce_Osborne · July 31, 2020, 8:02pm

True, but the device needs to realize is has been excluded first, correct? A device will only be included into one network at a time

chris · July 31, 2020, 8:50pm

Yes, it will need resetting or excluding first otherwise you can’t include it.

sercasyr · June 23, 2021, 8:18pm

Hi, I have similar messages, but with two important differences:

I get those “NODE xx: Not initialized (ie node unknown), ignoring message” messages from nodes whose id is indeed in the system (and I haven’t reset the controller since I installed it).
I also get those messages from nodes whose id is way higher than my highest z-wave device. For instance: node 138, node 40 (the highest id in my system is 30).

My Z-Wave binding is completely unstable (I have sensor reporting impossible values such as -32768 luxes) and unresponsive (some nodes don’t respond to my commands) right now, so I guess this may be the problem (or the manifestation of the problem).

Any ideas?

chris · June 24, 2021, 12:19am

It sounds like there are corrupted messages being received. The ZWave error checking capability just uses a simple checksum so is not very robust to errors in flight. This is the usual cause of the “node unknown” messages.

Normally these are caused by errors on the RF link, but it could also be an issue with your USB/serial ports and the computer communication.

Newer devices can use a CRC encapsulation to resolve this, but it’s not super common.

sercasyr · June 24, 2021, 7:17am

Hi, I have managed to solved some of my problems. It seems (at least this is what I think after testing multiple combinations) that the system was too busy (too many rules executing too often). The Z-Wave binding seems responsive now, but there is one node (a brand new Aeotec Multisensor 6 ZW-100C) that reports -32768 luxes for the illuminance sensor all the time.

This is something that from time to time happens in my openHAB system, but it is usually one crazy value and it usually goes to the right value quickly. This is quite annoying since it ruins all my graphs.
However, this time is different, since the -32768 is permanent.

I don’t know what to do to make it report the right value. It was working a few days ago, so I don’t think the device is broken.

chris · June 24, 2021, 7:36am

These problems are caused by either the device sending invalid data, or data getting corrupted in flight. I’ve analysed many logs from lots of people and this is always the case. Unfortunately there’s not a lot that can be done to resolve this other than to add a rule to filter this out.

sercasyr · June 24, 2021, 8:09am

The weird part is that this time is not just a single wrong value.
It keeps sending the -32768 value all the time. It may be the case that the device is sending invalid data, but it was working 2 days ago and I didn’t even touch it, so it is hard to believe it is broken. It is working on mains power supply and it is fairly close to the controller (5 meters away). I bet there is some software problem going on (on either side of the communication protocol).

Can I do something to kind-of-reset the device without having to exclude-include it again?