Home Assistant away from home on your watch: local URL, remote URL, Home Assistant Cloud and VPNs

The short answer

At home, AmazHA, a Home Assistant app for Amazfit watches, needs only your local address, such as http://192.168.1.50:8123, and nothing has to be reachable from outside. Away from home, your phone needs a remote address it can reach: Home Assistant Cloud, a VPN such as Tailscale or WireGuard, or your own domain with HTTPS. Enter both, and AmazHA picks the one that works, on its own.

At home you need nothing extra

On your home network, the only address AmazHA needs is the one you already use to open Home Assistant in a browser at home. That is the Local URL (LAN) field in the AmazHA settings, and it is enough on its own: no subscription, no VPN, no domain, no open port on your router.

AmazHA has two address fields in its settings: Local URL (LAN) and Remote URL. Either can stay empty. If you only ever use the watch at home, fill in the local one, leave the remote one blank, and you are done. You can add a remote address later, the day you want the watch to work at the office or on holiday, without touching anything else.

The fields are in the Zepp app, under Profile › your watch › Apps › AmazHA › Settings › Home Assistant. They appear once the full version is unlocked (a one-time unlock, no subscription): the free version is a live demo on sample data and does not connect to a server. The Connect Home Assistant tutorial shows the local address step on video.

A typical local address looks like one of these (examples, use your own):

http://192.168.1.50:8123
http://homeassistant.local:8123

If you type an address without http:// or https:// in Local URL (LAN), AmazHA puts http:// in front of it, because local servers usually speak plain http.

Why it is your phone that has to reach Home Assistant

The watch never talks to Home Assistant itself. It talks to your phone over Bluetooth, and the part of AmazHA that runs inside the Zepp app on the phone is the only part that sends requests to your server. So the question “can my watch reach Home Assistant?” is really “can my phone reach Home Assistant, right now, from where it is?”

That has a few practical consequences:

• The watch needs no Wi-Fi. It never joins a network for AmazHA. A watch with Bluetooth only works the same way.
• The phone has to be nearby, with Bluetooth on and the Zepp app running. If it is not, the watch says Offline · No answer from the phone, which is a different problem from a wrong address (see troubleshooting, step 2).
• Whatever network the phone is on decides which address works. On your home Wi-Fi, the local address works. On mobile data, at a friend’s house or on hotel Wi-Fi, only a remote address can work, and only if the phone can reach it from there.
• A VPN must be connected on the phone, not on the watch. The watch knows nothing about it.
• Your token stays on the phone. You paste a long-lived access token once, in the AmazHA settings. The watch receives only what it shows, over the Bluetooth link it already has with the phone; the token is never sent to it.

This explains a confusing picture: the settings say Connected and the watch says Offline. The settings test only the phone’s path to Home Assistant; the watch also needs the Bluetooth path to the phone.

How AmazHA picks the address

AmazHA picks the address on its own, local first, then remote. There is no switch to flip when you leave the house, and you never choose between the two fields by hand.

With one address

With only one field filled in, AmazHA simply uses it. Nothing is probed and nothing is switched. A local-only setup works at home and shows the Offline banner away from home; a remote-only setup works wherever the phone can reach that address.

With both addresses

With both fields filled in, the phone asks both addresses at the same time whether Home Assistant answers, with a short time limit of 1.5 seconds. If the local address answers, AmazHA uses it. If only the remote one does, it uses that. The winner is remembered, so later requests go straight to it without asking again.

The check is stricter than “something answered”. An address counts only when it answers as the Home Assistant API. That matters on other people’s networks: on hotel Wi-Fi, 192.168.1.50 might be a printer, a router page or a captive portal that answers with a web page. AmazHA does not mistake that for your server, so it does not get stuck on your local address while the real answer is your remote one.

Leaving home and coming back

The remembered address is kept until a request to it fails. When you leave the house and the phone drops off your Wi-Fi, the next request to the local address fails, AmazHA forgets it, and the following attempt asks both addresses again and lands on the remote one. While the AmazHA app is open, the watch refreshes every 8 seconds, so in practice the first refresh after the switch can fail and show the Offline banner briefly, and the next one recovers.

Coming home works the other way round, more quietly: if your remote address also works from inside your network, AmazHA keeps using it until a request fails or you tap Connect again. Nothing is wrong when that happens; the remote address is simply still working.

