Hello there,
is there anyone else experiencing the “cross-talk” communication between two smart homes standing nearby each other?
My Z-Wave Serial Controller is reporting unknown nodes 7, 8 and 9 for some time. My Z-Wave network is small, my newest device is node 12 (including those 3 unknown). So know perfectly all my devices and their numbers. These 3 strangerd did no harm to my network, so I did not pay attentio to them so far. But I’ve noticed another weird behavior today. One of my thermostats reported unknown colors today 
as you may guess, this device never heard about colors untill now. The same thermostat reported the power consumption of 104857.6 Wh for a few seconds today. Which is also nonsens. And I’m receiving messagess from unknown nodes 139, 75 and 29. Seems like some of my neighbours bought a lot of z-wave RGB lights (maybe a some turnkey solution) or deployed some Z-Wave network “repeater” which get his and my network into the range of each other.
Is that possible? Obviously it is.
Is there any solution? My nine devices against at least 140 nodes of someone else. If I somehow find who is my “Nemesis” and the only solution will be to drop one of the networks, then it is rather my tiny little Z-Wave network that can be “easily and at lower cost” replaced. Which I would like to avoid after 18 months of building and fine-tuning my smart heating.
I’ve upgraded to OH 2.5 recently, but the unknown nodes were in my inbox before the OH upgrade, so I do expect it is not related to this change.
Hmm. First: Don’t panic 
I don’t think your neighbours all of a sudden bought that many devices
(not every consecutive ID is in use). It’s also not impossible either that it was a high tech burglar or hacker fuzzy testing his environment (to include your house) but I believe it’s neither of these.
Those IDs you see are rather arbitrary numbers and I believe it’s just RF trash. Some devices to use the same frequency Z-Wave runs on (such as some mobile phone frequencies)were added by you or someone nearby, causing interferences.
This happens to me at times, too, causing all sorts of source node ID presumably talking to my controller, but effectively sending non-decodeable data (sometimes it is decodeable, resulting in e.g. your thermostat seeing colors).
Note that your neighbours cannot simply talk to your nodes as they need to be known on your controller (that happens when you include them). And any node knows its controller’s ID it was included with.
Use habmin to visualize your network. See if there’s any node that were included by accident.
Your controller may or may not see messages meant for other controllers. Run zwave debug level logging to find out. You can use chris’ ZWave Log Viewer to decode your log.
It is far more likely those are “zombie” nodes. The network is stored on the controller and sometimes when excluding a device, it stays defined ion the controller. I do not think it is possible to have neighbor devices on your network.
I will tag this thread as z-wave and, hopefully, Chris will have some good, sage advice on how easiest to deal with the situation.
Zombie nodes can cause network routing issues as other devices try to route through them to get to the controller.
Both of the two above ideas are plausible. Given there are so many nodes showing up, probably something along the lines of what @mstormi says is more likely.
ZWave ha a pretty poor error detection system and it is pretty easy for corrupt messages to pass through the error checks. So, I suspect that these are real ZWave communication packets coming in from some node somewhere in your network, but they have become corrupted. This is not overly uncommon.
Newer ZWave devices get around this by using a secondary encapsulation class to improve the error detection, however even that won’t stop this issue as this error detection is inside the original frames, so if the node ID is getting messed up, then it won’t be rejected until after it goes through the initial checks in the binding and you will still see strange nodes being logged.
If it was consistently a smaller number of nodes, then the other common reason is devices that are still in the network, but unknown by the controller. This happens when the controller is reset, but the devices are not re-included into the controller after the reset. I don’t think this is so likely in your case since you have 140 nodes.
Their network is small. It is possible the neighbor has a large network.
But as already pointed out, the controller will not pass through packets from another network. So unless the HomeIDs of the two networks are the same, which is extremely unlikely as it’s a 24 bit random number (from memory) then this can’t happen. We’re therefore limited to -:
- nodes that have been previously connected to the controller so that they are using the same HomeID (and having 140 nodes that you’ve forgotten to re-include is unlikely I think)
- corrupted packets, and this definitely happens and will result in random node IDs - ultimately covering all 232 nodes.
- hacking (pretty unlikely) - someone could be generating data with the same home ID.
Thank you all for the useful advices. I’m happy that I’m not connected to anyone else’s network.
I searched this forum for zombie nodes and found some threads. Now I’m trying to wipe the nodes 7-9 which are still popping up in my inbox by marking these nodes as failed. No success yet, but I will dive into the forum and try to find solution.
The second issue would be probably caused by the corrupted packets as mentioned by @chris. I’ll set my logs to debug level and check is too. What seems to me weird is that I’ve received several messages from node 139 over the time (and a few others) and they are repeating, so it does not look like some random noise. I’m also repeatedly receiving confusing messages from that one particular qubino thermostat since yesterday. Once again thanks for the tips where to look for the problems and I’m starting the investigation 
If you can shut down OH and connect the controller to a Windows box. Zensys Tools can clear them from the controller.
This is what I said - they are corrupted commands - not noise.
So this means that (for example) if there was a double error in a message from node 11, then this could easily show up as node 139 (ID11 = 0x0B, ID139 = 0x8B - 1 bit has changed). There needs to be another bit change somewhere else, and the error detection system is bypassed and the command will be received as a valid command from node 139.
Dear Bruce, I’m afraid this is not possible as I’m using the RaZberry daughter board and not the USB stick. Sorry I didn’t mention it earlier.
Z-Way can do it as well.