@istapeter I mean that I have practically no success ever trying to include a device that is physically far from the controller (and therefore must presumably have its messages repeated via another pre-existing node in the Z-wave mesh network).
@PecosKidd and @mterry63 : if LR is non-mesh, then for devices that support “800 LR” is there an option within Z-Wave JS UI to select whether this particular device I’m trying to include will join the network via standard mesh or LR? I’m slightly concerned because my standard process is to physically move a device close to the controller to include it and then move it to it’s final installation place… so is there a risk that an LR capable device that will ultimately be placed far away (but with a strong chain of intermediate devices to repeat in between) will unintentionally include in a non-mesh way and therefore lack connectivity when moved to its final place?
To get the camera scan function working, be sure to copy the URL from here (Settings/Home Assistant Cloud):
Then log out of the phone companion app and when you log back in, use the URL you copied above for your Home Assistant URL. The URL will be a random bunch of characters because it’s encrypted.
Same boat. Same thoughts.
2 Likes
LR is a direct connection between the controller stick and the device. It does not use the mesh method of intermediate devices to repeat the signal. So initially connecting a device using LR while close to the controller and then moving it to it’s final destination should be fine. In theory though, this should not be necessary with LR devices. You should be able to connect to them just fine in their final destination, since the signal reaches much further.
It’s actually not good practice to connect mesh (ie, not LR) devices close to the controller and then move them. This can cause the mesh to be built inefficiently, with an incorrect map of which devices it should use as repeaters. This might be a source of some of your communications issues and lag.
Have you used the network map feature of the Z-wave JS UI interface to look at how your devices are connected to and communicating with each other?
@PecosKidd Thanks!
Re network map: I’ve tried using the network map but it can become pretty un-useful once you have a lot of devices (everything is drawn on top of everything else…). And again, everything seems surprisingly solid once devices are included . It’s just the inclusion that is a huge pain.
Re LR vs mesh: is there a way within Z-wave JS UI to see whether a given node is connected via mesh or LR? Is this a permanent attribute of the node (the way that security levels are set upon inclusion and do not change until exclusion/re-inclusion) or do compatible devices, e.g., every day try to connect via LR and if that doesn’t work then fall back to mesh? (Most of my nodes are 800LR compatible, but I don’t honestly know what “mode” they are in… if that’s even a well-defined thing.)
Re moving devices in order to include: I’ve just qualitatively had so much more trouble trying to include devices when they are further from the controller. (TONS of timeouts… and the very rare occasion inclusion doesn’t time out, security times out and the device ends up included without S2 security.) Perhaps it’s superstition but I’ve been moving devices to include them, then moving them to their final position… then if there appear to be any problems I’ll rebuild routes for that node. Either way, I’m in the process of a big rollout right now (replacing a bunch of light switches) and afterwards was going to try to see if things seem stable. I’ve read elsewhere (e.g., here) about the importance of doing a global “heal” (which I’m assuming is called “Rebuild Routes” in Z-Wave JS UI?)… but I’ve read elsewhere (e.g., here) that this should generally be avoided. Any advice?
Thanks again to everyone for all of this! Unfortunately the only “introduction to z-wave” style articles I’ve found stop short of some of these more-nuanced issues, so advice in forums like this is incredibly helpful for someone like me who is trying to learn!
@landolfi Thanks! Dumb question though: in order to get the camera working, do I also have to create my own SSL certificate if I’m using Nabu Casa’s Home Assistant Cloud?
Yes - the “Protocol” column shows blue for standard (mesh) connections, and purple for LR connections.
As far as I understand this is a permanent attribute of a node, in that it will not automatically switch or fall back to the other protocol. You could, however, manually exclude a node and then include it again using the alternate protocol if desired.
I have a Aeotec gen5+ stick on an extension cable, using Z-WaveJS-UI. 67;devices connected to it: fFibaro, Aeotec, Shelly, Vesternet, Qubino, no Zooz.
I did have problems with S0 security back in the day. Don’t ever use that, there are ay too many things wrong with that. I have no locks or other things requiring strong security so I use unsecure, but S2 security should be fine too. I do that also because you cannot mix security levels when you use direct associations, which I use a lot.
I seem to remember S2 security requires close proximity for pairing though because it limits send power for inclusion (security reasons).
Z-wave long range requires direct connections to the controller, so i.m.h.o. using mesh gets you longer range.
But anyway, my situation is probably a bit too different, but I never have problems. I always pair in place, it always works at first try. Connections are always stable. So it is definitely not a given that Z-wave is hard. I have way more problems with Zigbee (same number of devices).
Info about Z-Wave Long Range and Mesh from the source:
Thank you again, @PecosKidd
I checked and all of my devices — most of which are 800LR compatible — are connected as Z-wave mesh rather than LR. Is there something I have to — or can — do in the inclusion process to steer between the two?
@mike15 I didn’t and it works fine with just the Nabu Casa URL.
Once you have the ability to scan a QR working, this post has instructions for connecting 800 LR devices using Smart Start.
Update: Z-wave inclusion is still maddeningly unreliable.
I ordered a USB extension cord to separate the dongle from the HA computer. In the meantime, I reoriented the computer to point the dongle towards the device, and I had a blessed ~1hr that things worked beautifully! I was even able to include via “SmartStart”. But then, despite nothing changing, things went back to the way I’ve described above.
A few days later I received the extension cord and relocated the dongle. That honestly hasn’t made any difference. If I leave a device (sitting 6’, clear line-of-sight) in SmartStart overnight, then by morning, if I’m lucky, I have 4 or 5 new artificial dead nodes appearing in my Z-Wave JS UI list. I had one successful inclusion from one device.
I’ve gone back to manual inclusion (vs. Smart Start) and about 1 out of 5 times it will include… but without security (which is maddening because I selected “Force Security”), so I have to exclude and then start all over.
This is seriously unreliable technology – or pretty blameworthy user error if I’m doing something wrong 
. Would again appreciate any advice!
1 Like
Yeah this is super frustrating. I’m this close to deciding that “Z-wave” is a sham “technology.” I’ve been trying for literally hours to include another lightswitch that an electrician will be installing tomorrow (too far from the controller to communicate without a hop, therefore needs to be included beforehand). I’m literally holding a top-of-the-line 800LR switch 18 inches from a top-of-the-line 800LR dongle made by the same company, and forcing security and the trashy thing keeps including fake node after fake node (without S2 security despite “forcing”), running up my node count and accomplishing nothing.
Please please please tell me I’m making some boneheaded mistake here… because otherwise, z-wave is complete garbage.
Sorry for how frustrating that must be! That is definitely not the normal experience. Something about your environment must be non-typical.
Could you possibly be running both Zwave JS and Zwave JS UI at the same time? From Settings → Add Ons, make sure ZWave JS is either not present, or is stopped.
1 Like
Thanks. in Settings → Add Ons I only see are Z-wave JS UI (plus a few other unrelated add-ons).
Ok. One thing ruled out then.
Next possibility to explore is whether you have a bad device that is flooding the Zwave network. To check this, look at the log (Settings → System → Logs → Z-Wave JS UI [blue, upper right]). Are there any error messages, or devices (Nodes) that seem to be filling the log / constantly reporting? If so, try physically disabling that device (unplugging it, removing its battery, or temporarily throwing the circuit breaker it’s on) and see if the log and your communications works better…
(Thanks again for the help here!)
I went to Home Assistant settings (note: not Z-wave JS UI settings), then system, then logs and switched to Z-wave JS UI. The resulting log file only seems to show logs from the past 3-4 minutes. Is there a way to get longer history? (Otherwise, I’m just refreshing every couple of minutes to get a quick scan of what seems to be happening…)
That said, I do periodically get the message “dropping message with invalid payload”… though it’s not all the time… but sometimes 10-20x /minute.
And about once every 30 sec there is a message of the form “APP: GET /health/zwave 301 1.680 ms - 191” (with slightly differing numbers of ms… sometimes as high as ~2.3)
Other than that most of the activity looks as-expected. I have a handful of Z-wave sensors that update values every 30-60 seconds (e.g., power plugs reporting wattage, or sensors reporting temperature/motion). What’s a reasonable number of “value updated” entries to see per minute in a healthy, unsaturated network?
Thanks!
The “dropping message with invalid payload” might be an clue. If that is always from the same Node, you could consider removing the device with that Node and seeing if things improve.
My “APP: Get /health/zwave” messages are typically 0.3 or 0.4 ms, so your 1.6 or higher sure seems to indicate that things are not communicating well. But whether 1.6 represents an actual problem is beyond my technical skill level. Hopefully someone who knows these details better can chime in.
Something else to look at is the Network Graph on the Z-Wave JS UI tab. That might help identify any particular devices that are communicating poorly. Could you post a screen shot of the graph?
The “Dropping message with invalid payload” does not reference a Node number. It just says the time, then “DRIVER Dropping message with invalid payload”.
Separately I did notice a sequence “the controller is jammed” / “Controller status: Controller is unable to transmit” / “The controller is no longer jammed” / “Controller status: Controller is Ready”. (over the span of about 2 seconds). This seems to happen ~ every 5ish minutes.