Fair enough.
You are the one with the access to the source code and more in-depth knowledge of the system. I would love to have greater insight into your statements. I understand you are likely very busy so hopefully this is something you can shed more light on. I'm all ears and listening.
If this forum isn't the appropriate place then I'm happy to receive either private messages or emails.
You can go look at any of the user made drivers, though, if you want. While they may not be identical to the ones you are using on your devices, the structure would be the same.
It would be quite odd for a device driver to publish an event for a command that it does not support. Often I'll throw a debug message in my drivers if I receive a command I wasn't expecting, but that';s about it.
That said, when you are talking binary reports and notification reports, those types are often present/supported on a wide variety of drivers. So if somehow, some way I can't think of a reproducible scenario for, a binary or notification report got sent the wrong driver it may indeed make an event.
I'll say I have never seen this happen in Hubitat though. Not saying it is impossible, just that I've never seen it.
I want to add to this something I noticed when I switched the garage door driver from the generic contact sensor to the Dome Leak Sensor. It appears that the garage door device fires off two messages when it opens and closes. This could be because the internal ball sensor bounces. I had forgotten that I turned on "Suppress duplicate contact events?" in the contact driver. So it is entirely possible that this sensor sent two independent messages of which one got corrupted somewhere along the way.
Maybe. There is really no way to proceed with understanding anything without packet sniffing logs.
We can all speculate all we want, but until there is proof of the packets it is all speculation and the conversation can't really move forward, as nothing can be proven one way or the other. 
That might not be what you want to hear, but I think it is an "it is what it is" in terms of next steps.
With regards to reproducing. Is it possible to setup a fake z-wave node on the network that is not an actual device but if messages were malformed via the node id that would still receive them? Since these devices are normally sleepy I wouldn't imagine it would interfere with routing?
I think I know how to set things up again that would create something that is reproducible eventually. It would be nice to basically take out one of the factors of the equation. In this instance take out the physical leak sensor but still have something in Hubitat that could receive the failed messages. I could then setup an alert that doesn't actually turn off my water and then hopefully have a sniffer listening at the same time. It would be great if I could have a sniffer that just connected to a raspberry pi recording frames to the filesystem. I'm still researching this part.
If you or @mike.maxwell have any thoughts on any of this it would be appreciated.
For a zwave sniffer just fetch the zniffer software from silabs and run it on a Windows pc.
@mike.maxwell Is there a way to request the next inclusion to start at a particular empty node id? Or is the only way to do that is include and exclude about 200 times?
Correct, the radio firmware assigns the node id, you can't change it.
It really isn't anything to be concerned about.
I appreciate the answer. However, let me decide what I should or should not be concerned about. I am trying to achieve a goal. Achieving that goal was the reason for the question. The answer as you stated is no there isn't a way to do that. You will have to include and exclude many times to achieve your goal.
Fair enough.
I believe his point was that the ID does not matter technically, gaps between IDs do not matter technically, and it can be safely ignored from a technical standpoint. Which is all 100% correct, of course.
If you choose to try and do something with IDs (like lining them up or changing a device to a specific ID), obviously that is your choice, and would require repeated pairing/unpairing to achieve.
Good luck.
From the standpoint of the network, a node could be missing for many reasons: a failed repeater on the route to the now-stranded nodes, or a dead battery, or a discarded device, etc. Some of the disappearances are temporary, some are permanent, some are extremely brief and transient. The network has no way to know. Grave disorder would occur if two devices had the same node ID. The present system of not re-using node IDs seems like a reasonable engineering decision, and allows nodes to reappear.
Download the Hubitat app