Typing the addresses

A few details are worth knowing when you fill in the fields:

• Nothing after the server address. http://192.168.1.50:8123, not http://192.168.1.50:8123/lovelace. The same goes for the remote one: https://xxxxx.ui.nabu.casa, not https://xxxxx.ui.nabu.casa/lovelace. With a path left on, the address answers, but not as the Home Assistant API.
• The scheme. With no scheme typed, Local URL (LAN) gets http:// and Remote URL gets https://. Type http:// yourself if a remote address really is plain http (a VPN address, for example).
• The port. Keep the port if your address needs one, as in :8123. Without a port, https:// means 443.
• One token for both. Paste it once into Long-lived access token; it serves the local and the remote address. Both addresses must lead to the same Home Assistant.

The Connect Home Assistant tutorial covers the remote address step, and step 8 the test that follows.

The remote options compared

Any remote address works with AmazHA as long as the phone can open it from where it is, and it answers as the Home Assistant API. Which one to use is a Home Assistant decision, not an AmazHA one. Here are the common ones side by side.

Home Assistant Cloud (soon Home Assistant Link)

Home Assistant Cloud is the subscription service run by Nabu Casa; its subscriptions fund Home Assistant’s full-time development. Home Assistant’s own documentation calls it the easiest option for most people: it needs no open router ports, it encrypts the traffic, and it generates a unique remote URL for you.

For AmazHA, that remote URL is all you need: copy it, as Home Assistant shows it, into Remote URL, with nothing after it. Your long-lived access token works through it just as it does on your local address, since both lead to the same server.

On 2 October 2026 Nabu Casa announced that Home Assistant Cloud will be renamed Home Assistant Link on 2 December 2026. The announcement says it is the same subscription under a new name and that no action is needed. It does not mention any change of address, so there is nothing to change in AmazHA today.

A VPN: Tailscale, WireGuard and others

A VPN puts your phone on your home network, virtually, wherever it is. Home Assistant’s documentation lists VPN services such as Tailscale and ZeroTier One as a secure way in, and points out the catch: the VPN has to be connected before anything can reach Home Assistant from outside. For AmazHA that means the VPN must be connected on the phone. If it drops, the watch shows Offline · Home Assistant unreachable until it is back.

What goes in Remote URL is the address your phone uses for Home Assistant while the VPN is up: the server’s address inside the VPN, or a name your VPN resolves for it. Two details:

• If your server answers plain http there, type http:// in front of the address. With no scheme, AmazHA adds https:// to the remote address, which would not answer.
• With some VPN setups your home address itself, 192.168.1.50, becomes reachable through the tunnel. Then the local address works everywhere the VPN is on, and the remote field is a fallback for when it is not.

A VPN is the option with the least exposure: nothing of your server is open to the internet. The price is that every device that needs Home Assistant, the phone included, has to run the VPN client.

Your own domain with HTTPS: a reverse proxy or a tunnel

With your own domain, https://ha.example.com leads to your Home Assistant from anywhere. Two common ways to get there:

• A reverse proxy (Nginx, Caddy, Traefik or similar) at home receives the requests on port 443, handles the certificate, and passes the requests on to Home Assistant. It needs a port forward on your router.
• A tunnel such as Cloudflare Tunnel runs a small connector inside your network that keeps an outgoing connection open to the provider, so nothing is opened on your router. The provider serves your domain with a valid certificate.

In both cases something sits in front of Home Assistant and forwards requests to it, and Home Assistant has to be told to trust it. Home Assistant’s documentation is explicit that requests from a reverse proxy are blocked unless you turn on Trust X-Forwarded-For and add the proxy to Trusted proxies. If you skip that, every request through the proxy gets 400 Bad Request (more on that below).

Port forwarding on its own

Forwarding a router port straight to Home Assistant is the most direct way, and the one Home Assistant’s remote access documentation is most careful about: just opening a port is not secure, the traffic has to be encrypted, and you should go through its security checklist before exposing anything. It also notes two practical traps: many internet providers give you a dynamic IP address, which is why it suggests a dynamic DNS name such as DuckDNS, and some providers put you behind CG-NAT, where incoming connections cannot reach you at all.

