Historial de versiones - MiWiFi XiaoHack Edition

📝 Changelog — Integración MiWiFi

📦 Versión v3.5.5 – 2026-02-01

✅ Correcciones y mejora de la estabilidad (en comparación con la versión 3.5.4)

• ⏱️ Se corrigieron los largos tiempos de espera del actualizador cuando la WAN está caída (configuraciones de AP/Bridge/Repetidor)
• Evita que los ciclos del coordinador tarden aproximadamente 110 segundos cuando la WAN informa repetidamente:
• link=0, status=0, uptime=0, ipv4.ip=""
• Se ha añadido un tiempo de espera estricto al sondeo de la WAN y una salida anticipada segura cuando la WAN está claramente caída, para que la topología y los dispositivos sigan actualizándose con normalidad.

• 🌐 Se ha ajustado el análisis de la WAN para evitar el falso mensaje de "WAN no disponible" en los firmwares PPPoE
• Es posible que algunas configuraciones PPPoE informen de campos parciales o vacíos de forma intermitente.
• Se ha mejorado la detección de caídas de la WAN y se han añadido mecanismos de reserva más seguros para que los sensores de la WAN no se desconecten incorrectamente.

• 🧯 Se han reforzado las reglas NAT para evitar el bloqueo de los ciclos de actualización.
• Algunos modelos/firmwares no exponen los puntos finales de reenvío de puertos esperados (ruta predeterminada + ruta de reserva).
• Se agregó un tiempo de espera estricto y un tiempo de enfriamiento después de los fallos para evitar reintentos repetidos/spam durante los ciclos de actualización.

• 🔐 Se solucionó el error de "token no válido" durante la actualización de las reglas NAT
• Evita que el error LuciRequestError: Invalid token interrumpa las tareas de actualización del coordinador.
• La recuperación de reglas NAT ahora falla de forma controlada en caso de problemas con los tokens y evita excepciones de tareas innecesarias.

• 🧩 Se corrigió la regresión de mutación de datos del actualizador (se conserva la referencia a __HTML_PLACEHOLDER_0__)
• Se eliminaron patrones inseguros como data = data o {} en los pasos de preparación que pueden crear un nuevo diccionario cuando data está vacío.
• Garantiza que los atributos preparados se conserven correctamente a lo largo del proceso de actualización y evita efectos secundarios como la "falta de entidades".

• 🧱 Mayor resistencia frente a cargas útiles inconsistentes/vacías
• Manejo defensivo para campos WAN faltantes/vacíos y puntos finales no compatibles para mantener la capacidad de respuesta del actualizador.

⚙️ Mejoras (en comparación con la versión 3.5.4)

• 🧠 Comportamiento más inteligente cuando las funciones no están disponibles
• Cuando la WAN no es aplicable (el enrutador está detrás de otra puerta de enlace), la integración la trata como "inactiva/no disponible" sin penalizar al resto del proceso de actualización.
• Las reglas NAT se obtienen de forma oportunista en lugar de saturar los puntos finales que están fallando o no son compatibles.

• 🧼 Canal de actualización más limpio en condiciones degradadas
• Se reduce el "impacto en cascada" cuando un único punto final es lento o no está disponible.
• Mayor estabilidad general en entornos mixtos (enrutador principal + nodos de malla + puerta de enlace externa).

✅ Compatibilidad (vs v3.5.4)

• 🌐 Mejor compatibilidad con routers que operan detrás de otra puerta de enlace
• Es común en escenarios de puerta de enlace ISP/4G donde el lado Xiaomi/AP mantiene la WAN en un estado "inactivo".

• 🧱 Mayor tolerancia a firmwares sin API de reenvío de puertos
• Evita fallos repetidos en dispositivos que no exponen los puntos finales NAT esperados.

📘 Cómo actualizar

1. Actualizar los archivos de componentes personalizados (HACS o manual).
2. Reiniciar Home Assistant.
3. Si utiliza reglas NAT:

• Confirma que sensor.miwifi_nat_rules se carga normalmente y ya no realiza reintentos innecesarios cuando no es compatible.

1. Si experimentaste entidades faltantes en las compilaciones RC de la versión 3.5.5:

• Tras el reinicio, las entidades deberían volver a llenarse con normalidad una vez que self.data se haya rellenado correctamente de nuevo.

ℹ️ Información adicional

• Si su router está en modo AP/Puente/Repetidor, es normal que vea la WAN como "inactiva".
• Es posible que las reglas NAT no sean compatibles con algunos firmwares/modelos; la integración se degrada gradualmente en lugar de reintentar de forma agresiva.

💖 Soporte y donaciones

Si esta integración le resulta útil y desea apoyar su desarrollo continuo:

• 💸 Wise
• 💸 PayPal

🔁 Resumen de cambios (v3.5.4 → v3.5.5)

📝 Changelog — Integración MiWiFi

📦 Versión v3.5.4 – 2026-01-28

✅ Correcciones y estabilidad

• 🔁 Se corrigieron los bucles repetidos de “Error inesperado al obtener los datos del actualizador de MiWiFi”
• Se implementó un envoltorio de solicitud seguro para manejar la condición común de httpx "el cliente ha sido cerrado".
• Las solicitudes se reintentan una vez después de recrear el cliente HTTP a través de la fábrica de clientes compartidos de Home Assistant, lo que evita el exceso de registros y los fallos repetidos del coordinador.

• 🧼 Se ha mitigado el posible aumento del consumo de memoria a largo plazo relacionado con los clientes HTTP no administrados.
• Ahora, todas las solicitudes HTTP reutilizan de forma consistente el cliente httpx compartido de Home Assistant (get_async_client) a través de un client_factory, evitando la creación de clientes ad hoc.
• Un usuario informó que este cambio corrigió un grave problema de aumento del consumo de memoria que saturaba su sistema aproximadamente cada 48 horas después de actualizar a la versión anterior (lo que sugiere que la integración estaba contribuyendo al aumento del uso de memoria).

• 🔐 Estabilidad de protocolo mejorada (AUTO → HTTP/HTTPS) sin afectar las configuraciones heredadas
• La detección de protocolos sigue siendo compatible, mientras que las solicitudes ahora se ejecutan a través del envoltorio que permite reintentos seguros.

• 🙌 Contribución de la comunidad
• Gracias a @pacorola por las mejoras realizadas en la versión principal y las pruebas en el mundo real que ayudaron a identificar y validar esta solución.

⚙️ Mejoras

• 🧩 Capa de red más resistente
• El cliente Luci puede recuperarse de estados de cliente cerrado durante recargas/reconexiones recreando el cliente administrado por HA bajo demanda.

✅ Compatibilidad

• No se esperan cambios importantes.
• Funciona con las configuraciones AUTO/HTTP/HTTPS existentes y mantiene intactas las asignaciones de puntos finales actuales.

📘 Cómo actualizar

1. Actualizar los archivos de integración (HACS o manual).
2. Reiniciar Home Assistant.
3. (Recomendado) Compruebe los registros después de reiniciar para confirmar que el actualizador ya no envía mensajes no deseados:

• “Error inesperado al obtener los datos de actualización de MiWiFi”

1. Si anteriormente experimentó un aumento en el uso de la memoria, supervise el uso de la memoria HA durante los próximos días para confirmar su estabilidad.

ℹ️ Información adicional

• Si el firmware de su enrutador es inestable o se reinicia con frecuencia, la nueva lógica de cliente con reintentos seguros ayuda a evitar que los errores transitorios de cliente cerrado se conviertan en fallos repetidos.

💖 Soporte y donaciones

Si esta integración le resulta útil y desea apoyar su desarrollo continuo:

• 💸 Wise
• 💸 PayPal

🔄 Resumen de cambios

