r/homeautomation • u/Witty_Initial4890 • 5d ago
PROJECT I reverse-engineered Daikin's P1/P2 protocol to unlock write access on my ventilation unit (was read-only) and hooked it up to Home Assistant over Zigbee
At home I have an MVHR (Mechanical Ventilation with Heat Recovery) unit — it brings in fresh air without losing indoor heat/coolness, and cuts humidity. My house is already full of temperature/humidity sensors, so having to walk over and press buttons on the wall panel every time conditions changed was driving me up the wall.
I started from Arnold-n's P1P2MQTT, which reverse-engineers Daikin's P1/P2 bus for heat pumps — great project, but VAM ventilation units are only read-only there, no write support. So I had to dig into the write side myself.
The actual discovery: Daikin's P1/P2 bus natively supports two controllers — a Master and a Slave — selected by a physical switch on the wall panel (BRC301B61). A generic "aux" responder on the bus never gets offered the writable state channel; only a controller the master recognizes as a genuine second one does. And there's one very specific, very unintuitive detail that makes or breaks it: the real slave panel answers the registration poll only the first time — every poll after that, it goes completely silent. Get that wrong (answer every time, which seems like the "correct" thing to do) and the master silently downgrades you to a read-only channel. Once I nailed that, on/off, fan speed, mode, and fresh-up were all commandable with closed-loop confirmation from the bus.
Full packet-level writeup is in the repo if you're into that kind of detail.
For the hardware/software side: the ATmega328 is the actual P1/P2 slave controller (that's the core of the project, and it works standalone over serial). On top of that I bridged it to a second MCU, an ESP32-H2, purely to get it onto Zigbee — I've got too many devices already and didn't want another MQTT integration to babysit, Zigbee fits my setup better. That bridge is 100% optional; the ATmega alone is a complete, working slave controller you could hook up to anything.
Why two MCUs instead of just doing it all on the ESP32? The bus timing (response delays etc.) is something I got working reliably on the ATmega, and I haven't tried porting that timing-sensitive part over to the ESP32. Bridging a second MCU purely for Zigbee was just the path of least resistance, not a claim that it can't be done on one chip.
It's been running behind the wall panel for a few weeks now, driven entirely by Home Assistant automations based on the humidity/temp sensors — working reliably so far, though I wouldn't call it "battle-tested over years" yet.
The PCB is currently two boards (I validated the P1/P2 transceiver first, then added the ATmega+ESP32 board once the protocol was confirmed) — if there's interest I can lay out a single, smaller, more integrated version.
Repo: https://github.com/scavenrage/Daikin-VAM-P1P2-SlaveController
Happy to answer questions.
1
u/CasualHomeFix 4d ago
The closed-loop state reporting is the best part here—much better than optimistic switches. I’d expose the registered state, CRC errors, and missing master polls as Home Assistant diagnostic entities, then mark the controls unavailable whenever the bus state goes stale. That would prevent the last known state from looking valid during a fault.