If you go this way, the remote address is your dynamic DNS name with https and the port you forwarded, for example https://yourname.duckdns.org:8123. Put exactly that in Remote URL.

HTTPS and certificates away from home

Away from home, the rule in the troubleshooting tutorial is short: the address needs https with a valid certificate. There are two reasons.

The first is security. Your long-lived access token goes with every request the phone sends. Over plain http on the open internet, anyone on the path can read it, and with it control your home.

The second is that phones refuse certificates they do not trust. A self-signed certificate, made on your own server, is not signed by an authority the phone trusts out of the box, so the connection is refused before it ever reaches Home Assistant. On the watch that looks like any other unreachable server. The simple fix is a certificate the phone already trusts:

• Home Assistant Cloud and tunnels such as Cloudflare Tunnel provide one for you.
• With your own domain or a dynamic DNS name, Let’s Encrypt certificates are free and trusted by phones.

Two pitfalls catch people who set up HTTPS on Home Assistant itself, rather than on a proxy in front of it:

• The local address changes too. Once Home Assistant serves HTTPS on its port, plain http://192.168.1.50:8123 no longer answers on that port.
• An IP address does not match the certificate. A certificate for ha.example.com is not valid for https://192.168.1.50:8123, so that local address fails the certificate check. A reverse proxy or a tunnel for the remote side, with Home Assistant itself left on plain http at home, avoids both.

Plain http is normal and fine for the local address at home. Inside a VPN, whose tunnel is already encrypted, http can be acceptable too; on the open internet, use https.

Common errors and what the watch says

When something is wrong, the watch says which link failed. The table lists the messages that have to do with addresses, and the one that looks similar but is not.

Offline · Home Assistant unreachable

The banner shows Offline, then Home Assistant unreachable · Retrying every 8s, and under it a short code that tells support exactly what failed. The usual causes: you are away with only a local address; the VPN is not connected on the phone; the remote address works at home but not from outside; the phone does not trust the certificate; or Home Assistant itself is down or restarting. The fix always starts the same way: open the address in the phone’s browser, as described below. The troubleshooting tutorial, step 3, shows this message on video.

Wrong address

Wrong address means the address answered, but with a web page instead of the Home Assistant API. Almost always the address carries a path, typically copied from the browser bar: https://ha.example.com/lovelace/0 instead of https://ha.example.com. Remove everything after the server address (and its port). In the AmazHA settings, the connection test says the same thing in its own words: the address answers, but not with the Home Assistant API, and it gives the example of a Home Assistant Cloud address with and without /lovelace. See troubleshooting, step 4. Less often, the address leads to something else entirely, such as a router’s admin page.

400 Bad Request behind a reverse proxy

If your remote address goes through a reverse proxy or a tunnel and every request comes back 400 Bad Request, Home Assistant is refusing the proxy. Its HTTP integration rejects any request that carries a forwarded-for header when it has not been told to trust reverse proxies, or when the proxy’s address is not on its trusted list, and the answer in both cases is 400. Home Assistant’s log names the address the request came from; for the second case it reads “Received X-Forwarded-For header from an untrusted proxy”, followed by that address.

In AmazHA, Connect shows Error 400 with a single address, or a red dot next to Remote with both.

The fix is on the Home Assistant side. In current versions, the HTTP server settings are in the user interface: Settings › System › Network, turn on Trust X-Forwarded-For and add the proxy’s address or network under Trusted proxies. Older versions use YAML in configuration.yaml (the address below is an example; use your proxy’s):

http:
  use_x_forwarded_for: true
  trusted_proxies:
    - 192.168.1.10

Home Assistant’s HTTP integration documentation has the details for each version. Restart Home Assistant if your version needs it, then tap Connect again.

Offline · No answer from the phone

This one is not about addresses at all. The watch could not reach the phone over Bluetooth, so the phone never got the chance to try Home Assistant. Keep the phone nearby, with Bluetooth on and the Zepp app running (troubleshooting, step 2). Changing addresses will not fix it.

Home Assistant’s own external URL setting

Home Assistant has its own Home Assistant URL settings, with an Internet and a Local network field under Settings › System › Network. They tell Home Assistant and its own apps where it lives. AmazHA does not read them: it uses only the two addresses typed into its own settings. If you changed your external URL in Home Assistant and the watch did not follow, that is why. Copy the new address into Remote URL.

