feat: add Panasonic A/C protocol and Hong Kong/Macau model

[sam0737]

Summary

Adds support for encoding Panasonic air-conditioner IR signals.

Following review, this was reworked to build on the existing Kaseikyo (AEHA) support rather than adding a separate framing layer: a Panasonic A/C frame is a Kaseikyo frame with the Panasonic vendor address 0x2002, and the full state is simply two such frames. The only missing piece in KaseikyoCommand was multi-frame support, which had been removed in 869f5d8 (#27) and is re-added here.

Changes

• commands/kaseikyo.py — re-add multi-frame support. KaseikyoCommand(data=...) now accepts either a single bytes (one frame, unchanged behaviour) or a list[bytes] (several same-address frames emitted as one message, separated by an inter-frame gap). Single-frame callers (e.g. the Panasonic ceiling light) are unaffected.
• commands/panasonic_ac.py — a generic, model-agnostic Panasonic A/C encoder built on KaseikyoCommand:
  • PanasonicAcCommand — full 27-byte state. Keyword-only __init__ exposing the complete field set (power, mode, temperature with 0.5 °C step, fan, two swing axes, nanoex) with sensible defaults, so callers drive whichever combination their unit supports. temperature is validated against MIN_TEMP/MAX_TEMP.
  • PanasonicAcToggleCommand — the short 16-byte Quiet/Powerful toggle frame.
  • Field values are IntEnums carrying the protocol nibble as their value (no lookup dicts): PanasonicAcMode, PanasonicAcFanSpeed, PanasonicAcSwingAxis1 (byte 16 low nibble), PanasonicAcSwingAxis2 (byte 17 low nibble), and PanasonicAcToggle.

Notes (responses to review)

• Dropped the HK-specific class. PanasonicAcHkCommand and the separate framing base are gone; everything is the generic PanasonicAcCommand on top of Kaseikyo.
• Swing is modelled per protocol slot, not physical direction. The physical louver a slot drives depends on the unit (window units: axis 1 = horizontal; split units: axis 1 = vertical, axis 2 = horizontal), so the enums are named Axis1/Axis2 and the caller maps axis → real-world direction. The 2-axis swing values follow the IRremoteESP8266 constants.
• Timings use Kaseikyo's canonical base unit (~421 µs at 38 kHz) rather than the ~432 µs Panasonic-AC values; the small delta is well within IR receiver tolerance (will re-verify on hardware).

The reverse-engineered protocol (frame layout, field encodings, checksum, timings) is documented here: https://github.com/sam0737/panasonic_window_ac_hk/blob/main/custom_components/panasonic_window_ac_hk/PROTOCOL.md

Testing

• tests/commands/test_panasonic_ac.py — encodes through the full stack, then decodes the raw timings back to bytes and asserts against the documented known-good frames. This keeps the tests robust to Kaseikyo timing-constant tweaks (those exact timings stay pinned in test_kaseikyo.py). Plus field-level checks: power bit, nanoeX, both swing axes, and out-of-range temperature.
• uv run pytest -q — all pass.
• uv run prek --all-files — ruff + basedpyright pass.

Related work

This backs the Home Assistant panasonic_window_ac_hk integration (see home-assistant/home-assistant.io#45662), which has been updated to map its state onto these generic commands once this is released.

Made with Cursor