Historial de versiones - MiWiFi XiaoHack Edition

📝 Changelog — Integración MiWiFi

📦 Versión v3.5.9 – 2026-03-25

🆕 Modelo compatible

• ✅ Se agregó compatibilidad con el nuevo modelo de enrutador RD03V2 #305

✅ Correcciones y estabilidad

• ⏱️ Se agregó un tiempo de espera a la verificación de la versión del panel #303
• Evita que las comprobaciones de versión del panel se queden bloqueadas indefinidamente cuando la fuente remota es lenta o no está disponible temporalmente.
• Mejora la capacidad de respuesta general y evita bloquear los flujos de actualización/validación de versiones relacionados.

⚙️ Mejoras

• 📦 Compatibilidad con modelos ampliada
• Se ha añadido la detección y compatibilidad con RD03V2 para mejorar la compatibilidad con las variantes más recientes de routers Xiaomi.

✅ Compatibilidad

• ✅ Compatible con configuraciones de router Xiaomi estándar.
• ✅ Se ha añadido compatibilidad con las variantes de enrutador RD03V2.

📘 Cómo actualizar

1. Reemplace su carpeta custom_components/miwifi/ con el contenido de esta versión.
2. Reiniciar Home Assistant.

ℹ️ Información adicional

• PR fusionada: #303 (feat: agregar tiempo de espera a la verificación de versión del panel)
• PR fusionado: #305 (se agrega soporte para el modelo de enrutador RD03V2)

💖 Soporte y donaciones

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

• 💸 Wise
• 💸 PayPal

📝 Changelog — Integración MiWiFi

📦 Versión v3.5.8 – 2026-02-22

🆕 Modelo compatible

• ✅ Se agregó compatibilidad con el nuevo modelo de enrutador RP04 #301

✅ Correcciones y estabilidad

• 🧩 Se corrigió la detección de “modo” en las variantes de firmware que devuelven __HTML_PLACEHOLDER_0__
• Cuando falla el punto final principal qnetwork/get_netmode, la integración recurre a netmode().
• Algunos firmwares devuelven el campo como netmode (y omiten mode), lo que puede interrumpir la lógica posterior que espera mode.
• Ahora normalizamos la carga útil de reserva: si netmode existe y mode no está presente, lo reflejamos (mode = netmode) para mantener una forma de respuesta consistente.

⚙️ Mejoras

• No hay otros cambios en esta versión.

✅ Compatibilidad

• ✅ Compatibilidad mejorada con firmwares de proveedores/personalizados que exponen __HTML_PLACEHOLDER_0__ en lugar de __HTML_PLACEHOLDER_1__ en la API de reserva.

📘 Cómo actualizar

1. Reemplace su carpeta custom_components/miwifi/ con el contenido de esta versión.
2. Reiniciar Home Assistant.

ℹ️ Información adicional

• PR fusionado: #300 (“convertir el campo netmode al campo mode para compatibilidad”)
• Gracias a @Mythologyli por la contribución.

📝 Changelog — Integración MiWiFi

📦 Versión v3.5.7 – 2026-02-11

✅ Correcciones y estabilidad

• 🧱 Se corrigieron los fallos de CB0401V2 causados por __HTML_PLACEHOLDER_0__ / cargas útiles de topología no válidas
• Es posible que algunos firmwares de proveedores devuelvan estructuras inesperadas (incluido null) en llamadas relacionadas con la topología.
• El manejo de la topología ahora está estrictamente normalizado para evitar errores de NoneType durante la primera actualización.

• 🧮 Se corrigieron los fallos de análisis de __HTML_PLACEHOLDER_0__ / cadena vacía durante la actualización
• Análisis reforzado para métricas de WAN/velocidad cuando los enrutadores informan temporalmente cadenas vacías ("") mientras los enlaces están negociando o inactivos.
• Los parámetros downspeed y upspeed del dispositivo ahora se analizan de forma segura y, si no son válidos, se establecen por defecto en 0.0.

• 🧯 Se corrigió el fallo de configuración de CB0401V2 cuando los puntos finales restringidos devolvían datos que no eran JSON
• Los firmwares de los proveedores pueden devolver respuestas HTML/vacías para ciertos puntos finales (por ejemplo, control de LED).
• Estas llamadas ahora se omiten o se tratan como no críticas, por lo que la integración siempre se carga.

• 🧹 Reducción del spam en los registros de firmware de los proveedores
• Se han añadido tiempos de espera y mecanismos de reserva seguros para evitar la saturación de reintentos y las respuestas 404/inválidas repetidas.

• 🚦 Se solucionó el problema por el cual el servicio Block Device dejaba de estar disponible cuando se agotaba el tiempo de espera de __HTML_PLACEHOLDER_0__.
• Algunos firmwares pueden agotar el tiempo de espera en wifi_macfilter_info (punto final de lectura) aunque set_mac_filter (punto final de escritura) funcione.
• El servicio Bloquear/Desbloquear ya no depende de la disponibilidad de macfilter_info para decidir la compatibilidad, evitando así errores falsos de "no es compatible".
• Tras aplicar un bloqueo/desbloqueo, la integración actualiza el mapa de filtros MAC almacenado en caché para que el estado internet_blocked se mantenga constante incluso durante los periodos de espera/tiempo de espera.