📝 Changelog — Integración MiWiFi

📦 Versión v3.5.3 – 2026-01-25

✅ Correcciones y estabilidad

• 🧩 Se corrigieron las entidades/dispositivos device_tracker duplicados en las configuraciones de Mesh
• Los rastreadores de clientes ahora utilizan un ID único estable basado únicamente en la dirección MAC del cliente, y no en el entry_id del enrutador.
• Evita que HA cree duplicados *_2, *_3 cuando un dispositivo se desplaza entre nodos.

• 🧱 Se ha corregido la advertencia de Home Assistant sobre referencias __HTML_PLACEHOLDER_0__ no válidas (HA 2025.12+)
• Garantiza que el dispositivo enrutador/nodo al que se hace referencia exista en el registro de dispositivos antes de vincular los clientes a través de via_device.
• Elimina: device_registry.async_get_or_create que hace referencia a un via_device inexistente.

• 🧹 Mejora en la limpieza/migración de sensores de clientes heredados
• Elimina automáticamente los esquemas unique_id antiguos de sensores por dispositivo que causaban duplicados en los enrutadores Mesh.

• ⚙️ Se ha corregido el error que impedía que la opción "Crear sensores de dispositivo" se aplicara correctamente.
• Ahora, esta opción se respeta al iniciar el sistema y después de reiniciarlo, lo que evita comportamientos inesperados en los que se omitían sensores incluso cuando estaban habilitados.

⚙️ Mejoras

• 📡 Los sensores por dispositivo ahora son compatibles con la red Mesh y ofrecen una configuración consistente.
• Cuando “Crear sensores de dispositivo” está habilitado:
• Los sensores se crean utilizando un identificador único estable basado en MAC (para que no se dupliquen al cambiar de red).
• Los sensores se crean como deshabilitados por defecto (activados opcionalmente), de acuerdo con las mejores prácticas.
• Cuando está discapacitado:
• Los sensores existentes por dispositivo se eliminan automáticamente.

• 🔗 Se agregaron/estandarizaron los datos de “Conectado a través de” para la visibilidad de la malla
• Las entidades de seguimiento de dispositivos exponen los datos de "conexión a través de nodo/enrutador" para que el panel siempre pueda identificar el nodo actual, incluso si los sensores del dispositivo no están habilitados.

• 🧰 Se conservaron los registros de depuración clave para la resolución de problemas
• Se restauró/mantuvo la depuración de inicio del sensor que imprime is_main, device_sensors_enabled y el recuento de dispositivos para diagnosticar rápidamente casos límite.

✅ Compatibilidad

• ✅ Compatible con Home Assistant 2026.1.0+
• ✅ Compatible con versiones futuras de Home Assistant 2025.12+ y cambios en la validación del registro de dispositivos via_device.
• 🧩 Diseñado para despliegues en malla (multienrutador): los clientes se desplazan sin dispositivos/entidades duplicados.

📘 Cómo actualizar

1. Reemplace todos los archivos dentro de custom_components/miwifi/ con el contenido de esta versión.
2. Reiniciar Home Assistant.
3. Si anteriormente tenía duplicados:

• Comprueba Ajustes → Dispositivos y servicios → Entidades para ver si quedan entradas antiguas (esta versión eliminará automáticamente la mayoría de ellas).

1. Si desea sensores por dispositivo:

• Habilite la opción “Crear sensores de dispositivo” en las opciones de integración.
• A continuación, active selectivamente los sensores de cliente que realmente desee (están desactivados por defecto).

ℹ️ Información adicional

• Los dispositivos cliente en la red Mesh ahora deberían aparecer una sola vez en Home Assistant, aunque seguirán mostrando a través de qué nodo están conectados.
• Esta versión se centra en la estabilidad y la identidad de las entidades. El siguiente paso es alinear el panel MiWiFi para que muestre la asignación de nodos y las entidades de los dispositivos de forma coherente.

💖 Soporte y donaciones

