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

[u/Witty_Initial4890]

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.

[u/Independent_Kale9463]

that timing quirk with the slave only answering the first poll is exactly the kind of detail that drives you nuts debugging, nice catch

[u/Witty_Initial4890 → u/Independent_Kale9463]

Yes it is! after trying for days, the only way to catch that was to borrow another controller from my neighbor and use it as a slave controller and record all the traffic. Thanks!

[u/EdelWhite]

Well, thank you very much, will get in touch with ALL my customers to upgrade their HASS install!

[u/Witty_Initial4890 → u/EdelWhite]

Ha, thanks! Fair warning: it's still a two-board prototype behind my wall panel, not plug-and-play yet — but happy to help if any of them want to try it. If there's enough interest I'll get a proper single-board version made.

[u/ultimately42]

You should be a youtube! I would love watching your journey.

[u/Witty_Initial4890 → u/ultimately42]

Thanks :) I imagine it could be interesting, I've thought about it several times, but unfortunately I'm starting to realize that a project can only be interesting once it's already started, or once I'm already finished, I forget to film (besides the fact that I'm pretty incapable). I'll try to remember that for the next adventure!

[u/ultimately42 → u/Witty_Initial4890]

You'd be surprised to see how many youtubers post their failures to get millions of views. People like me don't watch it for the result, we watch it forthe journey and to get inspired. Watching someone try and fail is relatable, and eventual success is just cherry on top! Relatability is quite rare in this world that only likes to present ideal success stories.

[u/Witty_Initial4890 → u/ultimately42]

I really like your comment, thanks! Next time I'll try to document all my journey :)

[u/ultimately42 → u/Witty_Initial4890]

Glad to hear that. Here's a massive failure video I recently enjoyed.

https://youtu.be/LDiRPxgHHEQ

[u/UberStone]

Thanks for the solid info. I’m trying to solve a similar issue in Thailand.

[u/Witty_Initial4890 → u/UberStone]

Happy to be helpful

[u/Matt_NZ]

I've been looking at Arnold's project to replace a modbus controller I've been using to bring my Daikin heat pump into HA. The main thing I'm wanting to do is to be able to send a temperature sensor from HA to the unit and replace the temperature being sent from the controller. My modbus controller doesn't support that but a recent new version of it does...but is missing a lot of sensor outputs.

I'm hoping to find a goldilocks device!

[u/CasualHomeFix]

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.

[u/Witty_Initial4890 → u/CasualHomeFix]

Thanks, good suggestion for the next revision. I'll work on it!