La respuesta corta
En casa, AmazHA, una app de Home Assistant para relojes Amazfit, solo necesita tu dirección local, como http://192.168.1.50:8123, y no hace falta que nada sea accesible desde fuera. Fuera de casa, tu móvil necesita una dirección remota a la que pueda llegar: Home Assistant Cloud, una VPN como Tailscale o WireGuard, o tu propio dominio con HTTPS. Introduce las dos, y AmazHA elige por sí sola la que funciona.
En casa no necesitas nada más
En la red de casa, la única dirección que necesita AmazHA es la que ya usas para abrir Home Assistant en un navegador en casa. Es el campo URL local (LAN) de los ajustes de AmazHA, y basta por sí solo: sin suscripción, sin VPN, sin dominio y sin abrir ningún puerto en el router.
AmazHA tiene dos campos de dirección en sus ajustes: URL local (LAN) y URL remota. Cualquiera de los dos puede quedarse vacío. Si solo usas el reloj en casa, rellena la local, deja la remota en blanco y listo. Puedes añadir una dirección remota más adelante, el día que quieras que el reloj funcione en la oficina o de vacaciones, sin tocar nada más.
Los campos están en la app Zepp, en Perfil › tu reloj › Apps › AmazHA › Ajustes › Home Assistant. Aparecen una vez desbloqueada la versión completa (un desbloqueo único, sin suscripción): la versión gratuita es una demo en vivo con datos de ejemplo y no se conecta a ningún servidor. El tutorial Conecta Home Assistant muestra en vídeo el paso de la dirección local.
Una dirección local típica se parece a una de estas (son ejemplos, usa la tuya):
http://192.168.1.50:8123
http://homeassistant.local:8123
Si escribes una dirección sin http:// ni https:// en URL local (LAN), AmazHA le pone http:// delante, porque los servidores locales suelen usar http simple.
Por qué es tu móvil el que tiene que llegar a Home Assistant
El reloj nunca habla directamente con Home Assistant. Habla con tu móvil por Bluetooth, y la parte de AmazHA que funciona dentro de la app Zepp en el móvil es la única que envía peticiones a tu servidor. Así que la pregunta «¿puede mi reloj llegar a Home Assistant?» es en realidad «¿puede mi móvil llegar a Home Assistant, ahora mismo, desde donde está?».
Eso tiene algunas consecuencias prácticas:
- El reloj no necesita wifi. Nunca se conecta a una red para AmazHA. Un reloj solo con Bluetooth funciona exactamente igual.
- El móvil tiene que estar cerca, con el Bluetooth activado y la app Zepp en marcha. Si no lo está, el reloj dice Sin conexión · El teléfono no responde, que es un problema distinto de una dirección incorrecta (consulta Cuando algo falla, paso 2).
- La red en la que está el móvil decide qué dirección funciona. Con el wifi de casa, funciona la dirección local. Con datos móviles, en casa de un amigo o con el wifi de un hotel, solo puede funcionar una dirección remota, y solo si el móvil puede llegar a ella desde ahí.
- La VPN tiene que estar conectada en el móvil, no en el reloj. El reloj no sabe nada de ella.
- Tu token se queda en el móvil. Pegas un token de acceso de larga duración una vez, en los ajustes de AmazHA. El reloj solo recibe lo que muestra, por el enlace Bluetooth que ya tiene con el móvil; el token nunca se le envía.
Esto explica una situación confusa: los ajustes dicen Conectado y el reloj dice Sin conexión. Los ajustes solo prueban el camino del móvil a Home Assistant; el reloj también necesita el camino Bluetooth hasta el móvil.
Cómo elige AmazHA la dirección
AmazHA elige la dirección por sí sola, primero la local y luego la remota. No hay ningún interruptor que accionar al salir de casa, y nunca eliges a mano entre los dos campos.
Con una dirección
Con un solo campo relleno, AmazHA simplemente lo usa. No se sondea nada ni se cambia nada. Una configuración solo local funciona en casa y muestra el banner Sin conexión fuera; una configuración solo remota funciona dondequiera que el móvil llegue a esa dirección.
Con las dos direcciones
Con los dos campos rellenos, el móvil pregunta a las dos direcciones a la vez si Home Assistant responde, con un límite de tiempo corto de 1,5 segundos. Si responde la dirección local, AmazHA la usa. Si solo responde la remota, usa esa. La ganadora se recuerda, así que las peticiones siguientes van directamente a ella sin volver a preguntar.
La comprobación es más estricta que «algo ha respondido». Una dirección solo cuenta cuando responde como la API de Home Assistant. Eso importa en las redes de otros: con el wifi de un hotel, 192.168.1.50 puede ser una impresora, la página de un router o un portal cautivo que responde con una página web. AmazHA no lo confunde con tu servidor, así que no se queda atascada en tu dirección local cuando la buena es tu dirección remota.
Al salir de casa y al volver
La dirección recordada se mantiene hasta que falla una petición a ella. Cuando sales de casa y el móvil pierde tu wifi, la siguiente petición a la dirección local falla, AmazHA la olvida, y el intento siguiente vuelve a preguntar a las dos direcciones y acaba en la remota. Mientras la app AmazHA está abierta, el reloj se actualiza cada 8 segundos, así que en la práctica la primera actualización tras el cambio puede fallar y mostrar brevemente el banner Sin conexión, y la siguiente se recupera.
Al volver a casa ocurre lo contrario, de forma más discreta: si tu dirección remota también funciona desde dentro de tu red, AmazHA la sigue usando hasta que falla una petición o vuelves a tocar Conectar. No pasa nada malo cuando ocurre; simplemente la dirección remota sigue funcionando.
Escribir las direcciones
Al rellenar los campos, conviene saber algunos detalles:
- Nada detrás de la dirección del servidor.
http://192.168.1.50:8123, nohttp://192.168.1.50:8123/lovelace. Lo mismo vale para la remota:https://xxxxx.ui.nabu.casa, nohttps://xxxxx.ui.nabu.casa/lovelace. Si dejas una ruta, la dirección responde, pero no como la API de Home Assistant. - El esquema. Si no escribes ningún esquema, URL local (LAN) recibe
http://y URL remota recibehttps://. Escribe túhttp://si una dirección remota es de verdad http simple (una dirección de VPN, por ejemplo). - El puerto. Mantén el puerto si tu dirección lo necesita, como en
:8123. Sin puerto,https://significa el 443. - Un solo token para las dos. Pégalo una vez en Token de acceso de larga duración; sirve para la dirección local y para la remota. Las dos direcciones tienen que llevar al mismo Home Assistant.
El tutorial Conecta Home Assistant cubre el paso de la dirección remota, y el paso 8, la prueba que viene después.
Las opciones de acceso remoto, comparadas
Cualquier dirección remota funciona con AmazHA siempre que el móvil pueda abrirla desde donde está y responda como la API de Home Assistant. Cuál usar es una decisión de Home Assistant, no de AmazHA. Aquí tienes las más habituales, una junto a otra.
| Opción | Qué va en URL remota | Puertos abiertos en casa | HTTPS y certificado | Coste | El móvil necesita |
|---|---|---|---|---|---|
| Home Assistant Cloud de Nabu Casa (pasará a llamarse Home Assistant Link el 2 de diciembre de 2026) | La dirección remota que genera para ti, https://xxxxx.ui.nabu.casa |
Ninguno | Incluido | Suscripción | Nada más |
| VPN, como Tailscale o WireGuard | La dirección de Home Assistant dentro de la VPN | Ninguno con Tailscale; uno para un servidor WireGuard propio | El túnel va cifrado; https solo si lo configuras | Hay opciones gratuitas | La VPN conectada |
| Tu propio dominio a través de un túnel, como Cloudflare Tunnel | https://ha.example.com |
Ninguno | Lo proporciona el túnel | Normalmente un dominio | Nada más |
| Tu propio dominio con un proxy inverso | https://ha.example.com |
Uno (normalmente el 443) | Lo configuras tú, por ejemplo con Let’s Encrypt | Un dominio o un nombre de DNS dinámico gratuito | Nada más |
| Redirección de puertos directa a Home Assistant | https://yourname.duckdns.org:8123 |
Uno | Lo configuras tú | Existe DNS dinámico gratuito | Nada más |
Home Assistant Cloud (pronto Home Assistant Link)
Home Assistant Cloud es el servicio de suscripción gestionado por Nabu Casa; sus suscripciones financian el desarrollo a tiempo completo de Home Assistant. La propia documentación de Home Assistant lo presenta como la opción más sencilla para la mayoría: no necesita abrir puertos en el router, cifra el tráfico y genera para ti una URL remota única.
Para AmazHA, esa URL remota es todo lo que necesitas: cópiala, tal como la muestra Home Assistant, en URL remota, sin nada detrás. Tu token de acceso de larga duración funciona a través de ella igual que en tu dirección local, ya que las dos llevan al mismo servidor.
El 2 de octubre de 2026, Nabu Casa anunció que Home Assistant Cloud pasará a llamarse Home Assistant Link el 2 de diciembre de 2026. El anuncio dice que es la misma suscripción con otro nombre y que no hay que hacer nada. No menciona ningún cambio de dirección, así que hoy no hay nada que cambiar en AmazHA.
Una VPN: Tailscale, WireGuard y otras
Una VPN pone tu móvil, virtualmente, en la red de casa, esté donde esté. La documentación de Home Assistant cita servicios VPN como Tailscale y ZeroTier One como una vía de acceso segura, y señala el inconveniente: la VPN tiene que estar conectada para que nada pueda llegar a Home Assistant desde fuera. Para AmazHA eso significa que la VPN tiene que estar conectada en el móvil. Si se cae, el reloj muestra Sin conexión · Home Assistant no accesible hasta que vuelva.
En URL remota va la dirección que usa tu móvil para Home Assistant mientras la VPN está activa: la dirección del servidor dentro de la VPN, o un nombre que tu VPN resuelve para él. Dos detalles:
- Si tu servidor responde ahí con http simple, escribe
http://delante de la dirección. Sin esquema, AmazHA añadehttps://a la dirección remota, que no respondería. - Con algunas configuraciones de VPN, tu propia dirección de casa,
192.168.1.50, pasa a ser accesible a través del túnel. Entonces la dirección local funciona en cualquier sitio con la VPN activa, y el campo remoto es un respaldo para cuando no lo está.
Una VPN es la opción con menos exposición: nada de tu servidor queda abierto a internet. El precio es que cada dispositivo que necesita Home Assistant, incluido el móvil, tiene que ejecutar el cliente VPN.
Tu propio dominio con HTTPS: un proxy inverso o un túnel
Con tu propio dominio, https://ha.example.com lleva a tu Home Assistant desde cualquier sitio. Dos formas habituales de conseguirlo:
- Un proxy inverso (Nginx, Caddy, Traefik o similar) en casa recibe las peticiones en el puerto 443, gestiona el certificado y pasa las peticiones a Home Assistant. Necesita una redirección de puertos en el router.
- Un túnel, como Cloudflare Tunnel, ejecuta un pequeño conector dentro de tu red que mantiene abierta una conexión saliente con el proveedor, así que no se abre nada en el router. El proveedor sirve tu dominio con un certificado válido.
En los dos casos hay algo delante de Home Assistant que le reenvía las peticiones, y hay que decirle a Home Assistant que confíe en ello. La documentación de Home Assistant es explícita: las peticiones de un proxy inverso se bloquean a menos que actives Trust X-Forwarded-For (confiar en X-Forwarded-For) y añadas el proxy a Trusted proxies (proxies de confianza). Si te lo saltas, todas las peticiones a través del proxy reciben 400 Bad Request (más sobre esto abajo).
Solo una redirección de puertos
Redirigir un puerto del router directamente a Home Assistant es la vía más directa, y la que la documentación de acceso remoto de Home Assistant trata con más cuidado: abrir un puerto sin más no es seguro, el tráfico tiene que ir cifrado y conviene repasar su lista de comprobación de seguridad antes de exponer nada. También señala dos trampas prácticas: muchos proveedores de internet te dan una dirección IP dinámica, por eso sugiere un nombre de DNS dinámico como DuckDNS, y algunos proveedores te ponen detrás de CG-NAT, donde las conexiones entrantes no pueden llegarte en absoluto.
Si eliges esta vía, la dirección remota es tu nombre de DNS dinámico con https y el puerto que has redirigido, por ejemplo https://yourname.duckdns.org:8123. Pon exactamente eso en URL remota.
HTTPS y certificados fuera de casa
Fuera de casa, la regla del tutorial Cuando algo falla es breve: la dirección necesita https con un certificado válido. Hay dos motivos.
El primero es la seguridad. Tu token de acceso de larga duración viaja con cada petición que envía el móvil. Con http simple en internet abierto, cualquiera que esté en el camino puede leerlo y, con él, controlar tu casa.
El segundo es que los móviles rechazan los certificados en los que no confían. Un certificado autofirmado, creado en tu propio servidor, no está firmado por una autoridad en la que el móvil confíe de serie, así que la conexión se rechaza antes de llegar siquiera a Home Assistant. En el reloj se ve como cualquier otro servidor inaccesible. La solución sencilla es un certificado en el que el móvil ya confíe:
- Home Assistant Cloud y los túneles como Cloudflare Tunnel te lo proporcionan.
- Con tu propio dominio o un nombre de DNS dinámico, los certificados de Let’s Encrypt son gratuitos y los móviles confían en ellos.
Hay dos trampas en las que caen quienes configuran HTTPS en el propio Home Assistant, en lugar de en un proxy delante de él:
- La dirección local también cambia. Una vez que Home Assistant sirve HTTPS en su puerto,
http://192.168.1.50:8123simple deja de responder en ese puerto. - Una dirección IP no coincide con el certificado. Un certificado para
ha.example.comno es válido parahttps://192.168.1.50:8123, así que esa dirección local no supera la comprobación del certificado. Un proxy inverso o un túnel para la parte remota, dejando el propio Home Assistant en http simple en casa, evita las dos cosas.
El http simple es normal y correcto para la dirección local en casa. Dentro de una VPN, cuyo túnel ya va cifrado, también puede ser aceptable; en internet abierto, usa https.
Errores habituales y lo que dice el reloj
Cuando algo va mal, el reloj dice qué enlace ha fallado. La tabla recoge los mensajes que tienen que ver con las direcciones, y el que se les parece pero no lo es.
| En el reloj | Qué significa | Solución |
|---|---|---|
| Sin conexión · Home Assistant no accesible · Reintento cada 8 s | El móvil no ha podido llegar a Home Assistant en ninguna de las direcciones que has introducido | Abre la dirección en el navegador del móvil desde donde está; fuera de casa, https con un certificado válido |
| Dirección incorrecta · Responde, pero no es la API de Home Assistant | Algo ha respondido, pero no la API de Home Assistant: normalmente una ruta como /lovelace tras la dirección |
Deja solo la dirección del servidor, sin nada detrás |
| Sin conexión · El teléfono no responde | El reloj no ha podido llegar al móvil; la dirección no tiene nada que ver | Móvil cerca, Bluetooth activado, app Zepp en marcha |
| Se necesita token admin | La dirección funciona, pero el token es de un usuario sin permisos de administrador | Crea un token de larga duración como administrador |
Sin conexión · Home Assistant no accesible
El banner muestra Sin conexión, luego Home Assistant no accesible · Reintento cada 8 s y, debajo, un código corto que le dice al soporte exactamente qué ha fallado. Las causas habituales: estás fuera y solo tienes una dirección local; la VPN no está conectada en el móvil; la dirección remota funciona en casa pero no desde fuera; el móvil no confía en el certificado; o el propio Home Assistant está caído o reiniciándose. La solución empieza siempre igual: abre la dirección en el navegador del móvil, como se explica más abajo. El tutorial Cuando algo falla, paso 3, muestra este mensaje en vídeo.
Dirección incorrecta
Dirección incorrecta significa que la dirección ha respondido, pero con una página web en lugar de la API de Home Assistant. Casi siempre la dirección lleva una ruta, normalmente copiada de la barra del navegador: https://ha.example.com/lovelace/0 en lugar de https://ha.example.com. Quita todo lo que haya tras la dirección del servidor (y su puerto). En los ajustes de AmazHA, la prueba de conexión dice lo mismo con sus propias palabras: la dirección responde, pero no con la API de Home Assistant, y pone el ejemplo de una dirección de Home Assistant Cloud con y sin /lovelace. Consulta Cuando algo falla, paso 4. Con menos frecuencia, la dirección lleva a otra cosa, como la página de administración de un router.
400 Bad Request detrás de un proxy inverso
Si tu dirección remota pasa por un proxy inverso o un túnel y todas las peticiones vuelven con 400 Bad Request, Home Assistant está rechazando el proxy. Su integración HTTP rechaza cualquier petición que lleve una cabecera de reenvío cuando no se le ha dicho que confíe en proxies inversos, o cuando la dirección del proxy no está en su lista de confianza, y en los dos casos la respuesta es un 400. El registro de Home Assistant nombra la dirección de la que llegó la petición; en el segundo caso dice «Received X-Forwarded-For header from an untrusted proxy», seguido de esa dirección.
En AmazHA, Conectar muestra Error 400 con una sola dirección, o un punto rojo junto a Remota con las dos.
La solución está del lado de Home Assistant. En las versiones actuales, los ajustes del servidor HTTP están en la interfaz de usuario: en Configuración › Sistema › Red, activa Trust X-Forwarded-For y añade la dirección o la red del proxy en Trusted proxies. Las versiones antiguas usan YAML en configuration.yaml (la dirección de abajo es un ejemplo; usa la de tu proxy):
http:
use_x_forwarded_for: true
trusted_proxies:
- 192.168.1.10
La documentación de la integración HTTP de Home Assistant tiene los detalles de cada versión. Reinicia Home Assistant si tu versión lo necesita y vuelve a tocar Conectar.
Sin conexión · El teléfono no responde
Este no tiene nada que ver con las direcciones. El reloj no ha podido llegar al móvil por Bluetooth, así que el móvil ni siquiera ha tenido ocasión de probar con Home Assistant. Ten el móvil cerca, con el Bluetooth activado y la app Zepp en marcha (Cuando algo falla, paso 2). Cambiar las direcciones no lo arreglará.
El ajuste de URL externa del propio Home Assistant
Home Assistant tiene sus propios ajustes de Home Assistant URL (URL de Home Assistant), con un campo Internet y otro Local network (red local), en Configuración › Sistema › Red. Le dicen a Home Assistant y a sus propias apps dónde está. AmazHA no los lee: solo usa las dos direcciones escritas en sus propios ajustes. Si has cambiado tu URL externa en Home Assistant y el reloj no la ha seguido, ese es el motivo. Copia la nueva dirección en URL remota.
Prueba primero desde el navegador del móvil
Antes de cambiar nada en AmazHA, abre la dirección en el navegador del mismo móvil, desde el mismo sitio. Es la prueba más rápida que hay, porque sigue el mismo camino que AmazHA: el móvil, su red actual y tu dirección.
- Desactiva el wifi del móvil si estás probando la dirección remota desde casa, para que salga de verdad por los datos móviles. Activa la VPN si la dirección remota la necesita.
- Escribe exactamente la dirección que has introducido en AmazHA, por ejemplo
https://ha.example.com. - Lee el resultado.
| El navegador muestra | Lo que te dice |
|---|---|
| La página de inicio de sesión de Home Assistant | La dirección y el certificado están bien: el problema está en otro sitio (ruta, token, Bluetooth) |
| Un aviso de certificado | El móvil no confía en el certificado; AmazHA no puede usar esta dirección tal como está |
| Nada, o «no se puede acceder a esta página» | El móvil no puede llegar a la dirección desde esta red |
| 400 Bad Request | Un proxy inverso en el que Home Assistant todavía no confía |
| Otra página (router, proveedor, página por defecto del proxy) | La dirección lleva a otro sitio |
Para la dirección local, haz lo mismo con el wifi activado, en casa. Si el navegador llega a la página de inicio de sesión y AmazHA sigue fallando, comprueba que el campo contiene solo la dirección del servidor, sin nada detrás, y el mismo esquema que ha usado el navegador.
También puedes añadir /api/ a la dirección en el navegador. Home Assistant responde con un error de autenticación, porque el navegador no envía ningún token: eso demuestra que la dirección lleva a la API de Home Assistant y no a otra página. En AmazHA, escribe la dirección sin /api/.
La prueba de conexión en AmazHA: cómo leer LAN y Remota
Conectar, en los ajustes de AmazHA, prueba las direcciones desde el móvil y te dice lo que ha encontrado. Después de tocarlo, el resultado aparece en unos segundos:
- Con una dirección: Conectado ✓ cuando Home Assistant responde, Inaccesible cuando no responde nada, Error seguido de un número cuando algo ha respondido con un error HTTP (por ejemplo Error 400 o Error 401), y Responde, pero no es Home Assistant cuando la dirección responde con algo que no es la API.
- Con las dos direcciones: un resultado por dirección, LAN y Remota, cada uno con un punto de color: verde cuando Home Assistant responde ahí, naranja cuando algo responde pero no es Home Assistant, rojo cuando falla.
Léelo teniendo en cuenta dónde está el móvil. En casa, un Remota en rojo puede ser normal (un dominio que no vuelve hacia dentro de tu red, una VPN desactivada) o un problema real, así que vuelve a probar con el wifi desactivado. Fuera de casa, un LAN en rojo es lo esperado; ahí solo importa Remota. Las dos en verde, probadas una vez en casa y otra con datos móviles, es la configuración que te acompaña a todas partes. El paso 8 del tutorial Conecta Home Assistant muestra la pantalla.
Cuando la dirección funciona pero el token es de un usuario sin permisos de administrador, Conectar lo indica bajo el resultado. Es un problema del token, no de la dirección: la prueba de la dirección sale bien, pero el reloj no puede cargar tus habitaciones hasta que el token sea de un administrador.
Cuatro configuraciones, paso a paso
Los mismos dos campos sirven para casas muy distintas. Cuatro ejemplos, con direcciones de ejemplo:
Un piso, solo para usar en casa. URL local (LAN): http://192.168.1.50:8123. URL remota: vacía. El reloj funciona con el wifi de casa; fuera muestra Sin conexión · Home Assistant no accesible, que es lo esperado. Conectar indica Conectado ✓ en casa.
Home Assistant Cloud. URL local (LAN): http://192.168.1.50:8123. URL remota: https://xxxxx.ui.nabu.casa. En casa, AmazHA usa la dirección local; con datos móviles pasa sola a la dirección de Home Assistant Cloud. Conectar muestra LAN y Remota, las dos en verde en casa, porque la dirección de la nube también funciona desde dentro.
Una VPN en el móvil. URL local (LAN): http://192.168.1.50:8123. URL remota: la dirección del servidor dentro de la VPN, con http:// escrito delante si el servidor responde ahí con http simple. En casa gana la dirección local. Fuera, con la VPN conectada, gana la remota; con la VPN desactivada, el reloj muestra el banner Sin conexión hasta que vuelva a activarse.
Tu propio dominio detrás de un proxy inverso. URL local (LAN): http://192.168.1.50:8123. URL remota: https://ha.example.com. Para que funcione, Home Assistant tiene que confiar en el proxy (Trust X-Forwarded-For, Trusted proxies), o todas las peticiones remotas recibirán un 400. Prueba la dirección remota con el wifi desactivado: algunos routers no devuelven tu propio dominio hacia dentro, así que un Remota en rojo en casa no siempre significa que falle fuera.
Una lista de comprobación antes de salir de casa
Cinco minutos en casa te ahorran una mirada de desconcierto al reloj más tarde:
- URL local (LAN) contiene solo la dirección del servidor, la que usa tu navegador en casa.
- URL remota contiene solo la dirección remota: sin
/lovelace, con el puerto si lo necesita y conhttps://por internet. - El navegador del móvil abre la dirección remota con el wifi desactivado y muestra la página de inicio de sesión de Home Assistant, sin ningún aviso de certificado.
- Si es una VPN: la VPN está configurada para seguir conectada en el móvil.
- Si es un proxy inverso o un túnel: Home Assistant confía en él, así que no hay 400.
- Conectar muestra LAN y Remota en verde, o Conectado ✓ con una sola dirección.
- El token es de un administrador, y es el mismo para las dos direcciones.
Con eso hecho, el reloj usa tu dirección local en casa y la remota en cualquier otro sitio, sin que tengas que hacer nada. Y si un día muestra Sin conexión, la segunda línea te dice hacia qué lado mirar: El teléfono no responde es el Bluetooth, Home Assistant no accesible es la dirección.