The current midea app for the Homey Pro uses local access
I want to add that this plugin works foor Maxicool airconditioning. To get the correct tokens. I had to use this python plugin and command.
midea-beautiful-air-cli.exe discover --account âXXXXX@gmail.comâ --password âXXXXXâ --credentials
The login method with user and password doesnât work but with tokens it was a success. Thanks for the app.
bupemko
February 9, 2026, 8:01pm
86
Thank you for your work!
I have 4 Midea ACs that I can control via Home Assistant without any issues.
In Homey with your app however I could only add 1 of them.
Could you please advise how to add the remaining 3 to Homey directly?
Wasnât sure if it will work or not, but just to confirm, two new midea ac, after adding it to NetHome Plus worked flowlessly. For now giving my compliments to the developer.
Jost1
April 15, 2026, 10:14pm
88
Has anyone gotten this to work with a QLIMA SJA-2519? Itâs connected trough the NetHome Plus service and produced by Midea..
Got my midea air con unit to work today by installing msmart-ng, then running âmsmart-ng discoverâ and then copying the key and token. Easy!
Hi there,
Today my Midea U-Shaped window unit went offline in the Homey App, and it suggested to remove and readd it (I skipped the screens prompting for the keys/creds I didnât have). Now I cannot readd the AC unit, as it is not found when scanning, and there is no manual add option. I have reset the device, everything is on the same network, I have removed and readded it in all of the manufacturer smart home apps (which all work fine), and msmart-ng discover produces this:
Nice app but a bit of a hiccup here. Please help.
There is a PR open that targets several of the Midea pairing/runtime issues discussed here:
develop â itsklimov:feat/public-live-discovery-lan-stability
opened 04:52PM - 10 May 26 UTC
## Summary
This PR makes Midea/Toshiba-style AC pairing and control local-first⌠, with automatic recovery when LAN sessions expire or a device IP changes. It also replaces the single-device broadcast-only pairing path with a validated multi-device discovery flow that can work on routed local networks.
The user-facing goal is to reduce the need for repair/re-pair actions:
- pairing validates that a discovered candidate is actually addable before showing it as a normal device
- multiple validated AC units can be selected and added from one pairing run
- manual "Search another network" accepts an IP-like network hint such as `192.0.2.0` and scans the full last-octet range for that network
- token/key and cloud-login pairing flows reuse the same validation path and return initial capability values
- runtime polling/control refreshes LAN state safely, resets timed-out sessions, and tries rediscovery before marking the device unavailable
- static capabilities are no longer re-derived during runtime polling
## Why this is a larger PR
Several reported symptoms share the same root cause: discovery, validation, Homey device identity, LAN authentication, capability setup, and runtime state refresh were tightly coupled. Fixing only one of those paths still leaves users with devices that can be discovered but not added, added but not controllable, or temporarily working until the LAN session or IP changes.
This is still one logical change: make the AC driver local-first and self-healing across pairing, polling, Flow conditions, and control.
## User impact
- Devices on routed local networks can be found without needing global broadcast to work.
- Already paired devices are recognized by stable identifiers instead of mutable host/port data.
- Pairing distinguishes validated devices from candidates that responded but could not be authenticated.
- Failed candidates now show an actionable route to the token/key or cloud-login fallback instead of appearing silently broken.
- Newly added devices start with populated Homey capability values instead of empty state.
- Existing devices can recover from an expired LAN socket/session by reconnecting and refreshing state.
- Existing devices can recover when the same unit appears at a new IP by rediscovering and updating stored host/port.
- Control actions and Flow conditions use the same serialized fresh-state LAN path, reducing stale writes and silent Flow mismatches.
- Temperature values keep decimal precision where supported, inside/current/outside readings are separated, and unsupported/outdoor placeholder values are not surfaced as real readings.
- Capability controls stay stable after pairing, so normal polling only updates state instead of reshaping the device UI.
## Main changes
- Added `drivers/airco/capabilities.ts` for conservative static capability definitions and capability value filtering.
- Added `drivers/airco/discovery-targets.ts` for explicit discovery target parsing.
- Reworked `drivers/airco/driver.ts` pairing discovery around validated candidates, stable Homey identity, token/key fallback, and rediscovery.
- Reworked `drivers/airco/device.ts` runtime LAN operations so polling and control use serialized fresh-state operations with timeout cleanup.
- Added a minimal discovery pairing view that shows validated devices first and failed candidates separately.
- Added initial `capabilitiesValues` during pairing so Homey receives the first known state immediately after add.
- Kept host/port as mutable store fields for new devices, while preserving fallback support for older devices that already have host/port in `data`.
## Review guide
Suggested review order:
1. `drivers/airco/capabilities.ts`
2. `drivers/airco/discovery-targets.ts`
3. pairing path in `drivers/airco/driver.ts`
4. runtime path in `drivers/airco/device.ts`
5. pairing UI/locales
## Related reports
Auto-closes the reports that match this PR's main discovery/runtime reliability path:
- Fixes #9: multi-device discovery/pairing can miss additional AC units.
- Fixes #13: devices become unreachable and may need repair/restart.
- Fixes #18: devices can become unavailable after running for a while.
Related to reports that may still need device-specific confirmation or credentials/token follow-up:
- Related to [#1 - Not possible to add devices](https://github.com/mteutelink/nl.intyme.midea/issues/1): discovery does not find devices reliably and users need a less technical manual add path.
- Related to [#5 - devices are in homey but not reachable](https://github.com/mteutelink/nl.intyme.midea/issues/5): devices can be present in Homey but still fail at runtime.
- Related to [#17 - Midea Extreme - MSAG-18HRN1 Homey problem](https://github.com/mteutelink/nl.intyme.midea/issues/17): token/key pairing can fail on some Midea-compatible setups.
## Validation
Ran locally against this branch:
- `bun run build`
- `bun run lint`
- `bunx --bun homey app build`
Also validated locally on a Homey Self-Hosted Server installation with two AC devices:
- direct LAN state polling
- control path requiring fresh state before `SetStateCommand`
- LAN session timeout recovery
- rediscovery/update of mutable host/port
- pairing output with non-empty initial `capabilitiesValues`
- no duplicate Homey identity for the same AC when host/port changes
The Homey build still emits existing future warnings about missing `titleFormatted` on some Flow cards; this PR does not change those Flow-card titles.
## Privacy / public PR notes
- No local network addresses, hostnames, databases, backups, or secrets are included.
- Local-only verification helpers are ignored and excluded from production build output.
- `package-lock.json` only contains root metadata churn from the local package manager; no dependency version changes are intended.
It changes the pairing flow to validate devices before adding, supports adding multiple validated AC units, adds an explicit âsearch another networkâ path for cases where broadcast discovery does not work, and makes runtime LAN polling/control recover from expired sessions or changed device IPs.
It is not merged yet, so this is not an official release announcement, but it should address the âonly one deviceâ, âdevice unavailable/unreachableâ, and âfound but cannot addâ class of problems once reviewed and released.
Thanks,
I will check this out and if positive publish it accordingly.
With regards,
Hi!
I wanted to try out Homey and got a Porta Split recently.
Its just Add â Midea â AirConditioner â Connect â No Device Found
As Iâm new to Homey, maybe I do something wrong.
Hello! Big thanks for this App integration. Everything works fine for me. I have Porta Split.
I was wondering, is it possible to set the device on ionizing mode? Is it possible to choose a specific fan speed in %, for example 8%?
Both of those I can do with the SmartHome app but I am not able to through homey pro flows.
The app is working great and really happy with the integration. Using it with the Midea PortaSplit heat & Cool I do have some feedback/feature requests:
The SmartHome app shows the energy usage of the unit it would be amazing if the homey app could expose this information too so the airco will show up in the homey energy dashboard .
The unit has a special I-Sense mode that will use the temperature sensor in the remote. Is there anyway this can be exposed/toggled in the homey app?
In the swing options I also see a horizontal swing that the unit does not support I think.
Hopefully you find some time to take a look at these points that would make me really happy!
