feat(fw): integrate the Midea PortaSplit into Home Assistant #445

Merged

dominik.polakovics merged 1 commit from lab/20261008-2355 into main

2026-10-09 00:39:33 +02:00

dominik.polakovics commented

2026-10-09 00:38:24 +02:00

Owner

Closes #444

What

ac.nix: installs the Midea Smart AC custom component (midea_ac, mill1000/midea-ac-py 2026.4.0 + msmart-ng 2026.4.1). 2026.4.0 is the release that added PortaSplit support (Out Silent Mode, defrost and outdoor-fan sensors). It talks to the unit locally on TCP 6444.
dnsmasq.nix: reserves 10.42.100.194 for the PortaSplit (60:7a:d8:8c:0d:90, shows up as net_ac_0D90). That's the address it already holds, so nothing moves and the host saved in the integration stays valid.
default.nix: exposes the HA nixpkgs pin to the container's modules as pkgs-with-home-assistant.

No firewall change: server → smart is already allowed, so the HA container can reach the unit.

Why the component comes from the HA pin

HA is built from the pinned unstable nixpkgs, not the host channel. The HA package builds its PYTHONPATH with makePythonPath, which keeps only Python packages whose pythonModule is its own interpreter. A component from the host channel brings msmart-ng built against 26.05's python3.14, so it's silently dropped. Eval and the dry-build pass, but the integration fails at runtime. With midea_ac from the pin, msmart-ng makes it onto the service's PYTHONPATH.

epex_spot in electricity.nix has the same problem today: its beautifulsoup4 requirement isn't on HA's PYTHONPATH. Out of scope here, but possibly related to #222.

Verification

Built the hass container's home-assistant service locally (PYTHONPATH, preStart, ExecStart). midea_ac and msmart-ng both come from cache.nixos.org, and the HA binary is unchanged (homeassistant-2026.5.4, cached).
With HA's interpreter and the service's PYTHONPATH: import msmart.device works, and the manifest requirement msmart-ng==2026.4.1 is satisfied.
Pre-commit dry-build of fw: OK.

After deploy (manual, one-time)

Settings → Devices & services → Add integration → Midea Smart AC → Discover devices, host 10.42.100.194, cloud region Europe. Discovery fetches the token/key from the Midea cloud once; after that it's fully local. Midea is retiring these token APIs, so save the token/key from the config entry somewhere safe. If the PortaSplit's power reading looks too low, switch the power format from BCD to Binary in the integration options.

🤖 Generated with Claude Code

Closes #444 ## What - **`ac.nix`**: installs the Midea Smart AC custom component (`midea_ac`, mill1000/midea-ac-py 2026.4.0 + `msmart-ng` 2026.4.1). 2026.4.0 is the release that added PortaSplit support (Out Silent Mode, defrost and outdoor-fan sensors). It talks to the unit locally on TCP 6444. - **`dnsmasq.nix`**: reserves `10.42.100.194` for the PortaSplit (`60:7a:d8:8c:0d:90`, shows up as `net_ac_0D90`). That's the address it already holds, so nothing moves and the host saved in the integration stays valid. - **`default.nix`**: exposes the HA nixpkgs pin to the container's modules as `pkgs-with-home-assistant`. No firewall change: `server` → `smart` is already allowed, so the HA container can reach the unit. ## Why the component comes from the HA pin HA is built from the pinned unstable nixpkgs, not the host channel. The HA package builds its `PYTHONPATH` with `makePythonPath`, which keeps only Python packages whose `pythonModule` is *its own* interpreter. A component from the host channel brings `msmart-ng` built against 26.05's `python3.14`, so it's silently dropped. Eval and the dry-build pass, but the integration fails at runtime. With `midea_ac` from the pin, `msmart-ng` makes it onto the service's `PYTHONPATH`. `epex_spot` in `electricity.nix` has the same problem today: its `beautifulsoup4` requirement isn't on HA's `PYTHONPATH`. Out of scope here, but possibly related to #222. ## Verification - Built the hass container's `home-assistant` service locally (`PYTHONPATH`, `preStart`, `ExecStart`). `midea_ac` and `msmart-ng` both come from cache.nixos.org, and the HA binary is unchanged (`homeassistant-2026.5.4`, cached). - With HA's interpreter and the service's `PYTHONPATH`: `import msmart.device` works, and the manifest requirement `msmart-ng==2026.4.1` is satisfied. - Pre-commit dry-build of `fw`: OK. ## After deploy (manual, one-time) Settings → Devices & services → Add integration → **Midea Smart AC** → *Discover devices*, host `10.42.100.194`, cloud region Europe. Discovery fetches the token/key from the Midea cloud once; after that it's fully local. Midea is retiring these token APIs, so save the token/key from the config entry somewhere safe. If the PortaSplit's power reading looks too low, switch the power format from BCD to Binary in the integration options. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

dominik.polakovics added 1 commit

2026-10-09 00:38:24 +02:00

feat(fw): integrate the Midea PortaSplit into Home Assistant 2a8d5e48e4

Install mill1000's midea_ac (Midea Smart AC, msmart-ng), which supports
the PortaSplit locally, and pin the unit (net_ac_0D90) to its current
smart-VLAN address so the integration's configured host stays valid.

The component is taken from the HA nixpkgs pin, now exposed to the
container's modules as pkgs-with-home-assistant: the host-channel build's
msmart-ng is filtered out of HA's PYTHONPATH because it was built
against a different python3.14 derivation.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>

dominik.polakovics merged commit 874733ca44 into main

2026-10-09 00:39:33 +02:00

dominik.polakovics deleted branch lab/20261008-2355

2026-10-09 00:39:33 +02:00

dominik.polakovics referenced this pull request from a commit

2026-10-09 00:39:34 +02:00

Merge pull request 'feat(fw): integrate the Midea PortaSplit into Home Assistant' (#445) from lab/20261008-2355 into main