[My experience is decent: going X10 -> Insteon -> ZWave/Hubitat (bad driver for my Qubino DIN dimmers) -> SmartThings (which I hate with a vengeance, but it did support the Qubinos, although badly) -> and now back to Hubitat C5 again, since Qubino drivers are available. I have very little experience of actual automation in Hubitat though.]
So, after all the above, I can now finally, for the first time since ripping out Insteon and replacing with ZWave three years ago, start to do some basic automation.
But I have consistent problems with devices not responding every now and then, mainly when they are grouped. Once every hundred or so for individual devices, but with a group of 20+ devices, there is almost always at least one that is not responding. I know that there are things you can do mitigate the issues, and I am on that path as well, but I just have to ask a very basic question indeed:
AREN'T Z-WAVE PLUS SUPPOSED TO BE BI-DIRECTIONAL? If so, how come the hub does not listen for a reply and send a repeated command if there's no reply? That would be the whole idea of a bi-directional protocol, right? [All my Z-Wave devices are Z-Wave Plus. Additionally I have 1 (one) Zigbee button.]
I have seen a screenshot from what I assume to be the C7 version of the UI with a Z-Wave Plus logo, which my corresponding C5 page does not have (and it's missing a lot of other useful stuff as well). Would my problems thus be solved with a C7?
Wow. That was a...hefty...thread! Just browsing it so far, and most of it seems to be not only above my paygrade/skill level, but also about the 700 series of ZWave chips. Which are in the C7 but not in my C5 if I understand it correctly?
And it would be nice to get back to a more basic level: isn't the protocol bi-directional? And doesn't the drivers/firmware check for an ACK that the command has been received and retries otherwise? It seems like the most basic of basic functionality that I am flabbergasted if it's not there...
Although the technical terminology is inaccurate, the gist is correct. The firmware on the ZWave Radio SOC handles the protocol of retries and ACK. Take a simple example... The ZWave Radio SOC gets a command to send a 255 to a specific Node ID.
The Radio waits for dead air and then sends the command... and the decision tree expands rapidly here. The connection Might be Direct, or it Might be through routers. The Radio knows. It's a source routing protocol so the source (the radio) has a route table, or enough of one to pick a route. It either sends the command within a Singlecast or a Routed packet format. Singlecast is a few bytes smaller, a Routed packet has slots for 4 hops that might be in the route.
In that screencap, the ZWave device is wanting to make a report (luminance), using Singlecast, and the Hub ACKs it and the device sends a 2nd report (UV) which the Hub also ACKs.
In this next screencap, the ZWave device sends a Routed message that has to hop though two repeaters. Each hop ACKs and then a final ACK of the device answering the message first hop repeater.
As you can see, packets flow in each direction, that's bidirectional in your terminology, right? (Because it's not in my terminology.) The Hub and a Device have a unidirectional conversation, packets in both directions, initiated by one end or the other. It's the initiation of a conversation that defines the direction.
Think about a ultra simple Door Sensor... it has one job to do, tell the Hub that a contact is open or closed. Possibly it will send a battery level message, but has no need to ever receive a message initiated by the Hub.
A Switch (or Dimmer) are usually able to both initiate a message (flipped the switch) as well as accept messages initiated by the hub.
In that case, just as you suggest, the hub initiates a message with a command to turn on (or off) the switch, which the device ACKs. The device then initiates a message to say the switch is on (or off). Hubitat does not indicate a switch result until it gets the message back. Note that from the switch's viewpoint, it sends a message back to the hub saying the switch is on, independent of it being a human flipping the physical switch or the hub telling it to.
As I said, you have the gist of it but there's a lot of detail that. you (and I) are skipping over. The problem, in my reading, is that you have devices that are having difficulty communicating, NOT that the protocol is mishandled.
If the hub sends an OFF to 20 devices and only 18 of them hear it with no errors, then there will be 18 responses.. and some of those may not get heard. It's why we focus on the ZWave Details page in so much of our advice. The information found there can have clues to the robustness of your mesh. You can see rows of good:
Thanks for the reply. I'm sure I will have more followup questions, but I want to start with the screenshots. I have nowhere near that level of detail in my Z-Wave details. Is that because I have C5 and not C7?
Right... C& has a different layout because of the 700 series chip. The c5 has the 500 series so doesn't have the same sdk. Is that your only z-wave device or do you have more? If more can you post the entire z-wave details page?
One thing I will also recommend is that except for locks and garage door stuff, everything should be paired with NO security.
Post your z-wave details page (in you can break it up) settings>>z-wave details. This will have all the stats, class, security, and route info in it...
A bit off topic this, sorry. Am I imagining something or did the C7 Z Wave details page previously show the in/out clusters and other info? I had an issue yesterday and it wasn't until I went into the specific device and scrolled to the bottom of the page that I could see the cluster info was missing (the device was operating fine but I excluded and re included it just to safe) I could swear it used to be on the Z wave Details page.
On the c7 the clusters are shown on the physical device page. In z-wave details doesn't have that. Vs @phjalmarsson z-wave settings page that shows the in/out clusters
Well, that was a lovely discussion while I was gone. Now, can we get back to my issue? So, since I am on c5 and not c7, what can I do? Situation is the same a week later, so the "settling period" that some people talk about should be over, right? I was very careful while pairing all devices, even pairing the buttons in their right position, so it shouldn't be that (also, the hubitat is in the middle of my apartment, and all devices are closer than 6m, so they should get direct contact anyhow, or?
What is the best next step?
Rebuilding the ZWave Mesh?
Removing devices one at a time? I really don't like that, beacuse the DIN rail dimmers that makes up the majority of my mesh are a pain to exclude/include.
Buy a C7 just to get better debigging info? Honestly I don't mind the cost (it's peanuts compared to the cost of my time...), but rebuilding the network again... Migrating it (there's some tool available?) while things are not working does not make sense.
Finding a software solution? Is there anything that just keeps banging on devices until it gets a reply back? Something similar to the AllOff App (which almost solves my turn off all lights issue for me, but does nothing for scenes and groups) but for scenes and groups?