• 🔄 Se solucionó el problema por el cual el estado __HTML_PLACEHOLDER_0__ no persistía después de actualizar/navegar (al activar/desactivar la conexión WAN en las tarjetas de dispositivo)
• Algunos firmwares informan del control de acceso WAN a través de /api/misystem/devicelist usando authority.wan (0=bloqueado, 1=permitido).
• Ahora, la integración mapea __HTML_PLACEHOLDER_0__ → __HTML_PLACEHOLDER_1__ de forma consistente durante la preparación de la lista de dispositivos, de modo que la interfaz de usuario mantiene el estado correcto de bloqueo/desbloqueo después de actualizar o cambiar de pantalla.
• Se agregó un mecanismo de reserva resiliente en la configuración del dispositivo para que el estado de acceso WAN nunca se restablezca a "permitido" de forma predeterminada cuando el valor está presente en las cargas útiles del enrutador.

⚙️ Mejoras

• 📡 Compatibilidad con CB0401V2 (Xiaomi 5G CPE Pro v2) (firmware Magenta/Telekom)
• Nueva detección de perfil CPE (cpe_profile: CB0401V2) para evitar fallos por “modelo no compatible”.
• Se agregaron puntos finales CPE dedicados:
• xqdtcustom/get_mobile_net_info (señal + uso + IPv4 en una sola llamada)
• xqdtcustom/cpe_detect (estado de la SIM + reintentos)
• xqdtcustom/newstatus (alternativa de hardware/MAC)
• xqmobile/get_msgbox_count (contador de SMS)

• 🌐 Respaldo de WAN móvil en CB0401V2
• Si los puntos finales WAN clásicos no están disponibles, la WAN puede recurrir a los datos IPv4 móviles de las llamadas CPE.

• 📊 Métricas móviles normalizadas para sensores limpios
• Uso/límite de datos normalizado a *_gb (flotante)
• RSRP/SNR de 5G normalizado a valores flotantes siempre que sea posible.

• 🧾 Sensores de diagnóstico solo para CB0401V2
• Tipo de enlace móvil, operador, IPv4 móvil
• RSRP 5G / SNR 5G
• Uso de datos (GB) / Límite de datos (GB)
• Estado de la SIM + Reintentos de PIN/PUK
• Número de SMS (cuando esté disponible)

Nota: El uso de datos en CB0401V2 solo se muestra cuando flowstatEnable=1 está habilitado en la interfaz de usuario del enrutador.

✅ Compatibilidad

• ✅ Sin cambios de comportamiento para los routers Xiaomi estándar
• Los puntos finales y las omisiones de CPE se aplican solo cuando se detecta CB0401V2.
• Los modelos normales mantienen el mismo flujo de actualización y las mismas entidades.

• 🧩 Compatibilidad mejorada con la importación de Home Assistant
• Evita que se produzcan fallos en la clase de dispositivo que no estén disponibles en algunas compilaciones de alta disponibilidad (lo que previene fallos durante la importación).

📘 Cómo actualizar

1. Descarga / obtén la última versión preliminar de MiWiFi XiaoHack Edition v3.5.7rc3.
2. Reemplaza tu carpeta custom_components/miwifi/ con la nueva versión.
3. Reiniciar Home Assistant.
4. (Opcional) Habilite temporalmente los registros de depuración para validar:

• No se producen fallos con NoneType / float('') durante la primera actualización.
• Los puntos finales CB0401V2 no envían errores 404/que no sean JSON de forma masiva.
• El servicio de bloqueo/desbloqueo sigue funcionando incluso si macfilter_info agota el tiempo de espera.

ℹ️ Información adicional

• Esta es una compilación RC centrada en CB0401V2 (variantes de firmware del proveedor) y análisis defensivo.
• Si realiza pruebas en CB0401V2, comparta las cargas útiles sanitizadas para:
• xqdtcustom/get_mobile_net_info
• xqdtcustom/cpe_detect
• Cualquier registro que muestre tiempos de espera agotados o puntos finales restringidos.
• Cualquier registro relacionado con los tiempos de espera de macfilter_info durante el bloqueo/desbloqueo

💖 Soporte y donaciones

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

• 💸 Wise
• 💸 PayPal

🔎 Resumen de cambios (última versión)

📝 Changelog — Integración MiWiFi

📦 Versión v3.5.6 – 2026-02-04

✅ Correcciones y estabilidad

• 🧭 Se solucionó el problema por el cual la detección de integración no encontraba enrutadores en subredes LAN no predeterminadas
• Ahora, la función de descubrimiento detecta correctamente los enrutadores incluso cuando la LAN no es 192.168.31.0/24 (por ejemplo, 192.168.1.1), y también descubre los nodos hoja de la malla a partir de la topología.
• Utiliza una ruta de obtención de topo_graph "en bruto" (sin depender de la creación de URL/protocolos internos), lo que mejora la compatibilidad entre las distintas variantes de firmware.

