結論から
自宅では、Amazfit ウォッチ向けの Home Assistant アプリ AmazHA に必要なのはローカルアドレス（例：http://192.168.1.50:8123）だけで、外部からアクセスできるようにしておく必要は何もありません。外出先では、スマートフォンからアクセスできるリモートアドレスが必要です。Home Assistant Cloud、Tailscale や WireGuard などの VPN、HTTPS 対応の独自ドメインのいずれかです。両方を入力すれば、AmazHA が動く方を自動で選びます。
自宅では追加のものは不要
自宅のネットワークで AmazHA に必要なアドレスは、自宅でブラウザから Home Assistant を開くときにすでに使っているものだけです。それが AmazHA の設定の ローカルURL (LAN) の欄で、それだけで足ります。サブスクリプションも、VPN も、ドメインも、ルーターの開放ポートも必要ありません。
AmazHA の設定にはアドレスの欄が2つあります。ローカルURL (LAN) と リモートURL で、どちらも空欄のままでかまいません。ウォッチを自宅でしか使わないなら、ローカルの欄だけを入力し、リモートの欄は空欄にすれば完了です。職場や旅行先でウォッチを使いたくなったら、ほかには何も変えずに、あとからリモートアドレスを追加できます。
この欄は Zepp アプリの プロフィール › お使いのウォッチ › アプリ › AmazHA › 設定 › Home Assistant にあります。フル版のロックを解除すると表示されます（一度だけの購入で、サブスクリプションはありません）。無料版はサンプルデータで動くライブデモで、サーバーには接続しません。ローカルアドレスの手順は、Home Assistant に接続のチュートリアルの動画で紹介しています。
一般的なローカルアドレスは、次のような形です（例です。ご自身のアドレスを使ってください）。
http://192.168.1.50:8123
http://homeassistant.local:8123
ローカルURL (LAN) に http:// や https:// を付けずにアドレスを入力すると、AmazHA は前に http:// を付けます。ローカルのサーバーは通常、暗号化されていない http で通信するためです。
Home Assistant にアクセスする必要があるのがスマートフォンである理由
ウォッチ自体が Home Assistant と通信することはありません。ウォッチは Bluetooth でスマートフォンと通信し、サーバーにリクエストを送るのは、スマートフォンの Zepp アプリの中で動く AmazHA の部分だけです。つまり「ウォッチは Home Assistant にアクセスできるか？」という問いは、実際には「スマートフォンは今いる場所から、今この瞬間に Home Assistant にアクセスできるか？」という問いなのです。
このことから、実際には次のようなことが言えます。
- ウォッチに Wi-Fi は不要です。 AmazHA のためにウォッチがネットワークに接続することはありません。Bluetooth しかないウォッチでも同じように動きます。
- スマートフォンが近くにある必要があります。 Bluetooth がオンで、Zepp アプリが動いていることが条件です。そうでない場合、ウォッチには オフライン · スマホから応答がありません と表示されます。これはアドレスの誤りとは別の問題です（困ったとき、ステップ2を参照）。
- どのアドレスが使えるかは、スマートフォンがつながっているネットワークで決まります。 自宅の Wi-Fi ではローカルアドレスが使えます。モバイルデータ、友人の家、ホテルの Wi-Fi では、リモートアドレスしか使えず、それもスマートフォンがその場所からアクセスできる場合に限ります。
- VPN は、ウォッチではなくスマートフォンで接続する必要があります。 ウォッチは VPN について何も知りません。
- トークンはスマートフォンに残ります。 長期アクセストークンは、AmazHA の設定に一度貼り付けるだけです。ウォッチはスマートフォンとのすでにある Bluetooth 接続で表示する内容だけを受け取り、トークンがウォッチに送られることはありません。
これで、設定には 接続済み と表示されるのにウォッチには オフライン と表示される、という紛らわしい状況も説明できます。設定でテストしているのはスマートフォンから Home Assistant への経路だけで、ウォッチにはそれに加えて、スマートフォンへの Bluetooth の経路も必要なのです。
AmazHA がアドレスを選ぶ仕組み
AmazHA はアドレスを自動で選びます。まずローカル、次にリモートです。家を出るときに切り替えるスイッチはなく、2つの欄のどちらを使うかを手動で選ぶこともありません。
アドレスが1つの場合
どちらか一方の欄だけを入力した場合、AmazHA はそれをそのまま使います。確認も切り替えも行いません。ローカルだけの設定では、自宅では動き、外出先ではオフラインのバナーが表示されます。リモートだけの設定では、スマートフォンがそのアドレスにアクセスできる場所ならどこでも動きます。
アドレスが2つの場合
両方の欄を入力した場合、スマートフォンは2つのアドレスに同時に、Home Assistant が応答するかどうかを1.5秒の短い制限時間で問い合わせます。ローカルアドレスが応答すれば、AmazHA はそれを使います。リモートだけが応答すれば、そちらを使います。選ばれたアドレスは記憶され、以降のリクエストは改めて問い合わせることなく、まっすぐそこに送られます。
この確認は「何かが応答した」よりも厳密です。アドレスが有効と見なされるのは、Home Assistant の API として応答した場合だけです。これは他人のネットワークで重要になります。ホテルの Wi-Fi では、192.168.1.50 がプリンターやルーターの管理ページ、または Web ページで応答するキャプティブポータルかもしれません。AmazHA はそれを自分のサーバーと取り違えないので、本当の答えがリモートアドレスなのにローカルアドレスにとらわれてしまうことはありません。
家を出るとき、帰ってきたとき
記憶されたアドレスは、そこへのリクエストが失敗するまで保持されます。家を出てスマートフォンが Wi-Fi から外れると、次のローカルアドレスへのリクエストが失敗し、AmazHA はそれを忘れ、その次の試行で改めて両方のアドレスに問い合わせて、リモートに落ち着きます。AmazHA アプリを開いている間、ウォッチは8秒ごとに更新するので、実際には切り替わった直後の最初の更新が失敗してオフラインのバナーが一瞬表示され、次の更新で回復することがあります。
帰ってきたときは逆の流れで、もっと静かに進みます。リモートアドレスが自宅のネットワーク内からも使える場合、AmazHA はリクエストが失敗するか、もう一度 接続 をタップするまで、リモートアドレスを使い続けます。そうなっても何も問題はありません。リモートアドレスがまだ使えている、というだけのことです。
アドレスの入力
欄を入力するときに知っておきたい点がいくつかあります。
- サーバーのアドレスの後ろには何も付けません。
http://192.168.1.50:8123が正しく、http://192.168.1.50:8123/lovelaceは誤りです。リモートも同様で、https://xxxxx.ui.nabu.casaが正しく、https://xxxxx.ui.nabu.casa/lovelaceは誤りです。パスが付いたままだと、アドレスは応答しても、Home Assistant の API としては応答しません。 - スキーム。 スキームを入力しなかった場合、ローカルURL (LAN) には
http://、リモートURL にはhttps://が付きます。リモートアドレスが本当に暗号化なしの http の場合（VPN のアドレスなど）は、自分でhttp://を入力してください。 - ポート。 アドレスにポートが必要な場合は、
:8123のように残しておきます。ポートがなければ、https://は 443 を意味します。 - トークンは1つで両方に。 長期アクセストークン に一度貼り付ければ、ローカルとリモートの両方のアドレスに使えます。どちらのアドレスも、同じ Home Assistant につながっている必要があります。
リモートアドレスの手順はHome Assistant に接続のチュートリアルで、そのあとのテストはステップ8で紹介しています。
リモートの選択肢を比較
スマートフォンが今いる場所から開けて、Home Assistant の API として応答するなら、どんなリモートアドレスでも AmazHA で使えます。どれを使うかは AmazHA ではなく Home Assistant 側で決めることです。よく使われる方法を並べて比較します。
| 方法 | リモートURL に入力するもの | 自宅で開放するポート | HTTPS と証明書 | 費用 | スマートフォンに必要なもの |
|---|---|---|---|---|---|
| Nabu Casa の Home Assistant Cloud（2026年12月2日に Home Assistant Link へ移行予定） | 自動で生成されるリモートアドレス https://xxxxx.ui.nabu.casa |
なし | 含まれる | サブスクリプション | 追加のものは不要 |
| VPN（Tailscale、WireGuard など） | VPN 内での Home Assistant のアドレス | Tailscale はなし。自分で運用する WireGuard サーバーは1つ | トンネルは暗号化される。https は自分で設定した場合のみ | 無料の選択肢あり | VPN の接続 |
| トンネル経由の独自ドメイン（Cloudflare Tunnel など） | https://ha.example.com |
なし | トンネルが提供 | 通常はドメインの費用 | 追加のものは不要 |
| リバースプロキシを使った独自ドメイン | https://ha.example.com |
1つ（通常は 443） | 自分で設定（Let’s Encrypt など） | ドメイン、または無料のダイナミック DNS 名 | 追加のものは不要 |
| Home Assistant へ直接のポート転送 | https://yourname.duckdns.org:8123 |
1つ | 自分で設定 | 無料のダイナミック DNS あり | 追加のものは不要 |
Home Assistant Cloud（まもなく Home Assistant Link）
Home Assistant Cloud は Nabu Casa が運営するサブスクリプションサービスで、その収益が Home Assistant のフルタイムの開発を支えています。Home Assistant 自身のドキュメントでは、ほとんどの人にとっていちばん簡単な方法とされています。ルーターのポートを開放する必要がなく、通信を暗号化し、固有のリモート URL を自動で生成してくれます。
AmazHA に必要なのは、そのリモート URL だけです。Home Assistant に表示されたとおりにコピーして、後ろに何も付けずに リモートURL に入力します。どちらも同じサーバーにつながっているので、長期アクセストークンはローカルアドレスと同じように、そのアドレス経由でも使えます。
2026年10月2日、Nabu Casa は Home Assistant Cloud を2026年12月2日に Home Assistant Link へ名称変更すると発表しました。発表によれば、名前が変わるだけで同じサブスクリプションであり、対応は不要です。アドレスの変更については触れられていないので、今のところ AmazHA で変更することは何もありません。
VPN：Tailscale、WireGuard など
VPN を使うと、スマートフォンがどこにあっても、仮想的に自宅のネットワークにつながります。Home Assistant のドキュメントでは、Tailscale や ZeroTier One などの VPN サービスが安全なアクセス方法として紹介されており、注意点も挙げられています。外部から Home Assistant にアクセスするには、先に VPN が接続されている必要があるという点です。AmazHA の場合、VPN は スマートフォンで 接続されている必要があります。VPN が切れると、ウォッチには再接続されるまで オフライン · Home Assistant に接続できません と表示されます。
リモートURL に入力するのは、VPN が接続されている間にスマートフォンが Home Assistant に使うアドレスです。VPN 内でのサーバーのアドレスか、VPN がそのサーバーに対して名前解決する名前です。細かい点が2つあります。
- そこでサーバーが暗号化なしの http で応答する場合は、アドレスの前に
http://を入力してください。スキームがないと、AmazHA はリモートアドレスにhttps://を付け加え、それでは応答しません。 - VPN の設定によっては、自宅のアドレス
192.168.1.50そのものがトンネル経由でアクセスできるようになります。その場合、VPN がオンならどこでもローカルアドレスが使え、リモートの欄は VPN がオフのときの予備になります。
VPN は、外部にさらされる部分がいちばん少ない方法です。サーバーのどの部分もインターネットに開放されません。その代わり、Home Assistant を使うすべてのデバイスで、スマートフォンも含めて VPN クライアントを動かす必要があります。
HTTPS 対応の独自ドメイン：リバースプロキシまたはトンネル
独自ドメインを使えば、https://ha.example.com でどこからでも Home Assistant にアクセスできます。よく使われる方法は2つです。
- リバースプロキシ（Nginx、Caddy、Traefik など）を自宅に置き、ポート 443 でリクエストを受け取り、証明書を処理して、リクエストを Home Assistant に渡します。ルーターでのポート転送が必要です。
- トンネル（Cloudflare Tunnel など）は、ネットワーク内で小さなコネクターを動かし、サービス提供者への外向きの接続を開いたままにするので、ルーターでは何も開放しません。サービス提供者が、有効な証明書付きでドメインを提供します。
どちらの場合も、Home Assistant の前に何かが置かれてリクエストを転送するので、Home Assistant にそれを信頼するよう設定する必要があります。Home Assistant のドキュメントには、Trust X-Forwarded-For（X-Forwarded-For を信頼する）をオンにしてプロキシを Trusted proxies（信頼するプロキシ）に追加しない限り、リバースプロキシからのリクエストはブロックされると明記されています。これを省くと、プロキシを経由したすべてのリクエストが 400 Bad Request になります（詳しくは後述）。
ポート転送のみ
ルーターのポートを直接 Home Assistant に転送するのはいちばん直接的な方法で、Home Assistant のリモートアクセスのドキュメントがもっとも慎重に扱っている方法でもあります。ポートを開放するだけでは安全ではなく、通信を暗号化する必要があり、何かを公開する前にセキュリティのチェックリストを確認すべきだとされています。実際的な落とし穴も2つ挙げられています。多くのインターネットプロバイダーは動的 IP アドレスを割り当てるので、DuckDNS のようなダイナミック DNS 名が勧められていること。そして、一部のプロバイダーは CG-NAT の内側に置くので、外部からの接続がまったく届かないことです。
この方法を使う場合、リモートアドレスは、https と転送したポートを付けたダイナミック DNS 名になります（例：https://yourname.duckdns.org:8123）。それをそのまま リモートURL に入力してください。
外出先での HTTPS と証明書
外出先でのルールは、困ったときはのチュートリアルにあるとおり簡潔です。アドレスには 有効な証明書のある https が必要です。理由は2つあります。
1つ目はセキュリティです。長期アクセストークンは、スマートフォンが送るすべてのリクエストとともに送られます。インターネット上で暗号化なしの http を使うと、経路上の誰でもトークンを読み取ることができ、それを使って家を操作できてしまいます。
2つ目は、スマートフォンが信頼できない証明書を拒否することです。自分のサーバーで作成した自己署名証明書は、スマートフォンが最初から信頼している認証局の署名がないので、接続は Home Assistant に届く前に拒否されます。ウォッチでは、ほかの接続できないサーバーと同じように見えます。簡単な解決策は、スマートフォンがすでに信頼している証明書を使うことです。
- Home Assistant Cloud や、Cloudflare Tunnel などのトンネルは、証明書を用意してくれます。
- 独自ドメインやダイナミック DNS 名なら、Let’s Encrypt の証明書が無料で、スマートフォンにも信頼されています。
前段のプロキシではなく Home Assistant 自体で HTTPS を設定した人がはまりやすい落とし穴が2つあります。
- ローカルアドレスも変わります。 Home Assistant がそのポートで HTTPS を提供するようになると、暗号化なしの
http://192.168.1.50:8123はそのポートで応答しなくなります。 - IP アドレスは証明書と一致しません。
ha.example.com用の証明書はhttps://192.168.1.50:8123には有効でないため、そのローカルアドレスは証明書の確認に失敗します。リモート側にはリバースプロキシかトンネルを使い、自宅では Home Assistant 自体を暗号化なしの http のままにしておけば、どちらも避けられます。
自宅のローカルアドレスでは、暗号化なしの http が一般的で問題ありません。トンネル自体が暗号化されている VPN 内でも、http が許容できる場合があります。インターネット上では https を使ってください。
よくあるエラーとウォッチの表示
問題があると、ウォッチはどの経路で失敗したかを表示します。この表は、アドレスに関係するメッセージと、似ているけれど関係のないメッセージをまとめたものです。
| ウォッチの表示 | 意味 | 対処法 |
|---|---|---|
| オフライン · Home Assistant に接続できません · 8 秒ごとに再試行 | スマートフォンが、入力したどのアドレスでも Home Assistant にアクセスできませんでした | スマートフォンのある場所から、スマートフォンのブラウザでアドレスを開いてみます。外出先では有効な証明書のある https が必要です |
| アドレスが違います · 応答はありますが Home Assistant の API ではありません | 何かが応答しましたが、Home Assistant の API ではありません。たいていはアドレスの後ろの /lovelace のようなパスが原因です |
サーバーのアドレスだけを残し、後ろには何も付けません |
| オフライン · スマホから応答がありません | ウォッチがスマートフォンにアクセスできませんでした。アドレスは関係ありません | スマートフォンを近くに置き、Bluetooth をオンにして、Zepp アプリを起動しておきます |
| 管理者トークンが必要 | アドレスは使えていますが、トークンが管理者権限のないユーザーのものです | 管理者として長期アクセストークンを作成します |
オフライン · Home Assistant に接続できません
バナーには オフライン、続いて Home Assistant に接続できません · 8 秒ごとに再試行 と表示され、その下に、何が失敗したのかをサポートが正確に把握できる短いコードが表示されます。よくある原因は次のとおりです。ローカルアドレスしかないのに外出している、スマートフォンで VPN が接続されていない、リモートアドレスが自宅では使えても外からは使えない、スマートフォンが証明書を信頼していない、または Home Assistant 自体が停止中か再起動中である。対処はいつも同じところから始まります。後述のとおり、スマートフォンのブラウザでアドレスを開いてみることです。困ったときはのチュートリアル、ステップ3の動画で、このメッセージを紹介しています。
アドレスが違います
アドレスが違います は、アドレスは応答したものの、Home Assistant の API ではなく Web ページが返ってきたことを意味します。ほとんどの場合、アドレスにパスが付いています。典型的なのは、ブラウザのアドレスバーからコピーした https://ha.example.com ではなく https://ha.example.com/lovelace/0 のようなものです。サーバーのアドレス（とそのポート）より後ろをすべて削除してください。AmazHA の設定の接続テストも、同じことを独自の表現で伝えます。アドレスは応答するが Home Assistant の API ではない、という内容で、/lovelace の有無による Home Assistant Cloud のアドレスの例も示します。困ったとき、ステップ4をご覧ください。まれに、ルーターの管理ページなど、まったく別のものにつながっていることもあります。
リバースプロキシの背後での 400 Bad Request
リモートアドレスがリバースプロキシやトンネルを経由していて、すべてのリクエストが 400 Bad Request になる場合、Home Assistant がプロキシを拒否しています。Home Assistant の HTTP 連携は、リバースプロキシを信頼するよう設定されていない場合や、プロキシのアドレスが信頼リストにない場合、転送元を示すヘッダーの付いたリクエストをすべて拒否し、どちらの場合も 400 を返します。Home Assistant のログには、リクエスト元のアドレスが記録されます。2つ目の場合は「Received X-Forwarded-For header from an untrusted proxy」という文に続いて、そのアドレスが記録されます。
AmazHA では、接続 の結果に、アドレスが1つなら エラー 400、2つなら リモート の横に赤い点が表示されます。
対処は Home Assistant 側で行います。現在のバージョンでは、HTTP サーバーの設定はユーザーインターフェイスにあります。設定 › システム › ネットワーク で Trust X-Forwarded-For をオンにし、Trusted proxies にプロキシのアドレスまたはネットワークを追加します。古いバージョンでは、configuration.yaml に YAML で記述します（下のアドレスは例です。ご自身のプロキシのアドレスを使ってください）。
http:
use_x_forwarded_for: true
trusted_proxies:
- 192.168.1.10
バージョンごとの詳細は、Home Assistant の HTTP 連携のドキュメントに書かれています。お使いのバージョンで必要なら Home Assistant を再起動し、もう一度 接続 をタップしてください。
オフライン · スマホから応答がありません
このメッセージは、アドレスとはまったく関係ありません。ウォッチが Bluetooth でスマートフォンにアクセスできなかったため、スマートフォンが Home Assistant に接続を試みる機会すらなかったのです。スマートフォンを近くに置き、Bluetooth をオンにして、Zepp アプリを起動しておいてください（困ったとき、ステップ2）。アドレスを変えても解決しません。
Home Assistant 自身の外部 URL の設定
Home Assistant には、設定 › システム › ネットワーク の下に、Internet（インターネット）と Local network（ローカルネットワーク）の欄を持つ独自の Home Assistant URL の設定があります。これは、Home Assistant と Home Assistant 自身のアプリに、サーバーの場所を伝えるためのものです。AmazHA はこれを読み取らず、自分の設定に入力された2つのアドレスだけを使います。Home Assistant で外部 URL を変更したのにウォッチが追従しなかったのは、そのためです。新しいアドレスを リモートURL にコピーしてください。
まずスマートフォンのブラウザでテスト
AmazHA で何かを変える前に、同じスマートフォンのブラウザで、同じ場所からアドレスを開いてみてください。AmazHA と同じ経路、つまりスマートフォン、その時点のネットワーク、あなたのアドレスを通るので、これがいちばん手早いテストです。
- 自宅からリモートアドレスをテストする場合は、スマートフォンの Wi-Fi をオフにして、本当にモバイルデータで外に出るようにします。リモートアドレスに VPN が必要なら、VPN をオンにします。
- AmazHA に入力したのと まったく同じアドレスを入力します（例：
https://ha.example.com）。 - 結果を確認します。
| ブラウザの表示 | わかること |
|---|---|
| Home Assistant のログインページ | アドレスと証明書は問題ありません。問題はほかにあります（パス、トークン、Bluetooth） |
| 証明書の警告 | スマートフォンが証明書を信頼していません。このままでは AmazHA はこのアドレスを使えません |
| 何も表示されない、または「このページにアクセスできません」 | スマートフォンは、このネットワークからそのアドレスにアクセスできません |
| 400 Bad Request | Home Assistant がまだ信頼していないリバースプロキシ |
| 別のページ（ルーター、プロバイダー、プロキシの初期ページ） | アドレスが別の場所につながっています |
ローカルアドレスの場合は、自宅で Wi-Fi をオンにした状態で同じことを行います。ブラウザでログインページが表示されるのに AmazHA が失敗する場合は、欄にサーバーのアドレスだけが入っていて後ろに何も付いていないこと、そしてブラウザが使ったのと同じスキームであることを確認してください。
ブラウザでアドレスの後ろに /api/ を付けてみる方法もあります。ブラウザはトークンを送らないので、Home Assistant は認証に関するエラーを返します。これで、そのアドレスがほかのページではなく Home Assistant の API につながっていることがわかります。AmazHA には /api/ を付けずにアドレスを入力してください。
AmazHA の接続テスト：LAN とリモートの読み方
AmazHA の設定の 接続 は、スマートフォンからアドレスをテストし、わかったことを表示します。タップすると、数秒で結果が表示されます。
- アドレスが1つの場合： Home Assistant が応答すれば 接続済み ✓、何も応答しなければ 接続不可、何かが HTTP エラーで応答した場合は エラー に続けて番号（エラー 400 や エラー 401 など）、アドレスが API ではない何かで応答した場合は 応答あり、ただし Home Assistant ではありません と表示されます。
- アドレスが2つの場合： アドレスごとに、LAN と リモート の結果がそれぞれ色付きの点とともに表示されます。Home Assistant が応答すれば緑、何かが応答したが Home Assistant ではなければオレンジ、失敗すれば赤です。
結果は、スマートフォンがどこにあるかを踏まえて読んでください。自宅では、リモート が赤なのは正常な場合（自宅のネットワーク内には折り返さないドメイン、オフになっている VPN）もあれば、本当の問題の場合もあるので、Wi-Fi をオフにしてもう一度テストしてください。外出先では LAN が赤なのは当然で、重要なのは リモート だけです。自宅で一度、モバイルデータで一度テストして両方とも緑なら、どこへ行っても使える設定です。画面はHome Assistant に接続のチュートリアルのステップ8で紹介しています。
アドレスは使えるのに、トークンが管理者権限のないユーザーのものである場合、接続 は結果の下でそのことを知らせます。これはアドレスではなくトークンの問題です。アドレスのテストは通りますが、トークンが管理者のものになるまで、ウォッチは部屋を読み込めません。
4つの設定例
同じ2つの欄で、まったく異なる家に対応できます。例のアドレスを使った4つの例を紹介します。
自宅だけで使うマンション。 ローカルURL (LAN)：http://192.168.1.50:8123。リモートURL：空欄。ウォッチは自宅の Wi-Fi で動き、外では オフライン · Home Assistant に接続できません と表示されますが、これは想定どおりです。自宅では 接続 に 接続済み ✓ と表示されます。
Home Assistant Cloud。 ローカルURL (LAN)：http://192.168.1.50:8123。リモートURL：https://xxxxx.ui.nabu.casa。自宅では AmazHA はローカルアドレスを使い、モバイルデータでは自動で Home Assistant Cloud のアドレスに切り替えます。クラウドのアドレスは自宅の中からも使えるので、自宅では 接続 に LAN と リモート が表示され、どちらも緑になります。
スマートフォンで VPN。 ローカルURL (LAN)：http://192.168.1.50:8123。リモートURL：VPN 内でのサーバーのアドレス。そこでサーバーが暗号化なしの http で応答する場合は、前に http:// を入力します。自宅ではローカルアドレスが選ばれます。外出先で VPN が接続されていればリモートが選ばれ、VPN がオフならオンになるまでウォッチにオフラインのバナーが表示されます。
リバースプロキシの背後にある独自ドメイン。 ローカルURL (LAN)：http://192.168.1.50:8123。リモートURL：https://ha.example.com。動かす前に、Home Assistant がプロキシを信頼するよう設定する必要があります（Trust X-Forwarded-For、Trusted proxies）。そうしないと、リモートのリクエストはすべて 400 になります。リモートアドレスは Wi-Fi をオフにしてテストしてください。ルーターによっては独自ドメインを内側に折り返さないので、自宅で リモート が赤でも、外で失敗するとは限りません。
家を出る前のチェックリスト
自宅での5分が、あとでウォッチを見て首をかしげる事態を防ぎます。
- ローカルURL (LAN) には、自宅でブラウザが使っているサーバーのアドレスだけが入っている。
- リモートURL には、リモートアドレスだけが入っている。
/lovelaceは付けず、必要ならポートを付け、インターネット経由ならhttps://。 - スマートフォンのブラウザで、Wi-Fi をオフにした状態で リモートアドレスを開くと、証明書の警告なしで Home Assistant のログインページが表示される。
- VPN の場合：スマートフォンで VPN が接続を維持するよう設定されている。
- リバースプロキシやトンネルの場合：Home Assistant がそれを信頼しているので、400 にならない。
- 接続 で LAN と リモート が緑、またはアドレスが1つなら 接続済み ✓ と表示される。
- トークンは管理者のもので、両方のアドレスで同じものを使っている。
これで、ウォッチは何もしなくても、自宅ではローカルアドレスを、それ以外の場所ではリモートアドレスを使います。そして、いつか オフライン と表示されても、2行目を見ればどちらを調べればよいかがわかります。スマホから応答がありません なら Bluetooth、Home Assistant に接続できません ならアドレスです。