Midea V2, V3 och Cloud API: vad det faktiskt innebär för PortaSplit

I samband med Midea PortaSplit betecknar ”V2” flera saker som är oberoende av varandra. Det finns ett lokalt V2-enhetsprotokoll, versionsnummer i privata appslutpunkter och ett officiellt Cloud-to-Cloud API V2 för partner. Den som likställer dessa nivåer drar oundvikligen fel slutsatser om den lokala styrningen.

Projektet Midea AC LAN varnar i sin README för att tidigare tokensnittställen skulle stängas och ersättas av ett molnbaserat V2-API. En granskning av diskussionerna, den aktuella koden och Mideas officiella dokumentation ger en mer nyanserad bild:

Det finns ett officiellt Midea Cloud-to-Cloud API V2. Det är dock inte identiskt med tokensnittstället som används av Home Assistant, och inte heller med det lokala V2- eller V3-enhetsprotokollet. Någon officiellt annonserad avveckling av den lokala PortaSplit-styrningen med ett konkret datum är inte dokumenterad. I juni 2026 visades dessutom att det påstått avvecklade SmartHome-token-API:t fortfarande fungerade – communitybibliotekets tidigare request var bara ofullständig.

Detta är del 3 i serien; del 1 beskriver installationen fram till dashboarden, del 2 säkring av token, key och hemnätverk. Artikeln är uppdaterad den 25 juli 2026.

Varför den tidigare bedömningen måste korrigeras

I en tidigare version av artikeln om token och key återgav jag i huvudsak varningen från projektet Midea AC LAN som en annonserad avveckling av molnsnittställena. Det motsvarade formuleringen i projektets README, men var för starkt formulerat som ett faktapåstående.

Varningen är fortfarande relevant som riskindikator. Den är dock ingen publicerad Midea-färdplan. Framför allt finns nu nytt tekniskt material som ifrågasätter en väsentlig del av den tidigare tolkningen.

Så fungerar den lokala PortaSplit-styrningen

Home Assistant-integrationen Midea Smart AC beskriver uttryckligen sin arkitektur som lokal styrning. För nyare V3-enheter används Midea-molnet endast under installationen för att hämta en enhetsspecifik token och key. Därefter sparar integrationen båda värdena lokalt och behöver ingen ytterligare molnanslutning för själva styrningen. Projektet dokumenterar detta under ”Note On Cloud Usage”.

Förenklat ser flödet ut så här:

Einrichtung:

Home Assistant
    │
    ├── Anmeldung an einer Midea-Cloud
    ├── Abruf von Geräte-ID, Token und Key
    └── lokale Speicherung der Zugangsdaten

Normalbetrieb:

Home Assistant
    │
    └── lokale TCP-Verbindung zur PortaSplit

För manuellt konfigurerade V3-enheter kräver Midea Smart AC enhets-ID, IP-adress, port, token och key. Den dokumenterade standardporten är 6444/TCP; token och key anges som 128 respektive 64 hexadecimala tecken. Uppgifterna finns i dokumentationen för manuell konfiguration.

En PortaSplit identifierades exempelvis i issue-trackern för Midea AC LAN som enhetstyp 0xAC, modell 00000Q1D och protokollversion 3. Samma användare kunde sedan lägga till den i Home Assistant via NetHome Plus. Det konkreta förloppet dokumenteras i Issue #607.

Avgörande är åtskillnaden:

• Molntjänsten används för att hämta de lokala åtkomstuppgifterna.
• Den efterföljande styrningen sker direkt i LAN.
• Ett fel i tokentjänsten förhindrar därför främst nya installationer.
• Det avslutar inte automatiskt en redan konfigurerad lokal anslutning.

Detta motsvarar också den uttryckliga beskrivningen från Midea Smart AC.

Varifrån avvecklingsvarningen kommer

Den varningstext som syns i dag lades till i dokumentationen den 19 maj 2025 med Pull Request #578.

Motiveringen kan sammanfattas så här:

• De lokala tokenarna saknade utgångsdatum.
• Olika Home Assistant-projekt använde emulerad eller extraherad appkryptering.
• Detta innebar ett säkerhetsproblem.
• Midea skulle därför successivt stänga de tidigare tokentjänsterna.
• På lång sikt skulle den lokala V1-styrningen trängas undan av ett molnbaserat V2-API.

I juli 2025 anpassades dokumentationen på nytt genom Pull Request #639. I stället för SmartHome-molnet nämndes nu NetHome Plus som temporärt använd tokenkälla. Själva avvecklingsvarningen kvarstod.

Den bakomliggande diskussionen är dock mer försiktigt formulerad än README-filen.

I kommentaren från Midea-AC-LAN-maintainern sägs i huvudsak att NetHome Plus möjligen bara är en tillfällig lösning och att Midea, enligt hans uppfattning, har en ny helt molnbaserad V2-tjänst.

Maintainern för midea-msmart svarade att även han misstänkte att ett nytt V2-API fanns, men att han bara i begränsad omfattning kunde undersöka det eftersom han saknade egna Midea-enheter. Detta framgår av det direkta svaret.

Källsituationen blir därmed tydligare:

• Varningen kommer från erfarna communityutvecklare.
• Den bygger på observerade ändringar och deras tekniska bedömning.
• En av maintainrarna beskriver uttryckligen V2-migreringen som sin uppfattning.
• Den andra talar om en misstanke.
• Varken Pull Request eller diskussionen länkar till något officiellt Midea-meddelande om avveckling eller något datum.

Det gör inte varningen värdelös. Men det gör den till en riskanalys och inte en bekräftad tillverkarfärdplan.

Det avgörande nya fyndet från juni 2026

Den 15 juni 2026 lades en fix in i biblioteket midea-local som väsentligt förändrar den tidigare tolkningen.

Utgångspunkten var felet:

{
  "code": "3004",
  "msg": "value is illegal."
}

Felet uppstod vid hämtning av token och key via SmartHome-molnet. Inloggning och enhetslista fortsatte att fungera, men anropet till /v1/iot/secure/getToken avvisades.

Till en början såg det ut som om snittstället hade stängts eller gjorts obrukbart. En analys av requesten från den officiella SmartHome-appen visade dock en annan orsak: Utöver udpid skickade appen även fältet applianceCodes. Communitybiblioteket skickade inte med detta fält.

Den korrigerade requesten innehåller nu:

data.update({
    "udpid": udp_id,
    "applianceCodes": str(appliance_id)
})

Utvecklaren testade ändringen med ett verkligt SmartHome-konto och fyra V3-luftkonditioneringsenheter av typen 0xAC:

• Utan applianceCodes svarade servern med fel 3004.
• Med applianceCodes levererade den giltiga tokenar och keys.
• De returnerade värdena fungerade sedan för den lokala V3-autentiseringen.

Den fullständiga undersökningen, testresultaten och kod-diffen dokumenteras i midea-local Pull Request #470. Den tillhörande oföränderliga commiten är 23312799.

Även i den aktuella källkoden används fortfarande exakt denna slutpunkt:

/v1/iot/secure/getToken

Dessutom skickas nu applianceCodes med. Det går att verifiera direkt i den aktuella midealocal/cloud.py.

Den nuvarande versionen av Midea AC LAN använder midea-local==6.11.0 och deklarerar sig fortfarande som en local_push-integration. Båda framgår av det aktuella manifest.json.

Det generella påståendet att SmartHome-token-API:t skulle ha stängts motbevisas därmed, åtminstone för de konton och enheter som testades i juni 2026. Korrekt vore:

Den tidigare tokenhämtningen fungerade inte längre efter en ändring av det förväntade requestformatet. Efter anpassning till formatet som används av den officiella appen levererade samma V1-slutpunkt åter giltiga lokala åtkomstuppgifter.

