I am in the same situation. I installed the Z-Wave JS add-on, and set up my network and devices, and now would like to use the Z-Wave JS UI now that I have found out about it.
I have added the same keys used in the JS integration into the JS UI integration, set the port and the server is set to ws://core-zwave-js/
Can I just stop the one add-on and start the UI add-on; will the devices still be connected or will I need to go through the process of adding them again?
I stopped the Z-Wave JS add-on, and it looks like the JS UI add on is working properly.
Edit: I was mistaken, devices were showing up on the UI, but all my dashboards and automations didn’t. I disabled the JS UI add on for now, and everything is back to where it was.
I’ll need to figure out more on how to properly set this up when I have more time. Any suggestions welcome.
I posted the instructions to switch above. Here they are again.
Thanks.
To clarify, I disable the current JS integration, and then after configuring the JS UI add-on, I don’t enable it, I have to go through the “Add Integration” process?
I had just re-enabled it before, I’m guessing that was the issue.
You should follow all of the steps that are listed, otherwise it won’t work. Especially step 4, which re-configures the server to connect to.
Ugh, still no luck. Not sure what I did wrong (I’m sure I had the correct address, that’s the only thing I can assume was the issue), but I did find your other writeup on this, I’ll try that again this weekend.
I love Home Asssiant and I support the team. But why is Zwave so fragnmented? Why can’t we have one native Zwave inegration that just works? Screw all these confusing add-ons.
Sorry to vent, but my entire zwave network is offline after the Zwave JS UI update 1.13. Backups won’t fix this, so I’m haing to rebuild the Zwave network…and I got this port error.
This thread has the instructions for fixing the “lock port” error. Did you try them?
I did get it resolved. Your post in partitcular was helpful. Thank you.
Glad to hear that. If you have such problems in the future, take a look at the HA logs and add-on logs first (if you didn’t first) before going the nuclear route. There were a couple of issues, now fixed, revealed by driver updates. No idea if that happened in this case, but the logs would tell us.
In Step 4, What is: Enter the correct address for the community add-on in the URL field in the next step.?
What is the “correct address”?
Can you give me an example?
By default when adding the Z-Wave JS UI Integration (and unchecking the Z-Wave JS Supervisor add-on) the popup has: ws://localhost:3000
Is that the “correct address”? apparently not as I get a Failed to Connect message.
I have to agree this is much more difficult than I had hoped and I’ve spent a few hours trying to get this started up and I keep running in circles.
I suggest:
After more running in circles, I tried: ws://a0d7b954-zwavejs2mqtt:3000
which worked. How can we make this the default instead of localhost?
The URL for the community add-on is documented many places, including multiple times in this very thread, just scroll up a bit.
As a reminder to anyone else stumbling into this thread, when you install an add-on, but sure to read the add-on docs first. This setting is mentioned clearly in the Z-Wave JS UI add-on docs.
The same instructions are in the Z-Wave integration docs.
Many people do not use add-ons, and others use the official add-on, so that value as a default is not correct either. I can only speak for myself, but I don’t think core integrations should hard-code things related to community add-ons. The effort would be better spent on HA being able to auto-discover the add-on and presenting it as a choice, instead of requiring manual entry.
The default URL for the configuration dialog is set here:
Anyone can submit a PR to the project. Getting it accepted is another story, so you can try your luck if you like.
This thread was very helpful, partly because it came up above the official docs in a google search, and partly because it made me reassess my incorrect assumptions about what Z-Wave JS UI is.
While I’m as guilty as anyone when it comes to only skimming official documentation, from reading this thread it’s not only me, and I’m sure the correct answer to this is for me to pay more attention (and that will be my takeaway!).
But mainly what threw me off track originally was the naming; I see one addon called “Z-Wave JS”, which is referred to as a server, and the very top of the installation instructions have you install this by default. I did this.
Then I see references to “Z-Wave JS UI” which looks pretty cool, and I immediately interpret this name (obviously incorrectly) as “the UI addon to Z-Wave JS”. What it really means is “Z-Wave JS With UI”.
Once I got past all that, and followed @freshcoast’s instructions, turns out it is pretty cool, and works well. So kudos to the community devs for producing yet something else amazing.
All that leads me to my actual question; was there a reason this wasn’t just done as a pure UI addon to the existing server, rather than replicating the entire thing?
Z-Wave JS UI is an independent application written by a developer that has no affiliation with Home Assistant. The project has also existed much longer, prior to HA being involved with Z-Wave JS (previously being zwavejs2mqtt and before that zwave2mqtt, those projects focusing on being an MQTT bridge). Many people prefer the UI it provides, and integration with the Z-Wave JS server is there to support HA users. It also interfaces directly with the Z-Wave JS driver, so there’s no need for it to be limited by the websocket API.
If anyone wants to write their own UI using the Z-Wave JS server (websocket server), they would be free to do that. But that’s what HA already is, there’s little reason for an add-on UI.
Thanks, this helps explain it, especially the history.
Totally why I installed it too, and agree wholeheartedly.
I’m guessing that “integration with” means that it encapsulations the same Z-Wave JS Server that HA uses, is that right?
Do you mind explaining this? In my head it looks like
HA → Z-Wave JS UI addon → (contains Z-Wave JS server → (contains Z-Wave JS driver)), but that’s probably way off 
When I originally installed the Z-Wave JS addon, it didn’t have a great UI, and certainly not the UI that the Z-Wave JS UI addon has, unless I missed it? Because this seemed kind of lacking, I looked around and found the same name with “UI” tacked on the end, and mistakenly assumed this was a UI addition. Maybe (probably!) I’m missing your point, though.
Yes, it means supporting HA users by means of the websocket server, as opposed to HA needing to use MQTT (which is limited for HA’s purposes). It just helped with the adoption of Z-Wave JS, as it gave users an alternative, but the core add-on is still the “official” Z-Wave JS application for HA.
Not quite. Both add-ons are Javascript applications. The Z-Wave JS driver and the Z-Wave JS server are separate components that the application manages. The server is only given a reference to the driver instance, it has no responsibility for its lifetime, which is why it is optional in ZUI.
The architecture of the components is explained here:
Z-Wave JS UI is a Javascript application, so it has direct access to calling the Z-Wave JS Javascript APIs and talks to the driver over the JS API, it doesn’t use the Websocket. This means it can provide functionality that isn’t supported by the Websocket API. HA is limited to the Websocket API features.
The core add-on doesn’t have any UI on purpose, Home Assistant is the UI.
Hi All,
Just wanted to share my issue and solution, since I ran into this similar issue today when upgrading to the following:
Z-Wave JS UI
From ? > Z-Wave JS UI - 3.4.0
Home Assistant Core
From 2024.1.8 > 2024.2.3
Operating System
From 11.2 > 11.5
I first noticed the problem because the Z-wave Integration failed to start.
I went to the Z-Wave JS UI Add-On and noticed the error message in the Logs
Failed to open the serial port: Error Resource temporarily unavailable Cannot
lock port
I tried reseating my Z-wave stick physically from the USB Port, but that did not change.
I knew the system could see the stick because I could verify that in:
Settings > System > Hardware > All Hardware > ttyACM1
When looking closer in the Z-Wave JS UI settings I noticed that the USB path has changed to ttyACM0 Which is used for my Zigbee Stick???
How on earth this changed I have no idea, but changing the value to the correct serial portttyACM1 instead of ttyACM0 fixed the issue.
Z-Wave JS immediately saw all my entities and I could not re-enable and start the Z-wave Integration again.
That problem is why HA and ZUI have always recommended using the persistent path /dev/serial/by-id/usb-0658_0200-if00. With the add-on it’s even available as a selection in the menu.
Next time you reboot, they might switch back, and you’ll be in the same situation.
Thank you for the recommendation freshcoast I was not aware of this. I have changed this now, so hopefully it does not happen again 
