So I've thought a good deal about this over the past 6 months about what has been happening before I posted a thing about it.
Coincidence? Based on what has happened to me here I have to say no. Let's just take this particular instance and not even think about my previous experiences. What are the chances that (looking at the log posted) within 1 second of the initial Garage Door (0x0C) opened notification that the Crawl Space Leak (0x0E) would report wet, not physically alarm, and not actually be wet? I'd have to guess the chances are fairly slim. I'll also mention that the sensor still reports as wet even though it is dry. Why? Likely it's because it never sent a message reporting itself as wet so it can't send a message reporting itself as dry. Therefore the hub has no reason to believe it is not wet. My guess is the hub is just a state machine stored in a database. It has stored off that this device is wet and until it hears that it is not wet it won’t change. Noticing that this morning I have pressed the refresh button on the leak sensor in hopes that the next time it wakes up the hub will ask it to send an update on its current state.
Let's address the off-by-one and off-by-two of the node id. So thinking about this more I feel this is either some possible software overwriting memory error or hardware memory bit-flip error. In the case of the recent incident it's easy to see how this might have happened. The Garage Door node id (0x0C) is 1100 in binary. The node id value just needs the second least significant bit to flip to become the Crawl Space Leak (0x0E) 1110 in binary. My guess is that the kind of messages these two send out are likely "compatible" with each other. This allows one to be mistaken for the other. The garage door reports open could be mistaken for the leak sensor reports wet. I would be interested to see if the software is keeping track of the notification device in the data structures as it moves through the system. Seems like it would be. And that brings to my mind as I'm typing that maybe this is a bug in the Dome Leak Sensor driver where it is not checking to see that the message is indeed a water alarm message it is being sent. So the software is responding incorrectly to bad inputs wherever or however it may be generated.
Let's be clear I'm not at this point saying that this is happening every day or every other day or even once a week. I'm simply saying that I have seen evidence that this has and is happening and it is disconcerting. It's possible this is happening more than we know. Maybe the bit-flips in your hub don't correspond to a device there. Or if the messages on which this happens are not compatible and the software does the right thing most of the time and ignores them. Or maybe my hub is just in the right place to get hit by a stray cosmic ray more frequently than everyone else causing the bit flips. I realize there are many reasons why this could be happening and I don't have all the answers here. But it seems pretty clear that this is happening at least to me and given some reports I'm pretty sure it's probably happening to others too.
Without seeing the code or the flow of information through the system I can only speculate as to what might be the problem.
The garage door sensor is an Ecolink Z-Wave Plus TILT-ZWAVE2.5-ECO. The leak sensor is a Dome Z-Wave Plus Leak Sensor.
No. I have not modified the node ids ever. That would be silly. I'm aware that during inclusion of a Z-Wave device the hub tells the device the value to set the home id and which value it should have for the node id. Changing those values would, as you are suggesting, mess everything up. Because the device node id wouldn't change. That only happens during inclusion or exclusion.
