Z-Wave JS and Z-Wave JS UI

Configuration Z-Wave
1

I read that Z-Wave JS and Z-Wave JS UI should not be used together. Is this correct?

I thought that Z-Wave JS UI is based on JS but with enhancements and GUI. I discovered that Z-Wave JS is superior in at least two ways: 1) JS detects the USB Z-Wave stick (Silicon Labs 700) where JS UI did not, and 2) JS was able to pull the keys from the stick where JS UI did not. I was hoping that JS UI was just as capable as JS, but it was not my experience. Am I missing something?

Also, can JS and JS UI coexist and interoperate? Their names contribute to the confusion.

Lastly, if I wanted to use JS UI, how do I connect the Z-Wave integration to JS UI? As I understand it, the integration is designed to be used with JS?

I’d appreciate any insight.

2

You can find the “official” instructions on how to migrate to UI here, please follow them closely:

2 Likes
3

Yes. Do not use together.
Zwavejsui bundles zwavejs with a ui so no need to install separate zwavejs.

If zwavejs can do it zwavejsui can. Maybe some features are simply not available in UI and in these case command line or something else is needed

Also these 2 cannot be used at same time so your 700 issue may be related to that. Not sure how your switching between the 2 software?

I dont see a way for the key to be retrived in API so maybe you mistake about this?

2 Likes
4

That’s Home Assistant discovering the USB stick, not the add-on. One of the perks of using the official add-on is the integration with HA. If you ran ZUI on bare metal it would also discover your stick.

No, the keys are not stored on the stick. The official add-on auto-creates random keys when you installl it. ZUI doesn’t, but all you need to do is click the refresh buttons in the configuration to generate ones. Not a big advantages for the official add-on.

I would disagree. HA does not support:

  1. UI customized for node management
  2. Assigning group associations
  3. Logging to files
  4. NVM backup and restore (the network is stored on the controller, this saves it)
  5. Auto-NVM-backup with cronjob or during network events (include/exclude)
  6. Controller OTW updates (HA will support soon)
  7. Network map and node health checks
  8. Driver code execution for advanced use (run driver Javascript code)
  9. Overriding device configuration files
  10. Naming nodes and assigning locations during inclusion
  11. Naming nodes and assigning locations with SmartStart
  12. Factory resetting a node
  13. Soft resetting a node
  14. etc…

There’s probably more, but that’s a long enough list. If you don’t need any of those features, then go ahead and stick with the official add-on. Because the zwave-js-server is identical in both add-ons, you lose no capabilities switching to ZUI, only gain them.

A lot of the above items could be implemented in HA, as the add-on (Z-Wave JS Server actually) supports them, but there’s no one available to do the necessary HA frontend work.

6 Likes
5

Thank you for the link!

6

Thanks for your reply. I could have had a misunderstanding on how the keys are handled. I think @freshcoast explains it below.

7

@freshcoast thank you for the detailed reply and explaination.

Regarding the Stick discovery–when I use JS, it “sees” the USB device. When I use JS UI (after JS is uninstalled), it does not see the USB device. Are you saying that 1) because JS is an official add-on, 2) it is able to integrate with HA, which does the detection, 3) and can grab the USB information, 4) whereas JS UI cannot integrate with HA in the same way, 5) which is why it does not show the USB device?

If the above is true, how else could I identify the USB’s device port string if without JS? Obviously, JS was useful to do that, but I was wondering if there is another way.

Also, why would JS UI discover on bare metal where it does not in a VM? What’s the difference?

///

Regarding the keys–Thanks for explaining. That makes sense.

///

Regarding features, I agree that JS UI offers a lot. The port detection and key issue (with my misunderstanding) made me think that in those two instances, JS was superior. Thanks again for clarifying.

8

I was partially mistaken. ZUI in the add-on can see the USB stick, just not the serial/by-id symlinks. Here is a screenshot of my stick being detected as /dev/ttyUSB0. So it’s not completely accurate to say it’s not detected. (If you are not seeing this, perhaps it’s a quirk of your install.)

image

What isn’t detected in ZUI are the persistent by-id symlinks. You can find this path in HA → Settings → Hardware → … → All Hardware. You should copy and paste this path in your ZUI configuration, even if it’s not displayed. The add-on has enabled the ability to create these symlinks.

image

It’s not really ZUI’s fault that it can’t find the by-id symlink, it’s a limitation of the Node.js serialport library. All that library does is enumerate the raw USB serial devices. It doesn’t consider the symlinks that udev creates inside the container (one reason, is they are Linux only). HA’s python USB discovery code does not have these limitations.

So yes, to your original point, HA does do a better job discovering device paths than ZUI, but that’s not really a big win when you compare the entire feature set.

Also, why would JS UI discover on bare metal where it does not in a VM? What’s the difference?

My statement here was when I thought that the add-on did not pass through all the USB devices automatically, which was incorrect. If you are running ZUI in a standalone container without privileged mode, it doesn’t have access to all the devices, but “bare metal” does. However, as mentioned, the ZUI add-on has access to all the device paths.

2 Likes
9

Many thanks for your reply. It was very helpful and explains a lot. The information to find the path under hardware is excellent!

As it turns out, likely by my tunnel vision, /dev/ttyUSB0 was in fact there on ZUI. I tested /dev/ttyUSB0 and it works. Question: Am I better of using /dev/ttyUSB0 or the symlink? Does it make a difference?

Cheers.

10

Always use the symlink, it’s more reliable. Unplugging or adding in other USB devices can change the “raw” path.

2 Likes
11

Thank you very much!

12

Reading the official instructions, I am stuck at #4

  1. Add the Z-Wave integration again (even though it is still installed), and uncheck the “Use the Z-Wave JS Supervisor add-on”. Enter the correct address for the community add-on in the URL field in the next step.

When I reinstall the add on, it takes me directly to the add on page, with no option to disable the JS supervisor add-on.

How do I proceed from here?

Thanks in advance.

Edit: I think I got it. After a restart, it worked.

2 Likes
13

I did it using this guide:

It explains step by step how to install Z-Wave JS UI, as well as how to switch from Z-Wave JS to Z-Wave JS UI and vice versa.

1 Like
14

I’m trying to switch to the UI. I’m stuck on this step with the URL part. It’s pre-filled with an address but it says failed to connect. Tried changing it with an IP address vs localhost and still failed.

If I skip this step and enable the js UI it works but does not have all the names.

15

Holy crapballs is this thing misnamed. To the average person (me) Z-Wave JS is the product, and Z-Wave JS UI is the UI. This thing needs to be renamed to something like “Z-Wave JS with UI” so people can realize it’s a variation of the same thing not an add-on UI. No wonder I had problems trying to run them in parallel.

Sure sure, to the seasoned HA user I’m sure this is obvious but I’m still climbing the steep-ass learning curve over here.

3 Likes
16

I actually agree with you.

The naming used for all of the zwave stuff after coming from openzwave is fairly non-intuitive. And it requires the user to be somewhat fluent in the evolution of the way zwave has been incorporated into HA over the years.

2 Likes