Midea PortaSplit en Home Assistant: por qué el token y la clave son decisivos

El control local de la Midea PortaSplit se basa en dos valores específicos del dispositivo: el token y la clave. La integración de Home Assistant obtiene ambos durante la configuración a través de un endpoint privado de la nube de Midea. Después envía los comandos de control directamente por la red local.

El proyecto Midea AC LAN advierte de posibles cambios en estas interfaces de la nube. Sin embargo, análisis más recientes muestran que de ello no puede derivarse una hoja de ruta confirmada del fabricante ni una fecha concreta de desactivación. Este artículo explica la relación técnica de dependencia; el análisis detallado de la API contextualiza las distintas denominaciones «V2» y la situación actual.

La cuestión del token en detalle

¿Por qué Home Assistant podía obtener hasta ahora el token?

La comunidad nunca calculó el token. Más bien analizó el tráfico de red de la aplicación oficial y comprobó que la aplicación no genera el token por sí misma, sino que lo obtiene de la nube:

App
   ↓
Midea Cloud
   ↓
Cloud liefert Token
   ↓
App verwendet Token lokal

La integración de Home Assistant reimplementó exactamente esta llamada a la nube. Inicia sesión en la nube con los mismos endpoints y el mismo proceso que la aplicación, y así obtiene el mismo token y la misma clave. La base real es, por tanto, una recuperación reproducida, no un cálculo. Si el endpoint desaparece, también desaparece la posibilidad de obtenerlos.

¿Se podría extraer el token de la aplicación oficial?

En teoría, sí. La aplicación debe conocer el token en algún momento; de lo contrario, no podría comunicarse localmente con el dispositivo. Algunas vías concebibles en principio serían:

• ingeniería inversa de la aplicación,
• interceptar el tráfico de red, si no cuenta con protección adicional,
• instrumentar la aplicación en tiempo de ejecución, por ejemplo con Frida u Objection,
• hacer hooking de las funciones que procesan el token.

Precisamente a esto se refiere la afirmación del desarrollador de Midea AC LAN de que el diseño actual constituye un problema de seguridad desde la perspectiva de Midea: un secreto duradero que puede extraerse de una aplicación ampliamente distribuida con un esfuerzo razonable es difícil de controlar. Sin embargo, para cada usuario estas vías son complejas y no sustituyen la cómoda recuperación desde la nube.

¿Se podría obtener el token directamente del dispositivo?

Esa sería la solución más elegante. Si el dispositivo intercambiara una clave pública durante el primer emparejamiento local o utilizara mediante Bluetooth un código de emparejamiento de un solo uso, no haría falta ninguna nube. Muchos dispositivos IoT modernos funcionan exactamente así.

Sin embargo, Midea diseñó de otra forma el protocolo LAN original: el dispositivo solo acepta comandos locales con las credenciales adecuadas vinculadas a la nube. No existe un mecanismo local de emparejamiento documentado que proporcione el token sin pasar por la nube. Por tanto, la nube no es solo una comodidad, sino que arquitectónicamente es la única vía prevista para obtener el token.

¿Podría la comunidad sortear cambios en el endpoint del token?

Solo sería posible si se encontrara una de las siguientes opciones:

• una nueva API en la nube que siga proporcionando tokens,
• un método de emparejamiento local hasta ahora desconocido,
• una vulnerabilidad en el dispositivo,
• o que Midea publique en algún momento una API local oficial.

En cambio, simplemente «recalcular» el token muy probablemente no funcionará. Si fuera posible, la comunidad probablemente lo habría implementado hace tiempo y nunca habría dependido de la API en la nube. Que se haya creado el desvío a través de la nube es el indicio más sólido de que no existe una vía local más sencilla.

La advertencia de Midea AC LAN

El repositorio de Midea AC LAN contiene un aviso destacado titulado «Important Notice». Según el desarrollador, Midea ya ha cerrado las API de tokens del lado del servidor en las nubes Meiju y SmartHome. Por ello, la integración utiliza actualmente interfaces de token de la nube NetHome Plus, y estas también se cerrarán gradualmente. La consecuencia sería que los dispositivos ya configurados seguirían funcionando localmente, pero no se podrían añadir otros nuevos. El desarrollador va más allá y escribe que Midea pretende migrar a largo plazo a una nueva API de Cloud Control y, con ello, dejar inutilizable la anterior API LAN V1.

