I have a Panasonic W18BD3P (ducted/commercial unit) that I’d like to integrate with Home Assistant. The unit only has a wired controller (CZ-RD514C type) connected via a 2-wire bus — there’s no CN-CNT or CN-WLAN port on the PCB, so the DomiStyle/esphome-panasonic-ac project and the IngeniousMakers hardware don’t work for this unit.
I’ve started sniffing the 2-wire bus with an ESP32 and a simple voltage divider, and I’m making some progress decoding the protocol. It’s a low-speed serial bus (inverted logic, 12V idle) with structured polling rounds.
Before I go too deep down the rabbit hole — has anyone else been working on the Panasonic PACi / ECOi / commercial wired controller protocol? I’ve searched extensively and found plenty of work on the domestic CN-CNT protocol, but nothing on this 2-wire commercial bus.
Specifically I’m wondering:
Has anyone reverse-engineered the protocol used by Panasonic wired controllers like the CZ-RD514C, CZ-RTC5B, or similar?
Is anyone aware of open-source projects targeting Panasonic commercial/PACi units via the wired controller bus (not CN-CNT)?
Does anyone know if this protocol is related to Panasonic’s P-Link bus?
Anyone with a similar Panasonic commercial unit (ducted, cassette, PACi series) who’d be interested in collaborating?
I’m happy to share what I’ve found so far and my sniffer tools if others are interested in working on this together.
Very superficial wild guess: RS485 protocol, with ModBus. Very common in commercial setups to connect multiple units together.
This wizard may make life considerably easier for you if that is the case.
Alternatively, it might be the common protocol that modulates a 24V AC link. Have you checked the two wires on AC with your multimeter as well as DC? Wires and connections marked W and R are a common giveaway.
Have you examined the service manuals? They often have wiring diagrams and discuss protocols. Work backwards from your controller to see what main units it is compatible with. I would be surprised if there wasn’t a generic internal protocol that applied across a generation of Panasonic devices.
Does the device support infrared or WiFi control. Check what pins are used for that.
Examining data sheets for chips the wiring connects to at either end can often yield clues. Most chip vendors release application notes and the examples given are often used as a template for final design.
I’ve checked with a multimeter — the bus is DC, around 12V idle. So it’s not a 24V AC modulated link. I also don’t think it’s RS-485 — the signal behaviour on the oscilloscope doesn’t match RS-485 characteristics, and the Intesis gateway manual for PACi units (INMBSPAN001R000) describes the R1/R2 bus as a simple two-wire bus with no polarity, which is different from RS-485’s differential pair.
I’ve opened the wired controller and the indoor unit PCB. The controller uses a Renesas H8/3823 MCU with discrete transistors near the bus connector — no MM1192 HBS chip, no coil. No IR receiver either (it’s a concealed ducted unit), and no WiFi module or CN-CNT port.
I’m currently sniffing the bus with an ESP32 and a voltage divider. I can see structured data coming through but I’m still working on confirming the exact baud rate and framing. It’s definitely a proprietary Panasonic protocol.
Good suggestion on checking the chip datasheets — I’ll look into the Renesas H8/3823 application notes to see if they reference any communication peripherals that could hint at the protocol.
I would be very interested in assisting with this. I have an abode with a CZ-RTC4. It should be fairly easy to reverse engineer this protocol if somebody has access to the right tools.
The voltage divider method I think is too primitive, but a good start none the less @hugojm.
I am experienced with all sorts of ESP32 - but the trick will be building an interface to modulate the 2-wire 12v interface. Some captures with a scope would be a great start.
Hi Hugo very interested in this project I have a Panasonic mini vrf with 7 indoor units. With th R5 controllers if I can be any help let me know. How did you wire in the voltage divider?
Hi guys!
I am trying to debug the signal from the controller but I am having a hard time trying to get the patterns. Probably it is because my setup with the esp32 is introducing a lot of noise.
Any recommendations on the hardware that I should be using to decode the signal?
Start with the idle signal first with the controller turned off. So you can use that as a reference point once you verified it’s the same data every capture then move on to turning the controller on then off. A better idea than using a voltage divider would be an octocoupler
Can you share detail signal with the Oscilloscope? I have studied it but since I am not own the heat pump, it is hard. This this the schematic of the CZ-RD514C
I have the S-71WF3E with the cz-rtc6blw remote.
Looking for basic hvac control, but also at least nanoex and static pressure control.
It must be possible over the R1R2 bus as some remotes (not mine) have the static pressure setting capabilities. And nanoex can be toggled on most remotes and over H&C app (over ble)
I have the hydronic/dhw side hooked up via heishamon/esphome, and have another isolated 5v level shifted uart bus available, do our units really have nothing compatible?
Update — oscilloscope measurements (revising my earlier "not HBS" assessment)
I finally got proper scope captures of the bus while it's being driven by the active controller, and the numbers are interesting, they actually push back toward HBS, contrary to what I concluded in my March post.
What I measured:
Idle level ~15.2 V, not 12 V. My multimeter was reading ~11–12 V because it was averaging; the scope shows the line idles high at ~15 V. That 15 V figure is right in the HBS range Arnold mentioned (15–16 V).
Active swing ~8.6 V — the line gets pulled down from ~15 V to ~7.6 V during signaling.
Encoding looks Manchester / bi-phase. At 20 µs/div I see two distinct pulse widths (a ~21 µs half-cell and a ~42 µs full-cell), not the flat rectangular segments you'd get from plain async UART.
Bit cell ~42 µs (base clock ~24 kHz, so roughly ~12 kbit/s).
Data comes in bursts/polling rounds repeating at ~11–12 Hz.
So: 15 V idle, ~8 V swing, continuous Manchester-style clocking in bursts. Electrically this looks a lot more like HBS/SIII-NET than the 12 V transistor interface I described earlier.
The wrinkle is that the hardware doesn't match cleanly: the controller PCB has discrete transistors near the bus connector, no MM1192 transceiver and no coil, which is Arnold's physical "tell" for HBS. So it may be a bus that's electrically HBS-like (voltage + encoding) but implemented with discrete parts rather than the usual MM1192 front end.
I've gone back to Arnold with these numbers and asked the key question: would the MAX22088 HBS front end on the P1P2 hardware be able to lock onto this bus directly, given the signaling looks right even if the originating chip isn't the usual one? If yes, that potentially turns this from "reverse-engineer from scratch" into "use existing hardware + decode framing," which would be a big shortcut.
@dzungpv — given the Manchester ~12 kHz / 15 V findings, does this line up with anything you've seen on the Daikin/HBS side? Happy to share scope photos and raw captures once I have a front end that gives clean bits.
Here you have some pictures of the oscilloscope in case you want to take a look
