lol, my wife saw what normal contact sensors looked like and said their were too big and ugly. Tbh, I see her point, the recessed ones look much better hidden inside the door.
I've been running a lot of z-wave devices for years on C7, C8, now C8Ps. My z-wave & zigbee devices are on one C8P (and it has very few rules, etc.) and all my automations and most other rules, apps, etc. are on another C8P.
I've not had much issue with sensors reporting during "quiet" times. However, I've long seen issues that tend to crop up when the hub is very busy--such as when I come home and want a bunch of lights turned on, etc.
The "Command Retry" logic was a game changer for SETTING devices, especially during "busy" times. It now is almost 100% at getting devices properly set (vs. 80-90% before).
Prior to that, Bryan Copeland did a lot of work with the S2 protocol--and using that seems to be more reliable (e.g., on the Ring Door Contacts, etc.).
However, I def. see indications that it is NOT always receiving the expected "I'm now set" acks from the devices--mostly when a lot is going on. Specifically, with the "Command Retry" enabled, I'll see it "retrying" devices that have successfully been set multiple times and even claiming to have "failed" after 5 retries despite the device actually being properly set. Saying this, Command Retry IS amazing -- but that great feature is completely irrelevant when it comes to random packets being sent from the device to the hub (like the op's sensor change packets) since "Command Retry" only applies to packets sent by the hub to a device.
Also, some devices (especially locks but sometimes lights as well) don't show their updated state after they are set (although they sometimes catch up after several minutes).
This would corroborate some sort of issue with the hub missing incoming packets--but it's almost always (except with locks) during times when there's a lot of z-wave traffic. I don't seem to notice missing packets when it's just a few things happening (which supports trying to dial down "chatty" devices so they aren't sending updates so often).
As a side note: I've long suspected that missing ACKs might be the reason some of my devices take circuitous routes despite easily being near enough to the hub to connect directly (my house is pretty small--everything should be able to connect directly). My suspicion is that the hub/device sends a command, misses getting the expected ACK, so it tries routing through other device(s)--eventually getting there after routing through several devices all over my house. The C8 helped with that (far fewer routing issues--but there are still a few odd ones that go from a device near the hub to the far side of the house and all around 
).
It would be interesting to hear from someone who's got a lot of nitty gritty z-wave protocol experience.
1 Like
It definitely is, I only turn it on for devices that need 100% reliability, eg door locks. Otherwise, you could create more zwave traffic and result in issues that didn’t exist before.
1 Like
The bonus with command retry is that it only retries devices that it doesn't get a response to.
I never really knew which lights might not work before, so I had to force-activate the entire room lighting group several times (thus sending a torrent of activity over and over). Enabling command retry means that far less activity is generated. And, all the lights now get properly set.
Now, I might see a handful retry. And just a few that claim to have failed--but, almost always, that's a false alert (the device did change, but the hub didn't get the message). All in all, I think that's the most impactful (positive) change in years. I love it! 
2 Likes
This is a frequent occurrence with locks here.
2 Likes
It looks like too many radios are in a very small space. Rf interference is almost guaranteed.
The radios on the secondary hub are disabled, and zwave uses 900Mhz, every other radio near my hubs uses 2.4 GHz or 5 GHz.
I forgot which radio even being disabled is in fact still active. The termination caps could be used instead of antennas for the disabled radios. This definitely will guarantee absence of rf activities. Do not simply remove antennas. Unterminated ports could be damaging to radios.
You are over thinking the issue, since changing the power reporting and replacing one of my door sensors which had low signal strength, with a 700 series version, the issues have gone away.
This suggests to me that my Hubitat hub was being overwhelmed by zwave power traffic and missing events as a result.
Whether it not it was the CPU being busy and the zwave buffer overflowing, I’m not sure.
2 Likes
I am happy to hear your problem is gone. But rf interference is never helpful. According to your picture the rf environment in your setup is far from perfect and who knows what impact it imposing on overall performance.
Zwave is a relatively slow (100 kbps max) serial protocol. If I had to guess, missing z-wave events are not due to a CPU limitation.
Zwave is 900 MHz, I only have one active Zwave radio and a high quality antenna attached, where is this interference coming from?
I’d have agreed with you, if it wasn’t for the fact that it was much worse a few months ago when I had Home Assistant integrated on my primary hub and the maker API was being slammed. I never missed any Zigbee events, but It was missing zwave events.
I’ve also been told by Hubitat staff, that Zigbee has higher CPU priority than zwave. 
This is a mesh failure, not a hub problem. It's not difficult to overwhelm the Z-Wave mesh, and it drops messages. It is caused by too much traffic. Frankly, Z-Wave is not a very robust protocol, and it has lots of cracks and issues. They've been there forever, and probably will be in the future as well (consider why LR is not mesh). Large Z-Wave networks tend to be worse than smaller ones (for obvious reasons). Z-Wave spec says it can address over 200 devices, but this is misleading. Yes, the specification itself supports some number, but in the real world Z-Wave doesn't actually work very well over a much smaller number of devices, and certainly not with many high traffic devices (such as power reporting).
On antennas: In virtually every circumstance the stock antennas will perform better than replacements, such as you have. These other antennas do not increase the radio strength, only change its dispersion and reception shapes. Your antenna could well be amplifying distortions on the reception side, causing what appears as if interference. @vitaliy_kh is correct about proper termination of unused radios being a good idea.
CPU priority of one radio over another is a complete misnomer, and is not relevant to the issues exposed in this topic. There is not a CPU limit being hit, even on a C-5. It's all on the mesh limits, which can't even be discussed in a particularly rigorous manner. RF is squirrelly, every environment is different, and a lot of time is wasted chasing after RF problems.
This topic has run its course, and we will bid adieu to it....
5 Likes