Test from the phone’s browser first

Before you change anything in AmazHA, open the address in the browser on the same phone, from the same place. It is the quickest test there is, because it takes the same path AmazHA takes: the phone, its current network, your address.

1. Turn Wi-Fi off on the phone if you are testing the remote address from home, so it really goes out over mobile data. Turn the VPN on if the remote address needs it.
2. Type the exact address you entered in AmazHA, for example https://ha.example.com.
3. Read the result.

For the local address, do the same with Wi-Fi on, at home. If the browser reaches the login page and AmazHA still fails, check that the field holds the server address alone, with nothing after it, and the same scheme the browser used.

You can also add /api/ to the address in the browser. Home Assistant answers that with an error about authentication, since the browser sends no token: it proves the address leads to the Home Assistant API rather than to some other page. In AmazHA, type the address without /api/.

Test connection in AmazHA: reading LAN and Remote

Connect, in the AmazHA settings, tests the addresses from the phone and tells you what it found. After you tap it, the result appears in a few seconds:

• With one address: Connected ✓ when Home Assistant answers, Unreachable when nothing answers, Error followed by a number when something answered with an HTTP error (for example Error 400 or Error 401), and Answered, but not Home Assistant when the address answers with something that is not the API.
• With both addresses: one result per address, LAN and Remote, each with a coloured dot: green when Home Assistant answers there, orange when something answers but it is not Home Assistant, red when it fails.

Read it with the phone’s position in mind. At home, a red Remote may be normal (a domain that does not loop back inside your network, a VPN that is off) or a real problem, so test again with Wi-Fi off. Away from home, a red LAN is expected; only Remote matters there. Both green, tested once at home and once on mobile data, is the setup that follows you everywhere. Step 8 of the Connect Home Assistant tutorial shows the screen.

When the address works but the token comes from a user without administrator rights, Connect says so under the result. That is a token problem, not an address problem: the address test passes, but the watch cannot load your rooms until the token comes from an administrator.

Four setups, worked through

The same two fields cover very different homes. Four examples, with example addresses:

A flat, home use only. Local URL (LAN): http://192.168.1.50:8123. Remote URL: empty. The watch works on the home Wi-Fi; outside it shows Offline · Home Assistant unreachable, which is expected. Connect reads Connected ✓ at home.

Home Assistant Cloud. Local URL (LAN): http://192.168.1.50:8123. Remote URL: https://xxxxx.ui.nabu.casa. At home AmazHA uses the local address; on mobile data it moves to the Home Assistant Cloud address on its own. Connect shows LAN and Remote, both green at home, because the cloud address also works from inside.

A VPN on the phone. Local URL (LAN): http://192.168.1.50:8123. Remote URL: the server’s address inside the VPN, with http:// typed in front if the server answers plain http there. At home the local address wins. Away, with the VPN connected, the remote one does; with the VPN off, the watch shows the Offline banner until it is on again.

Your own domain behind a reverse proxy. Local URL (LAN): http://192.168.1.50:8123. Remote URL: https://ha.example.com. Before it works, Home Assistant must trust the proxy (Trust X-Forwarded-For, Trusted proxies), or every remote request gets 400. Test the remote address with Wi-Fi off: some routers do not route your own domain back inside, so a red Remote at home does not always mean it fails outside.

A checklist before you leave the house

Five minutes at home save a confused look at the watch later:

1. Local URL (LAN) holds the server address alone, the one your browser uses at home.
2. Remote URL holds the remote address alone: no /lovelace, the port if it needs one, https:// over the internet.
3. The phone’s browser opens the remote address with Wi-Fi off and shows the Home Assistant login page, with no certificate warning.
4. If it is a VPN: the VPN is set to stay connected on the phone.
5. If it is a reverse proxy or a tunnel: Home Assistant trusts it, so no 400.
6. Connect shows LAN and Remote green, or Connected ✓ with one address.
7. The token comes from an administrator, and it is the same for both addresses.

With that done, the watch uses your local address at home and the remote one everywhere else, without you doing anything. And if one day it shows Offline, the second line tells you which side to look at: No answer from the phone is Bluetooth, Home Assistant unreachable is the address.