Midea PortaSplit in Home Assistant: Why Token and Key Matter

Local control of the Midea PortaSplit relies on two device-specific values: token and key. During setup, the Home Assistant integration retrieves both through a private Midea Cloud endpoint. It then sends control commands directly over the local network.

The Midea AC LAN project warns of possible changes to these cloud interfaces. However, newer analyses show that no confirmed manufacturer roadmap or specific shutdown date can be inferred from this. This article explains the technical dependency; the detailed API analysis explains the various “V2” labels and the current situation.

The token question in detail

Why has Home Assistant been able to obtain the token at all?

The community never calculated the token. Instead, it analyzed the official app’s network traffic and found that the app does not generate the token itself, but retrieves it from the cloud:

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

The Home Assistant integration reimplemented precisely this cloud request. It logs in to the cloud using the same endpoints and process as the app, thereby receiving the same token and key. The actual foundation is therefore a replicated retrieval process, not a calculation. If the endpoint disappears, so does the ability to obtain them.

Could the token be extracted from the official app?

Theoretically, yes. The app must know the token at some point; otherwise, it could not communicate locally with the device. Fundamentally conceivable methods would be:

• reverse engineering the app,
• monitoring network traffic if it is not additionally protected,
• instrumenting the app at runtime, for example with Frida or Objection,
• hooking the functions that process the token.

This is precisely what the Midea AC LAN developer means when saying that the previous design is a security problem from Midea’s perspective: a long-lived secret that can be extracted from a widely distributed app with reasonable effort is difficult to control. For individual users, however, these approaches are time-consuming and do not replace convenient cloud retrieval.

Could the token be obtained directly from the device?

That would be the most elegant solution. If the device exchanged a public key during the initial local pairing process or used a one-time pairing code over Bluetooth, no cloud would be needed at all. Many modern IoT devices do exactly that.

However, Midea designed the original LAN protocol differently: the device accepts local commands only with the appropriate cloud-related credentials. There is no documented local pairing mechanism that would provide the token without going through the cloud. The cloud is therefore not merely a convenience, but architecturally the only intended route to the token.

Could the community work around changes to the token endpoint?

That would only be possible if one of the following options is found:

• a new cloud API that continues to provide tokens,
• a previously unknown local pairing method,
• a vulnerability in the device,
• or Midea eventually publishes an official local API itself.

Simply “recalculating” the token is very unlikely to work. If that were possible, the community would probably have implemented it long ago and would never have depended on the cloud API. The fact that the cloud detour was built at all is the strongest indication that no simpler local method exists.

The warning from Midea AC LAN

The repository of Midea AC LAN contains a prominently placed “Important Notice.” According to the developer, Midea has already closed the server-side token APIs in the Meiju and SmartHome clouds. The integration therefore currently uses token interfaces from the NetHome Plus cloud, and these too are expected to be closed gradually. The consequence would be that devices already set up would continue to work locally, but new devices could no longer be added. The developer goes further, writing that Midea intends to transition to a new Cloud Control API in the long term, rendering the previous V1 LAN API unusable.

The warning has a brief history. The prominent “Important Notice” was added to the README on May 19, 2025 (pull request #578) and at the time named the SmartHome cloud as the fallback for adding new devices. It was updated on July 14, 2025 (#639); since then, it has referred to the NetHome Plus cloud because Midea had closed additional endpoints. The core remained unchanged in both versions: the token interfaces are gradually disappearing; only the cloud still usable at any given time changes.

This needs to be viewed with nuance. It is the assessment of an open-source project, not a binding roadmap from Midea, and the timeline is unknown. A future firmware update could change local functionality; an already stored token may continue to work, but it may not work forever. A factory reset, changing the Wi-Fi module, or adding a new device may require obtaining a token again.

This leads to the three steps in the box at the beginning of the article, each with its rationale:

• Do not replace a working setup without good reason. Obtaining the token is the only step that must go through the Midea Cloud. Changes to the private endpoint may primarily affect a later new setup.
• Back up credentials. Home Assistant stores the token and key locally. A failed system, unsuccessful restore, or accidentally deleted integration can still make local control unusable if no external backup exists.
• Do not unpair it lightly. Whether a factory reset or removing it from the Midea account requires new credentials for every model is not fully documented. A backup before such changes is therefore essential.

Ongoing operation is not initially affected: local control uses the values already stored and no longer needs the token endpoint. A residual risk remains if later firmware changes the local protocol or authentication. How to back up the token, key, and configuration is covered in the practical setup guide.

What this means for security

In addition to availability, the warning has a security-related core. According to Midea AC LAN, the older LAN architecture is based on a problematic assumption: client communication was originally considered sufficiently protected, which is why the tokens issued by the cloud were given no expiration date.

A token that does not expire is not a vulnerability in itself. It becomes problematic if it ends up in logs or unprotected backups, reaches third parties, or can neither be revoked nor rotated. The developer of Midea AC LAN suspects that Midea is responding to these risks with changes to token services and a more cloud-based architecture. However, no corresponding manufacturer announcement with a timeline has been substantiated.

Linguistic precision matters here. The community integration does not “hack” the air conditioner. It implements a proprietary protocol that has been understood through reverse engineering. The security problem arises because long-lived secrets can be used and stored outside the originally intended app.

For operation on your own network, what matters most is what the token and key enable. Both authenticate local communication with the device. If they fall into the wrong hands, an attacker could, depending on the protocol and their network position, identify the device, authenticate to it, read status information, change settings, turn the air conditioner on or off, switch operating modes, and change the target temperature. In general, the attacker would still need to establish a network connection to the device; possessing the token and key alone does not enable an attack from anywhere on the internet. The token and key should therefore be treated like a password. How to integrate the device into the network so that these values cause little damage even in the event of a mishap is the topic of the second part.

What remains in practice

Local control of the PortaSplit depends entirely on the token and key, which can currently only be obtained through the Midea Cloud. This detour is part of the protocol design: local commands are tied to cloud-related credentials. Because the endpoint is private and undocumented, the long-term availability of the unofficial integration remains uncertain.

In practice, this means: back up credentials and configuration, do not unnecessarily unpair a working setup, and monitor changes to the integration and firmware. Devices that have already been set up continue to run locally. Setup, backup, and network protection are described in the practical PortaSplit guide.