Si esta integración le resulta útil y desea apoyar su desarrollo continuo:

• 💸 Wise
• 💸 PayPal

🔎 Resumen de cambios (v3.5.2 → v3.5.3)

📝 Changelog — Integración MiWiFi

📦 Versión v3.5.2 – 2026-01-18

✅ Correcciones y estabilidad

• 🧯 Se corrigieron las cancelaciones de configuración de entrada (AX6000 / puntos finales LUCI lentos)
• Error resuelto:
• Configuración de la entrada de configuración... cancelada
• asyncio.exceptions.CancelledError
• Causa principal: ciertos firmwares pueden quedarse bloqueados en wifi_macfilter_info durante la primera actualización, lo que provoca tiempos de espera agotados en el arranque de Home Assistant.
• Corrección: se agregó soporte para tiempo de espera por llamada en las solicitudes LUCI y se impuso un tiempo de espera corto para macfilter_info() para que falle rápidamente y evite la cancelación del arranque.

• 🧩 Se solucionó el problema del panel MiWiFi que mostraba 0 dispositivos conectados (device_tracker no agregaba entidades)
• Error resuelto:
• Error al agregar la entidad device_tracker.miwifi_* ...
• AttributeError: el objeto 'MiWifiDeviceTracker' no tiene el atributo '__attr_name'
• Causa raíz: inicialización faltante/incorrecta de _attr_name a la que hace referencia device_info durante la adición de la entidad.
• Corrección: se garantiza que _attr_name siempre esté configurado y se haga referencia a él de forma consistente, lo que restablece la creación estable de la entidad device_tracker.

• 🔁 Se evitan los sensores de cliente duplicados en escenarios de itinerancia en malla
• Problema resuelto:
• Los sensores se crean como sensor.<name> y sensor.<name>_2 dependiendo del nodo de malla al que se conecta el cliente.
• Causa principal: la identidad del sensor por dispositivo se derivaba del contexto de entrada del enrutador o del entity_id basado en el nombre, lo que provocaba colisiones cuando los clientes se desplazaban entre nodos.
• Arreglar:
• El ID único del sensor del dispositivo ahora se deriva de MAC + clave del sensor, independientemente de la entrada del enrutador.
• entity_id ahora es estable: sensor.miwifi_<mac>_<key>.

• 🧰 Mejoras de la PR #239 (fusionadas con los ajustes de XiaoHack)
• Se han integrado correcciones y mejoras de estabilidad de la solicitud de extracción n.° 239, con adaptaciones mínimas y seguras para la compatibilidad en el código base de XiaoHack.
• Se ha garantizado que el nuevo comportamiento no genere problemas en las instalaciones existentes, al tiempo que se mejora la fiabilidad en las versiones más recientes de Home Assistant.

⚙️ Mejoras

• 🔧 Nuevo interruptor global para sensores de cliente (desactivado por defecto)
• Se agregó enable_device_sensors (valor predeterminado: false) en las opciones de integración.
• Comportamiento:
• Cuando está DESACTIVADO: no se crean sensores de cliente por dispositivo (y se eliminan los duplicados heredados del enrutador principal).
• Cuando está ACTIVADO: los sensores por dispositivo se crean solo desde el enrutador principal para evitar duplicados en la red mallada y permanecen deshabilitados de forma predeterminada en el registro de entidades para que los usuarios habiliten solo lo que deseen.

• 🧭 Se han añadido etiquetas de interfaz de usuario para la nueva opción
• Se ha añadido una etiqueta de opción descriptiva en strings.json para que la configuración sea visible y comprensible desde la interfaz de usuario.

✅ Compatibilidad

• ✅ Home Assistant 2026.1+ (comportamiento de cancelación de Python 3.13 / tiempos de espera de arranque)
• ✅ Entornos de malla (identidad estable para clientes itinerantes)
• ✅ Enrutadores con puntos finales LUCI parciales/lentos (comportamiento de fallo rápido para puntos finales problemáticos)