• 🔁 Se gestionaron las redirecciones a __HTML_PLACEHOLDER_0__ y las respuestas que no eran de LAN durante el descubrimiento.
• Las solicitudes de descubrimiento ahora siguen las redirecciones y ya no fallan estrepitosamente cuando miwifi.com se resuelve fuera de la LAN (por ejemplo, cuando www.miwifi.com devuelve un error 404).

• 🌐 Resiliencia de protocolo mejorada (HTTP/HTTPS)
• El descubrimiento sondea tanto http:// como https:// para topo_graph, lo que aumenta la tasa de éxito en diferentes configuraciones de enrutador.

• 🧩 Reducción del spam repetido en el flujo de descubrimiento
• Se agregó una protección "ya configurada" para que las entradas existentes no vuelvan a activar los flujos de configuración en cada intervalo de descubrimiento.

• 🧾 Mejor visibilidad para la depuración de descubrimientos
• Se añadieron registros explícitos para cada intento de detección y un controlador de excepciones protegido para que los fallos no desaparezcan silenciosamente.

• 🔒 Registros de depuración WAN sanitizados para evitar la filtración de credenciales confidenciales
• La salida de depuración de la WAN ahora enmascara los campos confidenciales (por ejemplo, la contraseña PPPoE, los tokens/claves) antes de registrarlos, lo que evita su exposición accidental en los registros.

• ⏱️ Se corrigieron las falsas advertencias de "no compatible" causadas por tiempos de espera transitorios en las comprobaciones de compatibilidad.
• Los tiempos de espera (y otros fallos no concluyentes) ya no marcan automáticamente las funciones como *no compatibles*.
• Evita las notificaciones de "Modelo no compatible detectado" cuando el punto final funciona correctamente pero responde con lentitud.

• 🧠 Se ha corregido la detección automática incorrecta del router PRINCIPAL en configuraciones Mesh
• Se evitó que los nodos hoja de la malla (por ejemplo, show=0, mode=3, assoc=1) se marcaran incorrectamente como is_main.
• La detección automática del nodo principal ahora prioriza el nodo raíz de la topología (presencia de hojas/nodos) y las señales show=1, lo que garantiza que solo se seleccione automáticamente el enrutador principal real.

• 🚫🌐 Se corrigieron la semántica del servicio de bloqueo/desbloqueo de WAN y la compatibilidad con el router
• Alinea el comportamiento del control WAN con las expectativas de la API del router Xiaomi:
• wan=1 → Internet permitido
• wan=0 → Internet bloqueado
• Evita situaciones en las que el interruptor cambia visualmente, pero el enrutador no aplica la regla esperada.

• 🧩 La capacidad mejorada del filtro MAC comprueba la robustez
• Evita falsos negativos en algunos firmwares donde macfilter_info puede fallar o agotar el tiempo de espera de forma intermitente, aunque la función funcione.
• Reduce la detección errónea de funciones de filtrado MAC "no compatibles" en routers lentos o con mucho tráfico.

⚙️ Mejoras

• 🧠 Programación de tareas de detección de limpiadores
• La función Discovery se inicia mediante el bucle de tareas de Home Assistant (hass.async_create_task) en lugar de una simple asyncio.create_task, lo que mejora la seguridad de la integración durante el arranque.

• 🧹 Salida de razonamiento principal automática más limpia
• auto_reason ahora refleja las señales de la raíz de la topología (hojas/nodos) como parte de la decisión, lo que facilita la resolución de problemas.

✅ Compatibilidad

• ✅ El comportamiento probado coincide con las respuestas de la topología de Xiaomi:
• Nodo principal detectado (por ejemplo, 192.168.1.1)
• Nodos hoja de la malla detectados (por ejemplo, 192.168.1.73)
• Funciona incluso cuando miwifi.com responde con redirecciones o se resuelve fuera de la LAN.

• ✅ Lógica principal automática de la malla validada:
• Solo el enrutador raíz/principal se marca automáticamente como is_main.
• Los nodos de la malla de hojas permanecen como no principales a menos que se seleccionen manualmente.

📘 Cómo actualizar

1. Descarga / obtén la última versión preliminar de MiWiFi XiaoHack Edition v3.5.6rc1.
2. Reemplaza tu carpeta custom_components/miwifi/ con la nueva versión.
3. Reiniciar Home Assistant.
4. (Opcional) Habilite temporalmente los registros de depuración para validar el descubrimiento:

• Compruebe los registros para ver: Discovery trying topo_graph... y Discovery found devices: [...].

ℹ️ Información adicional

• Esta es una versión candidata: seguiremos monitorizando los casos extremos y las variantes de firmware antes de etiquetarla como estable.

💖 Soporte y donaciones

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

• 💸 Wise
• 💸 PayPal

🔎 Resumen de cambios (vs RC anterior)

📝 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)