Regionala skillnader, avvikande konton eller enhetstyper som inte stöds kan därmed inte uteslutas. Men det var uppenbarligen inte en global avveckling.

Varför ”V2” så lätt missförstås här

I Midea-sammanhang används minst tre sinsemellan oberoende versionsbeteckningar.

Lokalt V2 och V3

I det lokala enhetsprotokollet betecknar V2 respektive V3 enhetens kommunikationsgeneration. Nyare V3-enheter behöver token och key för lokal autentisering. Midea Smart AC dokumenterar detta krav i sin konfigurationsguide.

Denna protokollversion har inget att göra med det officiella Cloud-to-Cloud API V2.

V1 och V2 i app-URL:er

Även i samma app kan slutpunkter med olika versionsnummer användas samtidigt. Ett /v2/ i URL-sökvägen innebär därför inte att hela plattformen har ställts om till en ny arkitektur.

Den aktuella koden för midea-local använder fortfarande /v1/iot/secure/getToken för token och key. Andra funktioner kan ändå ligga på sökvägar med andra versionsnummer.

Officiellt Cloud-to-Cloud API V2

Midea dokumenterar faktiskt ett officiellt Cloud-to-Cloud API V2.

Det använder bland annat:

• OAuth 2.0
• client_id och client_secret
• kortlivade access-tokenar och refresh-tokenar
• HMAC-SHA256-signaturer
• /v2/open/oauth2/authorize
• /v2/open/oauth2/token
• /v2/open/device/list/get
• molnbaserade statusförfrågningar och styrkommandon

Detta är ett kontrollerat partnersnittställe. Den nödvändiga client_secret tilldelas en tredjepartsleverantör av Midea. En vanlig ägare av en PortaSplit får den inte bara via sitt MSmartHome-konto. Kraven och signaturreglerna beskrivs i den officiella V2-dokumentationen.

Detta API uppstod inte heller först 2025. Dokumentationen innehåller requestexempel med tidsstämplar från 2018 och en Java-kommentar från den 18 april 2019. V2-partnersnittstället existerade alltså redan långt före varningen i Midea AC LAN.

Midea ersätter faktiskt ett V1-API – men ett annat

Midea har även ett äldre officiellt Cloud-to-Cloud-snittställe under /v1/open/.... Dess dokumentation innehåller uttryckligen informationen att det inte längre rekommenderas, kan avvecklas i framtiden och att den nya V2-dokumentationen bör användas. Detta står i Mideas dokumentation för det gamla Cloud-to-Cloud API:t.

Denna information är en verklig, officiell V1-till-V2-migrering. Den gäller dock partnerslutpunkterna:

/v1/open/...
           ↓
/v2/open/...

Tokenhämtningen som används av Home Assistant-biblioteken är däremot:

/v1/iot/secure/getToken

Och den lokala PortaSplit-anslutningen går sedan inte alls via en sådan moln-URL, utan direkt i hemnätverket.

Att likställa de tre snittställena enbart på grund av versionsnumret ”V1” vore därför tekniskt obefogat.

Finns det redan en helt molnbaserad Home Assistant-integration?

Med Midea Auto Cloud finns nu en communityintegration som styr Midea-enheter via molnet i stället för direkt över LAN.

Inte heller detta är dock ett bevis för att det officiella V2-partner-API:t redan har ersatt den lokala styrningen. Den aktuella källkoden för Midea Auto Cloud använder bland annat:

/v1/appliance/transparent/send
/mjl/v1/device/status/lua/get
/mjl/v1/device/lua/control

Dessa slutpunkter går att se i den aktuella core/cloud.py.

Integrationen emulerar därmed privata app- respektive konsumentmolnfunktioner. Den använder inte bara det dokumenterade /v2/open/...-partnersnittstället.

Det finns alltså redan ett molnbaserat alternativ. Men det medför också de vanliga beroendena hos en molnintegration: internetåtkomst, ett fungerande användarkonto, tillgängliga Midea-servrar och fortsatt kompatibla privata slutpunkter.

Vad innebär detta konkret för PortaSplit-ägare?

Redan konfigurerad lokal styrning

För en redan konfigurerad PortaSplit är situationen relativt okritisk. Midea Smart AC sparar token och key lokalt efter installationen och behöver enligt sin egen molndokumentation ingen molnanslutning för fortsatt styrning.

En avveckling av enbart tokenhämtningen skulle därför inte automatiskt avsluta den befintliga lokala anslutningen.

Nyinstallation eller återställning

Risken är större vid:

• en ny Home Assistant-installation
• byte till en annan integration
• en förlorad eller skadad backup
• byte av Wi-Fi-modul
• ändringar i enhetskopplingen
• en ny parkoppling, om enhetens åtkomstuppgifter ändras då

I sådana fall måste integrationen hämta token och key igen, eller så måste användaren ange dem manuellt. Att Midea Smart AC stöder manuell konfiguration beskrivs i dess konfigurationsdokumentation.

Om en fabriksåterställning eller en ny parkoppling nödvändigtvis skapar nya åtkomstuppgifter för varje PortaSplit är inte officiellt dokumenterat och bör därför inte hävdas generellt.

En verklig avveckling av LAN-styrningen

För att en redan konfigurerad PortaSplit inte längre ska acceptera sina lokalt lagrade åtkomstuppgifter måste dessutom beteendet hos enheten eller Wi-Fi-modulen ändras, till exempel genom ny firmware eller en ändrad autentiseringsmetod.

Enbart en avveckling av molnslutpunkten /v1/iot/secure/getToken tar inte automatiskt bort de åtkomstuppgifter som redan finns i enheten och i Home Assistant. Detta följer av den separation mellan engångshämtning från molnet och efterföljande LAN-styrning som dokumenteras av Midea Smart AC.

En sådan framtida enhetsändring är tekniskt möjlig. Jag har dock inte hittat något konkret tillkännagivande eller avvecklingsdatum särskilt för PortaSplit i Mideas offentligt tillgängliga dokumentation.

Vad jag fortfarande skulle rekommendera

Trots de nyanserande insikterna är en backup fortfarande klok.

För V3-enheter rekommenderar Midea AC LAN uttryckligen att spara den skapade JSON-konfigurationen utanför HAOS. Den aktuella rekommendationen står direkt i projektets README.

En backup är ett rimligt skydd mot molnändringar, integrationsproblem och egna misstag, men ingen indikation på att en avveckling är omedelbart förestående. Hur token, key och konfiguration säkerhetskopieras beskrivs i del 2.

Bedömning utifrån tillgängliga belägg

Varningen från Midea AC LAN bör tas på allvar, men placeras i rätt sammanhang.

Den dokumenterar en rimlig långsiktig risk: Midea kan betrakta lokala tokenar utan utgångsdatum som ett säkerhetsproblem, ytterligare begränsa hämtningen av sådana tokenar eller knyta framtida enheter starkare till molnet.

Däremot finns det inga belägg för en officiellt annonserad och tidsbestämd avveckling av den lokala PortaSplit-styrningen.

Det aktuella tekniska läget visar till och med motsatsen till en redan genomförd avveckling: I juni 2026 levererade den fortfarande använda V1-tokenslutpunkten giltiga åtkomstuppgifter efter att requesten hade anpassats till formatet i den officiella SmartHome-appen. Den aktuella fixen ingår nu i biblioteket som används av Midea AC LAN.

Det officiella Midea Cloud-to-Cloud API V2 finns också. Men det är ett äldre partnergränssnitt med begränsad åtkomst och inte automatiskt efterföljaren till det lokala PortaSplit-protokollet.

Den nyktra slutsatsen är därför:

Skapa en backup, följ integrationerna och ha molnberoenden i åtanke – men avskriv inte den lokala PortaSplit-styrningen i förtid på grund av ett obekräftat antagande om avveckling.