La advertencia tiene una breve historia. El destacado «Important Notice» se añadió al README el 19 de mayo de 2025 (pull request n.º 578) y entonces mencionaba la nube SmartHome como alternativa para añadir nuevos dispositivos. El 14 de julio de 2025 (n.º 639) se actualizó; desde entonces hace referencia a la nube NetHome Plus, porque Midea había cerrado más endpoints. El núcleo se mantuvo inalterado en ambas versiones: las interfaces de token desaparecen gradualmente y solo cambia la nube que sigue siendo utilizable en cada momento.

Debe considerarse con matices. Se trata de la valoración de un proyecto de código abierto, no de una hoja de ruta vinculante de Midea, y se desconoce el calendario. Una futura actualización de firmware puede cambiar funciones locales; un token ya guardado puede seguir funcionando, pero no necesariamente para siempre. Restablecer los ajustes de fábrica, cambiar el módulo Wi‑Fi o incorporar un dispositivo nuevo puede requerir obtener de nuevo el token.

De ello se derivan los tres pasos del recuadro al principio del artículo, cada uno con su justificación:

• No sustituir sin motivo una configuración que funciona. La obtención del token es el único paso que necesariamente pasa por la nube de Midea. Los cambios en el endpoint privado pueden afectar sobre todo a una nueva configuración posterior.
• Guardar las credenciales. Home Assistant almacena el token y la clave localmente. Aun así, un sistema defectuoso, una restauración fallida o una integración eliminada por accidente pueden dejar inutilizable el control local si no hay una copia de seguridad externa.
• No desvincular a la ligera. No está completamente documentado si un restablecimiento de fábrica o la eliminación de la cuenta de Midea obliga a obtener nuevas credenciales en todos los modelos. Por ello, es imprescindible realizar una copia de seguridad antes de tales cambios.

El funcionamiento habitual no se ve afectado por el momento: el control local utiliza los valores ya almacenados y ya no necesita el endpoint del token. Sigue existiendo un riesgo residual si un firmware posterior modifica el protocolo local o la autenticación. En el artículo práctico sobre la configuración se explica cómo guardar el token, la clave y la configuración.

Qué significa esto para la seguridad

Además de la disponibilidad, la advertencia tiene un núcleo relacionado con la seguridad. Según Midea AC LAN, la arquitectura LAN más antigua se basa en una suposición problemática: originalmente se consideraba que la comunicación del cliente estaba suficientemente protegida, por lo que los tokens emitidos por la nube no tenían fecha de caducidad.

Un token sin caducidad no es por sí mismo una vulnerabilidad. Se vuelve problemático si acaba en registros o copias de seguridad sin proteger, llega a terceros o no puede revocarse ni rotarse. El desarrollador de Midea AC LAN supone que Midea está respondiendo a estos riesgos con cambios en los servicios de token y una arquitectura más basada en la nube. Sin embargo, no existe constancia de un anuncio correspondiente del fabricante con un calendario.

La precisión lingüística es importante en este caso. La integración de la comunidad no «hackea» el aire acondicionado. Implementa un protocolo propietario que se ha reconstruido mediante ingeniería inversa. El problema de seguridad surge porque secretos duraderos pueden utilizarse y almacenarse fuera de la aplicación prevista originalmente.

Para el uso en la propia red, lo más relevante es qué permiten el token y la clave. Ambos autentican la comunicación local con el dispositivo. Si caen en malas manos, un atacante podría, según el protocolo y su posición en la red, identificar el dispositivo, autenticarse ante él, leer información de estado, modificar ajustes, encender o apagar el aire acondicionado, cambiar modos de funcionamiento y modificar la temperatura de consigna. Por regla general, el atacante debe aun así poder establecer una conexión de red con el dispositivo; poseer únicamente el token y la clave no permite atacar desde cualquier lugar de Internet. Por ello, el token y la clave deben tratarse como una contraseña. El segundo artículo trata de cómo integrar el dispositivo en la red de forma que estos valores causen pocos daños incluso en caso de incidente.

Qué queda en la práctica

El control local de la PortaSplit depende por completo del token y la clave, que actualmente solo pueden obtenerse a través de la nube de Midea. Este desvío forma parte del diseño del protocolo: los comandos locales están vinculados a credenciales relacionadas con la nube. Puesto que el endpoint es privado y no está documentado, la disponibilidad a largo plazo de la integración no oficial sigue siendo incierta.

En la práctica, esto significa: guardar las credenciales y la configuración, no deshacer innecesariamente una vinculación que funciona y vigilar los cambios en la integración y el firmware. Los dispositivos ya configurados siguen funcionando localmente. El artículo práctico sobre la PortaSplit describe la configuración, la copia de seguridad y la protección de red.