-
|
Originally reported in kinu-garage/hut_10sqft#680 (comment) A day ago I included I re-included many times. Also excluded + factory-reset the device (and power it off, rest it for awhile). Nothing seems to be working. Related or not: Through this Z-Wave node, I'm supposed to be able to send a signal to open/close a garage, but nothing happens. I'm not sure if the issue is related. Env:
A bit more verbose log from Thanks for the help. |
Beta Was this translation helpful? Give feedback.
Replies: 3 comments 9 replies
-
|
Thank you @AlCalzone for the instruction at kinu-garage/hut_10sqft#680 (comment). Here's the log file zwavejs_2022-06-13.log.gz where I switched the log level to 'silly', then re-interviewed the node in question, which completed with green, then set the log level back to verbose. Some log lines copied for my logging purpose. |
Beta Was this translation helpful? Give feedback.
-
|
There are two things going on here:
So for a solution I suggest:
|
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the detail.
I tried making the Z-Wave hub far closer to the device in question, using 5 meter USB extension. No improvement, on zwavejs, I still see timed outs. I'll post |
Beta Was this translation helpful? Give feedback.
-
|
Did you heal the node after moving things around? |
Beta Was this translation helpful? Give feedback.
-
I think I've followed Connectivity issues -> General troubleshooting fairly thoroughly. Only thing I haven't done is to keep away potential RF interference (as the RPi the USB Z-Wave hub eventually plugs into) is in the middle layer on the RPi rack (on that RPi rack, other RPis are not as active as the one in question). log (taken with On zwavejs' Control Panel, "Statistics" shows that "Timeout Response" keeps increasing upon re-interview. It seems to add roughly 11 per successful completion of re-interviewing the device in question.
"Statistics"
Yes.
I found a health check feature from |
Beta Was this translation helpful? Give feedback.
-
|
Regarding your log:
Click node 53, click health check, select node 1 as the target, start. Post the results. |
Beta Was this translation helpful? Give feedback.
-
|
Oops sorry. Here it is
Sorry, I didn't know you wanted the box to be checked every time. This time as I mentioned above I did it I think. No idea about security keys configuration. On inclusion of z-wave devices I've never been instructed to do so, but if it's needed (requirement from the Z-Wave Hub I use? Zwavejs?) I can try. |
Beta Was this translation helpful? Give feedback.
-
|
Ok that is a terrible connection. The problem seems to be one-directional though. The controller can ping the node just fine and it receives all the acknowledgements in a somewhat reasonable timeframe, but the node does not get any acknowledgement when pinging the controller. Since the acknowledgements are rather short messages, they can easily get lost in some noise. The directionality of this makes it likely that the controller's ACKs cannot be "heard" by the node due to noise or interference near the node itself. Aside from that, you don't have any security keys configured, but the node is still included securely: Since this is a garage door controller, it requires encryption to do anything, which isn't possible if you haven't set any keys. You'll have to
Then you should at least be able to control it. |
Beta Was this translation helpful? Give feedback.
-
|
Thank so much @AlCalzone, now I resolved! Steps I took:
I am now operate this Z-Wave node in question (via HASS).
Thanks for analysis. I am not yet sure what to do about this just yet due to my lack of knowledge about (maybe) general Z-Wave network configuration. Is this poor network connectivity worrysome? Is it going to cause critical connection issue? In retrospectAnyways, I'm moving forward. To sum up what I learned, what was not right were:
*1...Btw this text read like a link to help. I didn't know this link goes to a page where a user gets to configure the inclusion. |
Beta Was this translation helpful? Give feedback.
-
I guess that did the job in your case, but FYI in HA you can also do the "normal" way of excluding a device. Somewhere on the integration page you'll find a button "Exclude device", click it, then push the button on the device.
It can, and it is (at least partially) the source of larger problems here: The device not being able to ping the controller might not be that big of a deal, but the max. latency over 10 seconds in the first round of checks is. You might want to try adding another powered device between the controller and node 53, then heal node 53 so it hopefully picks up the new repeater. |
Beta Was this translation helpful? Give feedback.
-
Which I coincidentally already did after I posted my comment above. Currently I still don't see node 53 picked up the "new" powered device in b/w the hub even after the full heal of the entire network (triggered on HASS) though, this can be a separate topic I may open a new question later. Thanks again @AlCalzone |
Beta Was this translation helpful? Give feedback.
-
|
One more thing, I somehow missed this earlier: S0 needs to exchange three messages every time a message should be sent, so 3x the possibility for failures and delays. S2 doesn't have this downside, but a few upsides. |
Beta Was this translation helpful? Give feedback.
Ok that is a terrible connection. The problem seems to be one-directional though. The controller can ping the node just fine and it receives all the acknowledgements in a somewhat reasonable timeframe, but the node does not get any acknowledgement when pinging the controller.
Since the acknowledgements are rather short messages, they can easily get lost in some noise. The directionality of this makes it likely that the controller's ACKs cannot be "heard" by the node due to noise or interference near the node itself.
Aside from that, you don't have any security keys configured, but the node is still included securely: