Hack my Heat Pump and publish data onto emoncms

A single electrolytic doesn’t. But two connected back to back, do.

Hence my statement, in a pinch. i.e. if nothing else is available at the moment, and you
wanted / needed to test circuit operation. IOW, a temporary workaround.

Hi
Sorry for delayed reply, sharing my Python code:

from websocket import create_connection
import json, datetime, time, urllib2, urllib
ts = time.time()
timestamp = datetime.datetime.fromtimestamp(ts).strftime('%Y-%m-%d %H:%M:%S')

ws = create_connection("ws://192.168.2.4/mca")

ws.send("{\"m2m:rqp\":{\"op\":2,\"to\":\"/[0]/MNAE/1/Sensor/TankTemperature/la\",\"fr\":\"/TarmoTest\",\"rqi\":\"xijub\"}}")
result1 =  json.loads(ws.recv())
ws.send("{\"m2m:rqp\":{\"op\":2,\"to\":\"/[0]/MNAE/1/Operation/TargetTemperature/la\",\"fr\":\"/TarmoTest\",\"rqi\":\"yssyq\"}}")
result2 = json.loads(ws.recv())

#print("Received temp '%s'" % result1)
#print("Received target '%s'" % result2)

tankTemperature = result1["m2m:rsp"]["pc"]["m2m:cin"]["con"]
tankTargetTemperature = result2["m2m:rsp"]["pc"]["m2m:cin"]["con"]

urllib2.urlopen("http://xxxxx.yy/recv.php?timestamp=" + urllib.quote_plus(str(timestamp)) + "&type=daikinTankTemp&measurementValue=" + str(tankTemperature))
urllib2.urlopen("http://xxxxx.yy/recv.php?timestamp=" + urllib.quote_plus(str(timestamp)) + "&type=daikinTankTargetTemp&measurementValue=" + str(tankTargetTemperature))


ws.close()
1 Like

Hi,
my MM1192 already arrived. I can confirm that the suggested circuit works, I can read the data stream on pin 1. The P1/P2 bus is busy all the time.

Yes, you are right. I tried some basic decoding techniques in-built within the Saleae Logic Software, but no success, I can only see individual bits. I am stuck here, this is beyond me.

I am ready to help in the next phase whith the decoding of commands etc. but at the moment
I have to wait for help from others (Arnold). Modified AltSoftSerial library would be nice. I have some spare Arduino Uno which I want to use for data conversion.

Hi Kra,

Good to hear that the receiving part works! My MM1192 chips arrived today, but I have yet to connect them to the Arduino and the Daikin. I started rewriting the AltSoftSerial library for the HBS protocol but have yet to test it in real-life. I will let you know and share when it works.

I would be interested to hear what you plan to do with it - and perhaps from others here too. My end goal is reducing the number of defrosts, improving the overall average COP, and reducing the system noises. First goal is to understand the received bits and see if we can calculate the COP at all.

My main motivation is better integration into my home automation system (Loxone):

  1. Better remote control over the Daikin unit. At the moment my options to control the unit remotely (via the LAN adapter) are very limited. I can turn the unit on and off. I can set the “target room temp” remotely, but this is of no use for me, because Daikin measures the “actual room temp” through the control unit mounted on the hydrobox.
    I can control the LWT manually on the control unit, but unfortunately, it is not possible to control the leaving water temperature through the LAN adapter (when you switch the unit to the LWT mode, the unit simply disappears from the LAN interface!). I have thermoelectric valves to regulate floor heating in each room and I would like to set the leaving water temperature depending on the actual demand (how many rooms are heated, what is the actual and target temp in these rooms). I am quite satisfied with defrost cycles on my unit, but I want to control the output (leaving water temp).

  2. Monitoring. It is really frustrating. The control unit receives (through P1/P2) all the data about flow, leaving and returning water temperature etc. The control unit knows how much energy was consumed and produced each month (I can manually calculate average COP for each month). But that stupid LAN adapter knows nothing. Not even the information whether the heat pump (compressor) is running at the moment… Yes, I would also like to calculate COP in real time. I think it should be possible once we have the data from P1/P2. For sure, we will have the data (flow and LWT) needed to calculate the energy produced in real time. I think (hope) that there will also be real time data about (estimated) electric energy consumption. My unit does not have a dedicated electric meter, but it does somehow estimate the electric energy consumption. I am not sure if it provides real time data about the (estimated) electric data consumption through P1/P2. If not, one can always install external electricity meter - I will do that anyway to have more accurate data. In your case (hybrid), measuring the energy consumption could be tricky, I do not know whether Daikin measures gas consumption (gas flow) in real time…

Regarding my plans for the technical solution:

P1/P2 (HBS) <=> MM1192 <=> Arduino (serial) <=> Loxone (UDP)

At the moment I know how to do and successfully tested in real life:
P1/P2 => MM1192
Arduino (serial) <=> UDP

And these are my technical plans for monitoring:

… Arduino (serial) <=> UDP <=> Raspberry Pi (Node Red) <=> InfluxDB <=> Grafana

Successfully tested in real life:
Arduino (serial) <=> UDP <=> Raspberry Pi (Node Red)
InfluxDB <=> Grafana

At the moment playing with:
Raspberry Pi (Node Red) <=> InfluxDB

I know, this forum is dedicated to " Emoncms" but I honestly admit that I do not use the system for monitoring.

After some modifications to the circuit and finishing up what I have called the P1P2Serial library and P1P2Monitor program, I managed to (very) reliably receive data from the P1P2 bus and decode it for my heat pump. You can find the code, documentation, and first protocol analysis results on GitHub - Arnold-n/P1P2Serial: Monitor and control Daikin/Rotex (hybrid/Altherma) heat pumps via the 2-wire P1/P2 thermostat interface with an ATmega328P, ESP8266, and electronics. The P1P2Serial library and P1P2Monitor program perform low-level bus operation, the P1P2-bridge-esp8266 program interprets data from/to MQTT supporting Home Assistant MQTT discovery. P1P2Serial may also be used for other Japanese Home Bus System based standards: DIII-NET (F1/F2) bus, Mitsubishi M-Net bus, Toshiba TCC-Link, Hitachi H-link, Panasonic/Sanyo SIII-Net, Haier, York, and others.. Would be very interested to hear whether it works for you too.

As for whether to use emoncms or not - I haven’t decided yet. First the P1P2 bus input should be converted into a form that is easier to handle.

Good luck!

2 Likes

Hello there…

I have two Daikin HT units, which I have been determined to hack for a while now. I recently picked-up two RTD-W’s on Ebay for a reasonable price n now I’m trying to get them to talk to me n they flipping wont…!

I have an Arduino, with an RS485 interface and I picked up the Modbus Master library, sketched out a bit of code but my RTD’s just time out on me. Then I got an RS485 dongle for my PC and tested my Arduino against pyModSlave (seems like a genuine enough bit of code) and that was happy with my ModBus efforts. Then I tried my RTD’s using ‘QModMaster’ and again no reply to my advances…

RTD’s seem happy enough. Connected one in to my heat pumps via P1P2 and the LEDs all lit up the right way, but still no reply over ModBus.

Bit stuck now… Just wondering if you had any hassle with Modbus and if there are any magic runes I missed…

Michael

Ok, got it now. Turns out that some bright spark had the idea to give the RS485 pins two names each - A / B and + / -, but then made the extra letters ambiguous. Wikipedia has a nice description of it (note to self, extra donation this year…) Swapped them round n it worked straight away.

Sorry not to add much to the discussion here. Nothing but respect for you guys, hacking into the P1/P2 connection. Genius.

Right, onwards and upwards. Still, look on the bright side, at least I didn’t just waste two days of my life chasing down a 20 year-old documentation bug for nothing.

Oh, actually, yes I did…

M

It wasn’t us! We’re aware that the serial connections on the emonTx are labelled wrongly (i.e. not conventionally - the pin labelled TX is looking for transmitted data and so you DON’T cross-connect RX-TX & TX-RX as is convention, it has already happened on-board) but it’s been decades since I touched Modbus, so I hadn’t come across that one, or if I had, I didn’t remember it.

Excellent job Arnold, thanks a lot!

CIRCUIT
I have the same experience with the circuit. The original schematics did not work for me. With modifications (1) and (2), the circuit works OK. There are errors, but still OK for the purpose of decoding the data. I am too scared to do modification (3).
Did you try to connect the transmission part of the schema? Maybe the readability of P1P2 improves once we have the transmission part connected.

DATA
It works! I am able to read the data with Arduino Nano and your P1P2Serial, P1P2Monitor. The good news is that protocol data format is very similar. With some minor differences:

  • Some packets are longer (400013, 400015)
  • I have some additional packets (000016, 400016)

You can find my initial readings in this Excel file.
P1P2.zip (22.3 KB)

Each packet (I only did the data packets) has its own sheet in xls. My readings (hex) are in the 3rd column, GREEN means I have confirmed your readings. ORANGE means something new or different from your readings.

