Short Answer: Use the Official Z-Wave JS App by Default, and Separate It Only on Purpose

If you are starting a new Z-Wave network in Home Assistant in June 2026, the clean default is the official Z-Wave JS app on the same Home Assistant host. Home Assistant's Z-Wave docs make that the recommended install path, and the official release notes now treat the old installer split as largely historical.

A separate Z-Wave JS UI server still makes sense, but only when you have a concrete topology reason: you want the radio physically away from the Home Assistant box, you want Z-Wave to stay up while you reboot or tinker with Home Assistant, or you already run a stable remote server and do not want to collapse it back into one box.

The important shift is this: for many users, the argument is no longer really about features. It is about deployment shape, lifecycle coupling, and how much complexity you want to own.

Tara's default: if the home needs reliable locks, lighting, sensors, and supportable maintenance, take the boring path first. Earn the advanced topology later.

Why This Question Is Worth Publishing Right Now

The demand signal is active, not theoretical. On the Home Assistant Community's Z-Wave category page visible on June 23, 2026, recent threads included Zwave JS UI Versioning Differences, Z-Wave JS 1.1.0 Vs Z-Wave JS UI 7.0.0, Z-wave broken after update to HA 2026.6.0, Migrating from Z-Wave USB Stick (ZMEEUZB1) to ZWA-2, and Install and setup Zwave JS UI with Snap on a Raspberry Pi, with the category page showing that last thread at 14,434 views and the migration thread at 1,020 views. That is not a dead corner of the ecosystem.

Reddit shows the same confusion in plainer language. A current r/homeassistant thread from roughly February 2026 asks whether there is any reason to keep using the community-packaged Z-Wave JS UI now that the official Z-Wave JS 1.0 includes a UI. The highest-signal replies there say the main reason to keep the separate path is when you want a setup that stays independent of Home Assistant itself. That is a community interpretation, not an official Home Assistant statement, but it matches the practical tradeoff visible in the docs and release notes.

GitHub and the forum also show the downside of the advanced path. A Home Assistant Community thread on June 4, 2026 and a GitHub issue opened on June 10, 2026 both describe remote Z-Wave JS UI servers that became unavailable or falsely incompatible after upgrading Home Assistant 2026.6.x. That does not mean remote servers are a bad design. It does mean the extra flexibility comes with a version-matching and upgrade-management tax.

What Actually Changed in Home Assistant

Home Assistant's official Z-Wave docs now describe the network in four explicit parts: the adapter, the Z-Wave server, the Z-Wave integration, and the end devices. The recommended flow says to plug in a supported adapter, accept Recommended installation, and let Home Assistant install the Z-Wave JS app on the Home Assistant server.

Then came the user-facing shift. In the April 1, 2026 release notes for Home Assistant 2026.4, Home Assistant says the old hidden Z-Wave Installer panel was removed because the same functionality is now available through Z-Wave JS UI in the Z-Wave app. The current docs also include a specific migration section for moving from Z-Wave JS UI to the Z-Wave JS app. That is a strong signal that the official path is no longer the stripped-down one.

My interpretation from those sources is straightforward: for most users on Home Assistant OS, the official app has become the default not just because it exists, but because Home Assistant expects it to be the supportable baseline.

Which Path Fits Which House?

Path Best when Main cost
Official Z-Wave JS app on the Home Assistant host You are starting fresh, running one main Home Assistant box, and want the least moving parts. Z-Wave lives on the same host lifecycle as Home Assistant, so reboots and host placement matter more.
Separate Z-Wave JS UI server You want the radio and server independent of Home Assistant restarts, or you need them physically elsewhere. You own the version compatibility, update cadence, and remote connectivity details.
Existing stable remote Z-Wave JS UI setup You already solved placement and reliability, and the network is behaving. The temptation to migrate for branding reasons can create downtime you did not need.
Portable Z-Wave over Wi-Fi or PoE You have a specific placement problem and you understand advanced tradeoffs. Home Assistant's own announcement calls it experimental and not the most stable default.

When the Official App Is the Right Answer

1. You are building a new Z-Wave network on one main box

This is the easiest case. The Home Assistant docs explicitly recommend the install path that uses the Z-Wave JS app on the Home Assistant server. If you are on Home Assistant OS, using Home Assistant Green, or using a mini PC as a dedicated Home Assistant appliance, the official app is the path of least friction.

2. You want the most supportable default

The docs now treat migration from Z-Wave JS UI to the Z-Wave JS app as a first-class supported activity, and the release notes show Home Assistant moving more Z-Wave workflow into the official app. That is a clear sign of direction. If you want fewer moving parts to explain later, follow that direction unless you have a concrete reason not to.

3. Your coordinator can live in a good spot near the Home Assistant host

If the Home Assistant machine can sit in a reasonably central, low-interference location, the single-box setup is often enough. This is especially true if you use a better adapter instead of a tiny dangling stick. Home Assistant's Z-Wave adapter docs recommend the Home Assistant Connect ZWA-2, and the August 13, 2025 ZWA-2 announcement says the design moved away from the classic USB-stick form factor specifically because USB ports and cramped server placement create interference and poor antenna conditions.

When a Separate Z-Wave JS UI Server Is Still the Right Call

1. You need physical placement freedom

