Hack my Heat Pump and publish data onto emoncms

@Egyras I am also very interested in knowing about your experiences with extracting data via the CN-CNT connector. I own a H series Panasonic heat pump (WH-ADC0916H9E8AN). Could you share more information about the wiring and “magic” packet"?

@Egyras yes I own Panasonic SDC 9kW WH-SDC09H3E5.
As I know my Aquarea Wifi BOX ( CZ-TAW1) is connected by CN-CNT port.
How to read protocol values?

Just connect addtional USB to RS232 (TTL) and sniff with software as IOninja and you will have all information in HEX :slight_smile: Keep in mind that you can listen to RX or TX at once. But its just easiest part as decoding is required, which I did for most interesting values.
Here is my new repo -
Will publish deconding information later today.

Will post info here -

@Egyras I have ttl, but where to connect it?:wink:

I have provided all information in my github repo, just connect to existing TX or RX and use software as IOninja to get HEX values. So you connect to existing TX and GND to get values send in one way to sniff protocol between CZ-TAW1 and Heat Pump.


Just wanted to pass on my thanks. I now have this working, I can see the data and control my Altherma HT via the RTD-W over Wi-Fi.

Now I need to figure out how best to optimise it to run from my PV during the day, without importing any power if possible. Rather than switching on/off I was thinking about varying the Leaving Water Setpoint to reduce power load.

Any thoughts or ideas most welcomed.

Many thanks


@Egyras please help. I have to connect to cable between het pump and CZ-TAW1 ? which is which??
And what IOninja software to use ??

Hello GizmoB…

I am right in the middle of figuring this all out. I have two Daikin HT units talking thru the RTD to my Arduino and I am now trying to figure out what to do with it all… : )

My goal is to try and squeeze a bit more efficiency out of my setup. Depending on how you read Daikin’s sketchy info, the efficiency goes down by as much as 30% between extremes of outside vs circulating temp, or ~13% in my setup.

I figure that the heat output from the emitters is determined by the temperature difference between emitter and house. House temp varies a bit, but not that much, so heat output and hence heat load to the Daikins is determined primarily by circulating temp.

So, I believe you can reduce circ temp and hence demand on your heat pumps to match PV output, but your system will then deliver less heat inside your home on a cloudy day. Slightly worried that this could be the wrong way round…

I do have in mind to crank up the circ temp just before the end of the night-time electricity rate, my thinking being that it will store more heat inside the house while I can get it at cheap rate, so reducing demand during daytime, which is similar-ish to your problem. That does involve giving the thermostats a nudge too, but that’s a separate project…

Do you have a buffer tank…? Seems like it would work well to crank the temp up inside your buffer when the sun is out, then draw on that heat in the shade…?


1 Like

Just a short status update: plan C works. An MM1192 IC with an (SI8621) digital isolator and a (Murata) isolated DC/DC converter is able to read the P1/P2 bus, and to write to the P1/P2 bus. The heat pump answers any request sent to it, even if the requests are out of the usual order. I am running it now for weeks, and uploading the received data to my local emoncms works very reliably. The full schematic and code is on The emoncms glue code is not on github yet, but it is model-specific and reasonably trivial.


Hi @bart.ellast, could you give us any details about this RS232 converter? Does it connect to the P1/P2 interface on the Altherma heat pump, or something else? Is it the official Daikin EKPCCAB1? The Altherma LT (EHBH08CB etc) installer reference manuals talk about using this cable to configure settings remotely. Is your Daikin an LT or HT model?

Thanks, Chris.

Hey guys. I own the WH-MDC05H3E5 heatpump with the CZ-TAW1 module.
After some days of trial and error, I am now able to automatically read the system values (temperatures, pump RPM etc) out of the Panasonic service cloud to a json file. At the moment I insert it into an influxDB

I am optimistic, that I will be able to send commands to it in the future too.

Is anyone interested in stuff like that?I don’t want to share it too publicly at the moment, because Panasonic invested quite some work to make it extra hard to read the values if you do not use a web browser on the service cloud site

I’m interested.

I am also interested. Thx.

Me too. I’m trying to do the same with a couple of Panasonic air-conditioners.
Got a serial link working, but the ‘magic packet’ just gets echoed.

Many thanks @tarmo_r for the sample code! I never would have figured out how to use the API without that.

Also thanks @krakra for reverse engineering and posting the Online Controller (BRP069A61/2) API! There is more information about it, including additional endpoints I think, on the OpenHab community forum.

I contacted Realtime Controls, who make the Modbus interface, to confirm whether or not it was expected to work with a Daikin Altherma LT/CB heat pump (having been designed for the LT/CA) and they replied:

We currently do not offer any interface that is compatible to the Altherma LT CB series.
We are working on the development of the new product that would be compatible with Daikin Altherma CB series. We will keep you updated. However, we are unable to confirm when it will be ready until it has passed all the tests and validations.

So hopefully good news is coming soon on that front.

Hi Michael, can I confirm that you connected directly into the S21 port on your Daikin indoor unit and were able to get modbus working directly on the unit itself?

This is what I’m hoping to achieve. I’ve just ordered an RS485 HAT for my RPi and I’d like to get modbus working on my indoor unit. If you got this working, would you be able to post some photos of how you wired it up please?

Hi John,

Welcome to the rare breed of people with a deep obsession to hack into their heat pumps…!

First question is - which Daikin do you have…? My setup is around 5 years old now, and from your questions I have a feeling that yours may not have the same interfaces.

Second question is - what are you trying to achieve…? I wanted control over the leaving water temperature, so I could swizzle it up and down based on demand in my own particular way…

