daikin-remote-mcp — web panel remote and MCP server for Daikin air conditioners

Local control for Daikin units with a WiFi module, over the unit's own HTTP API. No cloud, no Onecta account, no official app — everything stays on your network.

Two things sharing one client:

• a web panel you open in a browser to control the unit from your computer;

• an MCP server, so an assistant (Claude Code, Claude Desktop, …) can read the state and drive the unit through tools.

Requirements

• Python 3.11+

• a Daikin unit whose WiFi module exposes the local HTTP API (see Compatibility)

• your machine on the same network as the unit

Related MCP server: Home Assistant MCP

Install

git clone <repo-url>
cd daikin-local
python3 -m venv .venv
.venv/bin/pip install -r requirements.txt   # only needed for the MCP server

The web panel needs nothing installed — it runs on the standard library.

Web panel

python3 web.py                    # http://127.0.0.1:8765
python3 web.py --port 9000
python3 web.py --bind 0.0.0.0     # reachable from the LAN, e.g. from a phone

Type the unit's IP address and press Connect. The address is saved to localStorage and appears as a chip; × removes it from the list. You can keep several units and switch between them. The list is mirrored into devices.json, so the MCP server sees the same units.

The panel shows the state, room and outdoor temperature, instantaneous and daily power use, and controls power, mode, temperature, fan, louvres and special modes.

Why a local server rather than a plain .html file: the Daikin module sends no CORS headers. A static page could fire commands blind (mode: 'no-cors') but could never read back the state, the temperature or the power figures. web.py proxies the requests and solves that.

MCP server

claude mcp add daikin --scope user \
  --env DAIKIN_HOST=192.168.1.50 \
  -- /path/to/.venv/bin/python /path/to/server.py

Or, in any MCP client, through configuration:

{
  "mcpServers": {
    "daikin": {
      "command": "/path/to/.venv/bin/python",
      "args": ["/path/to/server.py"],
      "env": { "DAIKIN_HOST": "192.168.1.50" }
    }
  }
}

Tools: daikin_status, daikin_energy, daikin_set, daikin_set_special_mode, daikin_list_devices, daikin_add_device, daikin_remove_device, daikin_discover.

When host is omitted, the default unit from devices.json or DAIKIN_HOST is used.

Layout

Troubleshooting

DAIKIN_DEBUG=1 python3 web.py
tail -f daikin.log

The log records every request to the unit and its raw response, plus events from the page if you set const DEBUG = true in web/index.html. Note: the log contains the unit's IP, MAC address, SSID and id, which is why it is in .gitignore.

Protocol notes

Gathered by testing against a real unit (BRP069, adp_kind=2, firmware 4_0_3). There is no public documentation for this API, so most of what follows was worked out empirically. Other modules or firmware versions may behave differently.

• The endpoints are plain GET requests with no authentication, returning comma-separated key=value pairs with percent-encoded values.

• set_control_info wants the complete set (pow, mode, stemp, shum, f_rate, f_dir) on every write and resets whatever is missing. Hence the read-modify-write in the client.

• Each mode remembers its own setpoint in dt1..dt7. When the mode changes without an explicit temperature, the client reuses the new mode's remembered value.

• Dry mode uses dt2=M (no numeric setpoint), and fan mode may have no dt6 field at all — in those modes the temperature is not adjustable.

• Energy comes in units of 100Wh. datas from get_week_power is a legacy field that does not correlate with the rest; use get_week_power_ex instead (index 0 = today). Verified by comparing against the hourly series from get_day_power_ex.

• Special modes are read from the adv field, separated by /. The write parameters are not the codes from adv:

  Mode	Code in adv	How to write it
  powerful (on)	2	set_special_mode?spmode_kind=1&set_spmode=1
  powerful (off)		set_special_mode?spmode_kind=1&set_spmode=0&en_powerful=0
  econo	12	set_special_mode?spmode_kind=2&set_spmode=0|1
  streamer	13	set_special_mode?en_streamer=0|1

  Switching powerful off requires en_powerful=0 alongside set_spmode=0; without it the unit answers ret=OK and does nothing. en_powerful on its own returns PARAM NG.

• The unit silently ignores some special-mode commands: it answers ret=OK but adv does not change, especially when one command follows another closely. The client resends until adv confirms (up to 4 attempts).

• powerful and econo are mutually exclusive. powerful switches itself off after about 20 minutes, and opens the louvres wide while it is active.

• ret=ADV NG shows up occasionally on set_control_info. It was observed once, with powerful active and a changed setpoint. The hypothesis that "powerful locks the setpoint" did not hold: a later temperature change with powerful on went through fine. The client does not switch any mode off on its own — it reports the refusal and leaves the decision to the user.

• Error codes seen: PARAM NG (invalid or out-of-range parameter), ADV NG (conflict with a special mode).

Compatibility

Works with modules that expose the local HTTP API: BRP069A/B, BRP072A, BRP15B61 "Airbase", SKYFi. The path prefix (/ or /skyfi) is detected automatically.

It does not work with BRP069C and newer, which use HTTPS with a token, nor with the Onecta cloud. In that case the client returns an explicit message rather than a timeout.

License

MIT — see LICENSE.