📘 Cómo actualizar

HACS (recomendado)

1. HACS → Integraciones → MiWiFi XiaoHack Edition
2. Actualizar a v3.5.2
3. Reiniciar Home Assistant

Manual

1. Reemplace /config/custom_components/miwifi/ con la versión v3.5.2.
2. Reiniciar Home Assistant

Opcional (sensores del cliente)

• Ajustes → Dispositivos y servicios → MiWiFi → Configurar
• Habilitar: Crear sensores de dispositivo (clientes)

Nota: los sensores de cliente permanecen deshabilitados de forma predeterminada en el Registro de entidades. Habilite solo las entidades que desee.

ℹ️ Información adicional

• Valores predeterminados recomendados:
• Mantén enable_device_sensors = false a menos que necesites explícitamente sensores por dispositivo.
• Migración/limpieza:
• Los duplicados de sensores heredados por dispositivo vinculados al contexto de entrada del enrutador se eliminan automáticamente del enrutador principal.

💖 Soporte y donaciones

Si esta integración le resulta útil y desea apoyar su desarrollo continuo:

• 💸 Wise
• 💸 PayPal

🙌 Créditos

• Gracias a @pacorola por contribuir con las mejoras incluidas a través de PR #239.

🔎 Resumen de cambios

📝 Changelog — Integración MiWiFi

📦 Versión v3.5.1 – 2026-01-04

✅ Correcciones y estabilidad

• 🧵 Solucionado el problema de advertencia de "bloqueo de llamada" de Home Assistant (SSL / certifi)
• Advertencia resuelta:
• Se ha detectado una llamada bloqueante a load_verify_locations... dentro del bucle de eventos
• Causa raíz: creación directa de httpx.AsyncClient() dentro del bucle de eventos en MiWifiPanelUpdate.async_release_notes().
• Corrección: se cambió al cliente compartido recomendado por Home Assistant (get_async_client(self.hass)) para evitar bloquear SSLContext.load_verify_locations. #227

• 🐞 Se corrigió el error __HTML_PLACEHOLDER_0__ al agregar entidades
• Advertencia resuelta:
• RuntimeWarning: la corrutina 'EntityPlatform.async_add_entities' nunca se esperó
• Causa raíz: Se llamó a platform.async_add_entities(to_add) desde un contexto @callback (no asíncrono) en sensor.py.
• Solución: programar de forma segura la corrutina mediante hass.async_create_task(...) cuando sea necesario.

⚙️ Mejoras

• 🧩 Alternativas que garantizan la compatibilidad
• Se ha añadido una alternativa segura cuando homeassistant.helpers.httpx_client.get_async_client no está disponible (en versiones muy antiguas de Home Assistant), conservando el comportamiento anterior sin romper las mejores prácticas asíncronas modernas.

✅ Compatibilidad

• ✅ Home Assistant: compatible con las versiones actuales donde se detectan llamadas que bloquean el bucle de eventos y donde EntityPlatform.async_add_entities es asíncrono.
• 🛡️ Compatible con versiones anteriores: incluye lógica de reserva para instalaciones antiguas.

📘 Cómo actualizar

HACS (recomendado)

1. HACS → Integraciones → MiWiFi XiaoHack Edition
2. Actualizar a v3.5.1
3. Reiniciar Home Assistant

Manual

1. Reemplace /config/custom_components/miwifi/ con la versión v3.5.1
2. Reiniciar Home Assistant

ℹ️ Información adicional

• No se han realizado cambios de configuración.
• Sin migraciones.
• Esta versión se centra en eliminar las advertencias de asincronía que pueden afectar la estabilidad y el rendimiento en entornos modernos de Home Assistant.

💖 Soporte y donaciones

Si esta integración le resulta útil y desea apoyar su desarrollo continuo:

• 💸 Wise
• 💸 PayPal

🔎 Resumen de cambios