My next plans: connect Arduino (via USB/serial) to Raspberry running Node Red. Once I have the data in Node Red, it will be much easier for me to filter the data and detect changes to the data. Maybe there are easier ways to do that, but I am not a developer. Node Red is one of the few programming tools I am familiar with.

Oh and about my Daikin: Altherma LT EHVX08S26CB9W. Two heating zones (main, add). Main is used for floor heating, additional zone is for ceiling cooling. My unit is currently in “RT control” (thermostat control), weather dependent.

Great to see it working, and glad it is helpful to you! Actually I am surprised to see so many similar data in a different heat pump type. This is really helpful to better understand the format.

If you are afraid to do modification (3), there is always a plan B and C. I don’t think it helps to add the writing circuitry to improve the reading reliability. Plan B: I looked into the circuitry of the thermostat itself, but haven’t tried copying that yet. The thermostat uses a MM1192, and it does not use the resistors of modification (2), but it does use 130k Ohm resistors instead of 100k Ohm resistors in modification (1). It also has ferrite beads in the incoming P1/P2 lines. Plan C: I am preparing a slightly more complex schematic including a SI8662 digital isolator to provide galvanic isolation so it is safe to do modification (3).

I haven’t tried writing at all yet, as writing is not easy: how to sync writing with the messages from the thermostat? And above all, I am not sure whether the heat pump will accept my written messages if they are not conforming to unknown rules. I noticed quite some "interesting" data patterns in the final "00F030…" message, which may be used as verification by the heat pump. There are two patterns in the “00F030” message. First, there is a "walking bit" that moves from one location to another, and stays for a number of messages in its place. How many messages it stays in a certain location is fixed (but different for each location). The first "00F030…" message after a restart is of a different type and indicates per byte how many packets the bit stays in that position. Additionally, some of these bytes fluctuate now and then (by -1 … +2), and this seems to happen more often after additional packets (such as a request for energy consumed) were communicated in a package. I don’t see a pattern in these yet. Not sure if the heat pump checks for this.

Meanwhile I have also looked at the data upon a (re)start. The heat pump communicates upon each restart (and upon request by the thermostat) all the field settings. For each field setting (for example [8-09] comfort heating temperature) 4 bytes are transmitted:

-the field value (often plus 0xC0 added)
-the minimum/offset value (to be added to understand the value)
-the maximum value
-a byte characterizing how to use this field: whether the step size is 5, 1, 0.5, or 0.1; whether the value involves a comma or not; whether the field is in use or not.

I need to document this also on github - later.

As to your data, just a guess, but could
-400016:4-5 bytes 0x0C1F be a 12.1 degrees temperature?
-000016:6-7 bytes 0x1432 be 20.2 degrees room temperature (a repetition of elsewhere)?

I think that instead of messing with the thermostat (main user interface) ↔ heat pump communication, better way would be to emulate some other device.

I have a LAN adapter, so I can have a look how it communicates. But I do not know whether LAN adapter has full access to the heat pump.

Another option would be to emulate second user interface (second thermostat). Daikin allows you to have 2 user interfaces (EKRUCBL) and it seems that both of them have full access. But Daikin requires some kind of synchronization between both user interfaces. From Installer Reference Guide:

For proper operation of the system, the local data on the two user interfaces must be the same.

If the data are not the same (do not know how this is detected), both user interfaces will display error and you need to do some kind of manual sync between the two.

I only have one user interface, so I can not sniff the communication.

@SubOrbit,

I have a Daikin Altherma HT and a RTD-W on its way to me along with a RS485 module.

I have built a lot of projects with the ESP8266 and also with serial (RS232) but nothing with RS485 or ModBus. Would you be willing to share your code as it sounds like just what I am trying to achieve and could save me a lot of time getting started with RS485?

Much appreciated.

G

Hey Gary, sure, I can share the code… Take a look at GitHub - SubOrbit/Daikin_HT_RTDW_modbus_esp8266

Hey Michael, sorry for the late reply. I see you have figured out the problem by yourself already… Yes, the pins are reversed…

@SubOrbit, thank you, it looks great, I look forward to trying this out soon.

Hey @Egyras can You describe how You managed to get data from Your Panasonic Heat Pump? Maybe some photos? It will be a lifesaver for me;)

@Kamil_Matuszczak
You need for H series Panasonic ? I did some Protocol “hacking” and have some values, but need to write a proper code in C++ for MQTT integration. Dont have time and my codding skills are very limited :frowning:
You need to send “magic” packet to query heat pump via serial

@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"?