Skip to content

Add optional local network URL with fallback - #7

Merged
konradk merged 6 commits into
konradk:mainfrom
RolfKoenders:local-network-url
Aug 17, 2026
Merged

Add optional local network URL with fallback#7
konradk merged 6 commits into
konradk:mainfrom
RolfKoenders:local-network-url

Conversation

@RolfKoenders

Copy link
Copy Markdown
Contributor

Adds an optional local network URL, for people who reach their Home Assistant instance through two addresses: a LAN address at home and something else away from home (Nabu Casa, a reverse proxy, Tailscale, etc).

When it's set, the bridge tries the local address first on every connection attempt and falls back to the main URL if it's not reachable. It reuses the token from the main URL rather than needing its own, since it's the same instance.

The field is collapsed behind a toggle next to the main URL field, off by default, matching the existing Demo mode toggle.

Settings panel with the local network URL toggle

Testing

  • Three new bridge integration tests: local URL preferred when reachable, falls back when it's not reachable, and a bad local URL doesn't block the main URL from being tried
  • Updated Connection.js and ConfigStore.js tests for the new field
  • Full existing test suite passes (bridge, connection, config, store, model, row model, vendor, service contract, qml style)
  • qmllint and omarchy plugin validate pass
  • Verified live against a real Home Assistant instance by symlinking this branch into an Omarchy install

Lets you set a LAN address for your Home Assistant instance alongside the
existing URL. The bridge tries the local address first on every connection
attempt and falls back to the primary URL when it isn't reachable (e.g. away
from home). The local URL shares the primary URL's stored token rather than
needing its own, since it's the same instance reached by a different address.
Two always-visible URL fields, each with its own plaintext warning, was more
chrome than most users need for an optional field. Reuses the Demo mode
toggle's visual pattern: collapsed by default, expands to reveal the field,
starts expanded only if a local URL is already saved. Collapsing clears the
draft so "off" means no local URL rather than a hidden stale value.
@konradk

konradk commented Aug 16, 2026

Copy link
Copy Markdown
Owner

Thank you for your PR! This is definitely a useful improvement, however i have a security concern. Your implementation assumes that we always try to use local address first. On untrusted network there is a risk that we will send token to service that is opened on the same port and IP but is not our HA instance.

I checked how it's implemented in official HA clients and internal address is used only when we are connected to trusted wifi address. Probably we should use the same approach, so plaintext local URLs should require trusted-network detection. wdyt?

@RolfKoenders

Copy link
Copy Markdown
Contributor Author

I fully agree! Will push an update!

Trying the local URL unconditionally meant a laptop joining any Wi-Fi could
send the access token to whatever answers at that address there, not just at
home. Adds a trusted network name field next to the local URL. The bridge now
checks the current Wi-Fi network name (via nmcli) before every attempt and
only tries the local URL when it matches, exactly like the official Home
Assistant apps do with their internal URL. Any failure to determine the
current network fails closed to the primary URL.
@RolfKoenders

Copy link
Copy Markdown
Contributor Author

Pushed a fix. Added a trusted network name field next to the local URL. The bridge checks the current Wi-Fi network name via nmcli before every connection attempt and only tries the local URL when it matches, same as the official HA apps do with their internal URL. If the network name can't be determined for any reason (no NetworkManager, nmcli error, not on Wi-Fi) it fails closed to the primary URL rather than assuming trust.

Also enforced this in Service.applyConnection, not just the bridge, so a local URL can't be saved without a trusted network paired with it.

Added three bridge tests for this: local URL skipped when the current network doesn't match, never used at all when no trusted network is set, and fails closed when the network can't be determined.

A single name didn't cover routers that broadcast separate 2.4GHz and 5GHz
SSIDs, or people who consider more than one location trusted. The field now
takes a comma-separated list, matched against exactly, same as before just
against more than one name.
@konradk

konradk commented Aug 17, 2026

Copy link
Copy Markdown
Owner

Tested the branch on my side, noticed two things:

image
  1. The modal layout breaks after expanding the option to configure the local network
  2. Maybe we could suggest a value for the wifi-name field based on the network currently the user is currently connected to. We should show it only if the network name hasn't already be set.

The connection settings card has a fixed height, and the local URL fields
pushed content past it with nothing to contain the overflow. Wrapped the form
in a scrollable Flickable so this can't recur as more fields get added.

Also suggests the currently connected Wi-Fi name as a one-click fill for the
trusted network field, shown only while that field is empty. While building
it, found that nmcli's default wifi list forces a multi-second radio scan,
which would have blocked the bridge's single-threaded run loop on every
reconnect attempt whenever a local URL is configured. Added --rescan no to
both the bridge's check and the new suggestion, since neither needs a fresh
scan of neighboring networks, only NetworkManager's already-cached state for
the active connection.
@RolfKoenders

Copy link
Copy Markdown
Contributor Author

Pushed fixes for both.

  1. The connection card has a fixed height and the local URL fields pushed content past it with nothing to contain the overflow. Wrapped the form in a scrollable Flickable so this can't happen again as more fields get added.

  2. Added the suggestion: the trusted network field now shows "Currently on ''" with a one-click button to use it, but only while the field is empty. While building this I noticed nmcli's default wifi list forces a multi-second radio scan, which would also have blocked the bridge's connect loop on every reconnect attempt once a local URL is configured. Added --rescan no to both the suggestion and the bridge's own check, since neither needs a fresh scan of neighboring networks, just NetworkManager's already-cached state for the active connection. That dropped the call from ~7s to a few ms.

Tested both live against a real instance this time.

@konradk

konradk commented Aug 17, 2026

Copy link
Copy Markdown
Owner

@RolfKoenders thank you for your contribution! Merging.

@konradk
konradk merged commit 2d6f239 into konradk:main Aug 17, 2026
1 check passed
@RolfKoenders

Copy link
Copy Markdown
Contributor Author

@RolfKoenders thank you for your contribution! Merging.

Thank you for the plugin!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants