Built-in A/C library: 66 protocols generated on demand, including a reverse-engineered Dawlance

[hammad42]

What this changes

Air conditioners are the reason this device is annoying to set up. An A/C remote
never sends "temperature up" -- every button transmits the unit's entire
state, so teaching one by hand means capturing every temperature separately,
and you still cannot use a combination you never pressed. Thirteen captures for
one mode.

This adds a built-in library that generates the frames instead.

66 A/C protocols. The 65 IRremoteESP8266 supports through IRac (Gree,
Coolix, Midea, Daikin, Electra, Fujitsu, Haier, Hitachi, LG, Samsung, TCL,
Toshiba, Argo, Airton…) plus DAWLANCE, implemented here. Pick a brand, set
mode / temperature / fan, and the device encodes the frame with the correct
checksum. A "save a whole temperature range" action creates one command per
degree in a single click.

Dawlance, reverse engineered. Not supported upstream -- its 72-bit frame
over a 6.7/3.3 ms header matches nothing in IRremoteESP8266, which is why those
captures decode as UNKNOWN. Derived from 18 captures off a real unit:

AA 11 <mode|power|turbo> <temp-16> 00 <flags> 00 00 <checksum>

byte 0,1   constant AA 11
byte 2     bits 0-2 mode, bit 3 power (09 on / 01 off), bit 7 turbo
byte 3     temperature - 16          (16 -> 0x00 … 28 -> 0x0C)
byte 5     base 0x44, bit 7 display light, bit 0 economy
byte 8     checksum = sum(bytes 0..7) XOR 0xAA

Preset packs in data/presets/, for remotes that cannot be generated at
all. The browser fetches a pack and posts each command to /api/import -- the
same path a restore takes -- so adding a device to the library needs no
firmware change, only a new file and a line in index.json.
tools/make-preset.sh builds one from any backup.

Why

Generating beats shipping a code database, and not marginally. A database keyed
by combination needs thousands of entries per brand; the encoders already know
the frame layout and checksum, so one brand covers everything including
combinations nobody captured.

Storage follows the same reasoning. A generated command holds the standard
stdAc::state_t struct rather than timings -- 56 bytes against ~1.2 KB --
and is replayed by handing the struct back to the encoder, so the checksum stays
the library's rather than a reconstruction of it, and a library upgrade improves
existing commands for free. This needed no change to the store: the struct
rides in the existing payload, one byte per entry, flagged IR_FLAG_AC_STATE.

Pulling the encoded bytes out instead would have meant a switch with a case per
protocol; one struct covers all sixty-six.

Cost: 5.6 % of flash (68.2 → 73.8 % on esp32dev), leaving 26 % headroom.

How it was tested

• All four targets build, zero warnings: esp32dev 73.8 %, esp32dev_oled 75.8 %, esp32s3 35.0 %, esp32c3 75.6 %
• Web UI exercised in a browser against the mock: live preview follows every control, and the range action created four commands into the Air Conditioner group in one click
• Tested on hardware — ESP32-D0WDQ6, VS1838B receiver, 2N2222-driven LED, updated over the air:
  • 66 protocols listed; preview / send / save all work
  • a generated Gree command stores as 56 bytes and sends through the normal command path (tx: 'Gree Cool 24' (generated GREE))
  • out-of-range temperatures and unknown protocol names rejected with useful messages
  • Dawlance checksum: 18 / 18 captures agree
  • Dawlance encoder vs captures: byte-identical for all 13 temperatures plus power on, power off, eco, lamp off and turbo
• Documentation updated — API.md (endpoints, DAWLANCE, preset packs), USAGE.md (Library tab, placed before Learning)
• CHANGELOG.md updated under Unreleased

Notes for the reviewer

One field is a guess, and is labelled as one. Every Dawlance capture was
taken in cool, so only mode = 1 is measured. Heat, dry, fan and auto follow
the ordering these controllers usually use. src/ir_library.cpp marks it
INFERRED, and NOT verified at the point of use, and the docs repeat it. If a
mode turns out wrong, capturing that button still yields a correct raw command.

I refused to ship this generator earlier in the work because the checksum
was only half derived, and a wrong checksum produces commands that fail
silently. That objection is settled — the XOR form checks against 18 of 18
captures and the encoder reproduces every one byte for byte, on the device, over
the API. Everything except the mode field is measured rather than assumed.

The light default is deliberately protocol-specific. Every Dawlance
capture carries the display bit set, so it has to default on for that protocol
or generated frames would differ from the remote. The first version applied that
to all 66, which would have switched other people's displays on unasked; it is
now scoped to Dawlance alone.

HANDOFF.md moves onto this branch and supersedes the copy on
docs/handoff. That branch should be deleted rather than merged.

🤖 Generated with Claude Code