Daikin have a proprietary interface from the indoor unit to the control panel, loosely called “P1-P2”. Some guys on here have hacked directly into P1-P2, which is genius. I took a more conventional route and found a couple of “RTD-W” interface units on Ebay. The RTD’s are a custom product produced for Daikin and are specific to the model of heat pump that you have. The RTD unit converts from P1-P2 to Modbus.

Next thing is to have a serious look at the Arduino if you haven’t already. My setup has both Pi + Arduino, but I basically use the Pi to remote into the Arduino, otherwise I have to live in the cupboard to complete my obsessive programming…

I don’t have experience with Modbus on Pi, sorry. The Pi has so many layers of operating system n drivers n processes to wade through, whereas the bare-bones approach with Arduino gets you straight to the hardware. I think the original post at the top of this forum worked direct from Pi to Modbus, so I’m guessing its possible…

Arduino has loads of libraries and tons of help online. I didn’t have much problem finding the “Modbus master” library that admirably chuffs Modbus packets in n out and built up from there.

I’ll stop waffling now… just to say that my comments on RS485 refer to the pin naming, where long ago some muppet decided to give the two wires four names - “+”, “-”, “A” and “B”. My tip is to ignore the “A” and “B”, which were defined ambiguously and wasted a week of my life. Connect “+” to “+” and “-” to “-”. After that it all sprang into life…

Good luck…!


I have a Daikin Altherma HT, a RTD-W and several RS485 modules.
I tried to read modbus registers from my PC with ModbusDoctor.exe but i have no answer from the module.
I tried your code on a esp8285 (it’s like esp8266). I set RTD-W id to 2, as in your code.
No more results.
I tried to reverse pin A and B.
I tried 2 differents RS485/TTL modules.
Do you have any advice for me?

Thank you


Hello everyone,
just a status update, in case anyone’s still interested in S21…
@gyrex: S21 is for sure not compatible with RS485 if that is what you asked.
S21 pinout is very simple: 1:+5V, 2:Tx, 3: Rx, 4: +12V, 5: GND
S403 pinout: 1:+15V (power for wireless modules), 2: JEM-A OUT (pull-down=ON), 3: JEM-A IN (pull-down=toggle switch), 4:Tx, 5: Rx, 6:GND, 7:GND, 8,9:NC, 10: ~327VDC
Now, S403 is split by adapters like KRP067A41E into 4pin JEM-A connector and 5pin S21, using optoisolators on Rx,Tx,J-in,J-out. I can post detailed pinouts of all adapter connectors if anyone is interested, but generally these boards are not required as far as I can tell.
I have successfully connected BRP069B41 wireless module directly to S403, using pins 1,4,5,6 (wifi module does not use 5V on S21:1 at all).
I have also managed to connect arduino to JEM-A directly on S403 - pin 2 with 10K pull-up detects if aircon is on or off (1=off,0=on) and pin 3 can switch current status by shortly pulling it to ground (S403 has it on 5V by default).
The Rx/Tx are pretty much equivalent on S403 and S21, the adapters just add optoisolation. It’s definitely full-duplex data link with a 5V pull-up, but I have no idea what protocol is used there. For a moment I hoped it could be uart, because BRP069B41 (not connected to aircon unit) kept sending same short burst every 0.5s which looked almost like 5 bytes with checksum on 2400baud serial (data 02h,46h,32h,78h,03h), which looked like ,payload,,<??>, but replaying the same bytes on 2400,8N1 and 8E1 uart straight to S403 got no response from the aircon unit. Connecting wifi module there did get a response and fully successful connection however.
I cannot say for sure it’s not a normal 5v uart - the pins are connected to pins 28 (TxD1) and 29 (RxD1) of M30280 MCU which would hint at uart, although both pins can also be used as standard GPIO pins.
Basic oscilloscope probes showed slight timing differences in the wifi output vs. normaln 2400baud uart sending the same data, so it might all just a strange coincidence with payload-lenght and checksum, or it may be that my usb/uart converter did not sufficiently match some other electrical or timing requirements of the aircon MCU.
I have already ordered another wifi module for the same type of unit (FTXB-C, which according to all the specs should not be compatible with them, but we all know how the public documents work…), I plan to do additional tests there with S403/S21 adapter in place, and eventually also hooking logic analyzer probes to both Tx and Rx to captute full communication between wifi and MCU, but that may take another month or two.
Meanwhile I have connected the wifi unit to mobile app and verified it works fine, all the sensors and control work, even wifi-module firmware upgrade went fine. Communication seems to match the HTTP protocol documented here for example (, at least some subset of it (get_timer returns 404 not found for example but that might be because FTXB-C does not support that functionality).
Another thing I plan to do when new module arrives is retrieving full content of the SPI flash chip, which may be possible to reverse-engineer for more internal info, although for sure not trivial. Fetching firmware code from aircon unit seems unlikely, as the code is on the MCU chip, which I could not even exactly identify. It’s a TQFP80 with markings “M30280DKFA”, which makes renesas M30280FAxx most compatible (96k flash, 4k ram), but I have not found any mention of “DK” anywhere so it may just as well be something specifically manufactured for Daikin, thus invalidating any MCU internals found in official datasheets.
Another thing I’ve noticed (and used for oscilloscope probing) is the 3+4pin S24 connector on the main control PCB, which has among others also the Rx and Tx signals routed (top left):

It looks like some kind of debug interface, might be worth to trace all the pins to MCU or power, and do some oscilloscope probes there.
Uff… if anyone read through all of this ranting and has some ideas, let me know :wink: