Z-Wave JS UI Driver: Failed to open the serial port Cannot lock port (ZW0100)

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.

1 Like

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.

1 Like

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:

  1. after clicking on the Add Integration and searching for Z-Wave, then selecting Z-Wave
  2. in addition to the checkbox for Use the Z-Wave JS Supervisor add-on
    a radio button allows the Z-Wave JS UI add-on to be installed instead.
    And have a note or when hovering over each one it says the UI version is for advanced users.

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.

1 Like

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 :upside_down_face:

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.

1 Like

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

  • /dev/serial/by-id/usb-0658_0200-if00
    Screenshot 2024-02-24 at 11.32.41

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.

1 Like

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.

2 Likes

Thank you for the recommendation freshcoast I was not aware of this. I have changed this now, so hopefully it does not happen again :slight_smile:

2 Likes

I’ve added Z-wave JS UI, but it looks like there is a conflict because I have Z-Wave JS already running. It looks like I have to uninstall that and then re-install Z-wave JS UI? I’m afraid if I do that, I’ll lose all the the Z-wave devices I spent days adding to HA. If someone can help a newbie to configuring all of this in HA so I don’t mess this up, I’d appreciate it.

Did you find out what to do? I’m in the same situation, I’ve had the Z-Wave JS add-on for a few years and just found out about UI. I’ve added the UI add-on in addition to the Z-Wave JS add-on because it sounds like these can now run side-by-side. However, the UI add-on is stuck with this error:
Driver: Failed to open the serial port

It’s quite the opposite:

And the official documentation:

https://www.home-assistant.io/integrations/zwave_js/#can-i-switch-between-z-wave-js-and-z-wave-js-ui

Can I switch between Z-Wave JS and Z-Wave JS UI?

You can switch between the official Z-Wave JS add-on and the Z-Wave JS UI add-on. However, but you cannot run them both at the same time. Only one of them can be active at the same time.

A guide for switching add-ons:

1 Like

Oh, in the Z-Wave UI docs, it reads “Compatible with the Home Assistant Z-Wave JS integration.” I understood that to mean these can run side-by-side.

Thanks for the additional docs!

That is the guide I used. The funny and ironic thing is I switched over so I could set up association with some Z-wave devices that weren’t reporting back to HA when manually using the switches and I could never get the associations to work :slight_smile: That guide is good, however.

You are confusing Add-ons (like Z-wave-JS UI) and Integrations. For Home Assistant, the Z-wave-JS UI Add-on works with the Z-wave JS integration. Having similar names makes it even more confusing.