If your Home Assistant host sits in a rack, closet, basement, or media cabinet where RF placement is bad, separating the Z-Wave server can still be rational. The official docs are explicit that the adapter should be connected to the same host where the Z-Wave JS server is running. That means if you move the server, the radio moves with it. Sometimes that is exactly what you want.

2. You want Z-Wave insulated from Home Assistant reboots and experiments

The strongest community argument for the separate path is still operational isolation. If you frequently restart Home Assistant, test add-ons, or rebuild the main box, keeping the Z-Wave server elsewhere means the controller process is not flapping every time the automation hub changes state.

3. You already have a stable remote install

If a remote Z-Wave JS UI server is already running well and it solves a real topology problem, there is no prize for collapsing it back into the official app immediately. Community replies around the Z-Wave JS 1.0 transition repeatedly say there is no hurry if your current setup works and you are not chasing a missing feature.

Why the Advanced Path Still Bites People

The cost is not imaginary. On June 4, 2026, a Community thread documented Home Assistant 2026.6.0 refusing to talk to a reachable remote Z-Wave server and reporting an invalid server version. On June 10, 2026, GitHub issue #173453 described a similar regression on Home Assistant Core 2026.6.1, where the same remote Z-Wave JS UI server still worked on 2026.5.4 but became unavailable after the upgrade. The report says all Z-Wave devices became unavailable and automations stopped functioning until Home Assistant was rolled back.

That is the real trade: decoupling can improve placement and reboot behavior, but it also means you are now the person who has to think about server schema versions, remote discovery, API compatibility, and update order.

Do Not Migrate Just Because the Names Changed

A lot of confusion in 2026 comes from the fact that the visible UI got closer while the deployment choices remained different. That is not a good reason to rebuild a healthy Z-Wave network. If you already have dozens of secure devices, locks, or carefully tuned associations, treat migration like infrastructure work, not like changing a theme.

Home Assistant's current docs include a dedicated migration section from Z-Wave JS UI to the Z-Wave JS app. That is useful, but it should also tell you something important: migration is a planned task, not a casual Friday click.

Practical rule: do not move the packaging, the adapter, and the host at the same time unless you enjoy debugging your front door after midnight.

Before You Change Anything, Back Up the Controller

Home Assistant's Z-Wave docs say to use Settings > Z-Wave > Download backup and store the controller backup somewhere safe. The same docs say this backup contains the non-volatile memory of the adapter, including paired devices, and recommend taking one before major changes such as migrating to a new adapter or resetting the adapter.

That is not optional ceremony. If you are moving from a separate Z-Wave JS UI setup to the official app, or from one adapter to another, the backup is the line between a controlled migration and a re-pair marathon. Pair that with your security keys and a maintenance window.

If Placement Is the Real Problem, Solve Placement First

Home Assistant's ZWA-2 announcement is blunt about RF reality: old USB-stick placement is often poor, and interference from the host can matter. The whole reason ZWA-2 exists as a larger adapter with a dedicated cable and antenna is to give the radio a better physical life.

So if your urge to build a remote Z-Wave JS UI server is really just "my coordinator is wedged behind a metal rack," first try the simpler fix: a better adapter, better antenna geometry, and better placement. Only move to a network-connected radio path if you actually need it.

Home Assistant's October 13, 2025 Portable Z-Wave announcement does offer a network-connected answer for the ZWA-2 over Wi-Fi or PoE, but the same announcement explicitly labels it experimental and says not to use it if you are looking for the most stable Z-Wave experience. That is a useful tool for advanced installs, not the default homeowner answer.

Tara's Take

For a Tara-style installed home, the ranking is simple. Start with the official Z-Wave JS app if the Home Assistant host can live somewhere sensible and the home needs a supportable baseline. Use a separate Z-Wave JS UI server only when there is a real topology reason to separate the radio and server from the Home Assistant host. And if a remote setup is already working, do not tear it apart just because the UI names got closer in 2026.

In other words: let reliability decide, not brand nostalgia and not a forum comment you half-remembered from two releases ago.

If this decision is really part of a bigger hardware or protocol plan, these guides connect the Z-Wave choice to the rest of the house.

FAQ

Are Z-Wave JS and Z-Wave JS UI different radio protocols?

No. They are not different radio stacks. In practice, the difference for Home Assistant users in 2026 is how the Z-Wave server is deployed and how tightly it is coupled to the Home Assistant host.

Should a new Home Assistant user start with the official Z-Wave JS app?

Usually yes. That is the recommended installation path in Home Assistant's current Z-Wave docs, and it is the least complicated answer when you are not solving a placement or lifecycle problem.

If I run a separate Z-Wave JS UI server, where does the adapter go?

On the same host as the Z-Wave JS server. Home Assistant's docs call that out directly. If the server is remote, the adapter is remote too.

Do I need to migrate off a stable remote Z-Wave JS UI setup right away?

No. If the setup is stable and intentional, there is no urgent reason to rebuild it. Migrate only when the simplification benefit is real enough to justify a planned maintenance window.

Is Portable Z-Wave over Wi-Fi or PoE the best default answer for bad placement?

Usually no. Home Assistant's own announcement says that path is experimental and not for people seeking the most stable default. Fix basic placement first, then reach for the advanced option only if you still need it.