Support for EKH/RKH systems - such as Rotex RKHBRD016 (Daikin Altherma EKHBRD-ADV17), strange values about p1p2mqtt HOT 45 OPEN

My C is a bit rusty and the code is not the most accessible to make changes to so I wrote a short python script to validate my suspicion that the bytes are swapped. In the A trace I was able to get the 3 values I read on the controller like this:

data = """05084C2CD41704184818F414A9
05084C2CD417181848180C1557
05084C2CD41730183018F4140E
05084C2CEC17181830180C1530
05084C2CEC1718184818F41456
05084C2CEC17301848180C152D
0508282C0418181830180C15EC
0508282C0418301848180C15F1
0508282CD417041860180C1594
0508282CD417181830180C1512
0508282CD41718184818F41474
0508282CEC17041830180C15ED
0508282CEC17181830180C1557
0508282CEC1718184818F41431
05084C2C0418301848180C1596
05084C2CBC17181830180C1521
05084C2CD417181830180C1575
05084C2CD41718183018F41431
05084C2CD417181848180C1557
05084C2CD41718184818F41413
05084C2CD417181860180C1549
05084C2CD41730183018F4140E
05084C2CEC17181830180C1530
05084C2CEC1718183018F41474
05084C2CEC17181848180C1512
05084C2CEC1718184818F41456
05084C2CEC17301830180C150F
05084C2CEC17301848180C152D
05084C2CEC1730184818F41469
05086C2CBC17181830180C1534
05086C2CD41704184818F414BC
05086C2CD41718183018F41424
05086C2CD417181848180C1542
05086C2CEC1704184818F414F9"""

for line in data.splitlines():
    data = []
    for i in range(int(len(line) / 2)):
        data.append(int(line[2*i:2*i+2], 16))

    vars = data[2:4]
    print("{:2.1f}".format(vars[1] + vars[0] / 256))

So the value is like f8_8, except the function should be:

float FN_f8_8(uint8_t *b)            { return (((int8_t) b[0]) + (b[-1] * 1.0 / 256)); }

from p1p2mqtt.

Yeah, I have already started searching ebay and 2hands for something like that. No luck so far :-)

from p1p2mqtt.

That did the trick. I patched the f8_8 function to swap the bytes and now I get all stable readings

from p1p2mqtt.

That is why I created the PR. I am not sure on how much is shared between E* and EKH*. So first I am going to make the change in the E header and then decide on how to support both.

from p1p2mqtt.

Thanks @mrrepel for your feedback. Indeed RKH*/EKH* systems (which I think are called Altherma 2) are not as well supported as Altherma 3 systems. For now I think we would be able to modify the code such that it reports a number of sensor values (I hope at least some of the temperatures (49.000, 44.582, 33.906) are correct for your system even if the names used may be wrong). We will need to write a separate header file for the EKH systems. It would be helpful for me to receive your logs of raw data P1P2/R/# together with a description of system changes made during the log (on/off, target setings changed manually, temperature values changing as a response, so we can match these to the changes in the raw data logs).

There are a few EKH* users with the P1/P2 interface so this issue would be a good place to start sharing EKH/RKH experiences.

from p1p2mqtt.

Now that my holidays have started I picked it up again for my Altherma 2 (EKHVH008BB6WN). I can already report the following:

1. Set point values are decoded correctly. However the labels are not correct. The following changes need to happen.

   • S1_DHW_Setpoint_Response -> Target temperature leaving water. There is no room thermostat in my system, so room temperature is not the correct label I think.
   • S0_Target_Temperature_Room -> Target temperature DHW Tank

2. All measured values seem to have the wrong encoding applied. The jump up and down while on the controller itself only the value after the . seem to fluctuate. I "hacked" the NTC of my boiler with 2 relays so that I can let it measure the correct value, a very low value or a high value. I use this to make it heat only on solar in the summer. This also means that I can create an mqtt dump while the values change before the .

I have not dived deeps enough into but at the very least it seems that the byte order is different (or not fixed point at all). Often the part behind the . is stable while the part before it fluctuates a lot. The results of my experiment are as follows. The files attached are the dumps that correspond to the values the daikin controller reported. I wrote down all the values I saw:

A. 44.1 44.2 44.4
B. 31.5 31.6
C. 56.9 57

B.txt
C.txt
A.txt

Based on the changing values, my guess is that this sensor is labeled T1_Temperature_DHW_Tank

Once we can find the correct encoding, it should not be to difficult anymore to also correctly label all other values. They all report the same strange values.

from p1p2mqtt.

Hi @bartv - thanks very much, very useful information. I will set up a separate header file for EKH over the next week based on your findings.

The user manual for the EKHBRD-ADV17 system indicates that it supports a main controller (room thermostat) and a slave controller (2nd room thermostat, used for controlling but not really as room thermostat). If someone would have a system with 2 such controllers and make raw data logs when changing settings on the 2nd auxiliary/slave controller, we could determine whether the protocol between main controller (master) and auxiliary controller (slave) would function in the same way as on other (Altherma 3 or VRV) systems, and we would actually be able to control EKH/RKH systems too!

from p1p2mqtt.

The DHW setpoint response seems to be the "stooklijn" from the weather setpoint. This is the preset for leaving temp hot water for heating (when it is cold, the heatingwater will be warmer and vice versa, see graph). Setting 3 in the menu. I also use an external thermostat with the EKRP1AHTA interface card (dry relais), so there are no room temperature settings for me, S0_Target_Temperature_Room stays at 16 "C

Also the next sensors are correct:
S0_Heating_OnOff
S0_DHW_OnOff
S0_Quiet_Mode
S1_Defrost_Operation

Mismatches in names:
T1_Temperature_Refrigerant_1 seems to be T1_Temperature_Return_Water
T1_Temperature_Outside_1 seems to be T1_Temperature_DHW_Tank

Because i switch the heatpump on/off externally for heating i think these ones are correct to:
S1_Circulation_Pump_OnOff
S1_Compressor_OnOff

The warmtepomp on/off is a relais starting/stopping heating

Other values fluctuate, maybe the bitswapping as Bart stated.

from p1p2mqtt.

I did an attempt to update the firmware to already figure out the correct labels. I am unable to generate a working firmware using the arduino ide. It compiles and can uploaded (both using serial and OTA), the boards responds to a ping but it does not connect to MQTT and the telnet interface does not come up. I used my arduino ide before, even for esp* boards. I guess there must be some setting that is wrong?

from p1p2mqtt.

Hi @bartv, I think you have flash size set to default 1MB instead of 4MB. This value determines where the "EEPROM" (wifi/mqtt) data is stored. Even with 1MB selected, the WiFiManager AP "P1P2MQTT" should restart to allow entering your wifi/mqtt settings. If you change the configuration to 4MB, I think you will get the original settings back. Please let me know if that does not help - ultimate fall-back is programming with the USB programmer and "Erase Flash: All".

Also there are some changes needed to the BSP and libraries. The ESP_Telnet library owner implemented my suggestion for making the library working with ethernet differently than I did, so for the current ESP code you still need my modified version of the library, or #undefine ETHERNET, or change the code. I will update the code to allow the use of the official library now it is updated.

from p1p2mqtt.

Great, many thanks! I'll incorporate this change and the name corrections into the new header file for EKH/RKH systems, or if you prefer, feel free to do so yourself.

from p1p2mqtt.

I created a draft PR with my findings and experiments: #46

@mrrepel if you want I can also post a firmware image

from p1p2mqtt.

Thanks - I would suggest to use #ifdef EKH constructs to keep the original functionality maintained for Altherma 3, or to create a separate header file for EKH.

from p1p2mqtt.

@bartv , that would be really nice if you post the image.

Some logs from my system are added. If there is any need for specific logs / actions, please tell.
log1.txt

from p1p2mqtt.

I can confirm that the outside temperature is correct.

from p1p2mqtt.

@bartv , that would be really nice if you post the image.

Some logs from my system are added. If there is any need for specific logs / actions, please tell. log1.txt

P1P2-bridge-change.ino.generic.zip

from p1p2mqtt.

@bartv , that would be really nice if you post the image.
Some logs from my system are added. If there is any need for specific logs / actions, please tell. log1.txt

P1P2-bridge-change.ino.generic.zip

You might need to remove the integration from HA and let it discover again so that the renamed values are gone.

from p1p2mqtt.

I was able to figure out some more fields. Others are still work in progress. I create another repo with my scripts and current documentation:
https://github.com/bartv/p1p2decoder/blob/main/ekh.py

The summary:
https://github.com/bartv/p1p2decoder/blob/main/ekh.md

from p1p2mqtt.

Thanx Bart for sharing the firmware. Just finished flashing the ESP and after some trial and error i got the interface working again (fully my fault :-)).

The values and labels have changed, some readings work, others dont.

For my heatpump a combination of both could do the trick:

Greetings,

Barry

from p1p2mqtt.

Hi everybody. I'm using Arnold's interface with my EKHBRD011ADV17, and found the same results of the first part of this thread. I'll try to read the rest and report back.

For what is worth, my installation includes a RTD-W interface, which is connected to the P1/P2 inetrface and provides ModBus connection. I can manage some options and read and write (some) values with the ModBus connection, but not all of them.

If anybody wants me to test something, just tell me.

Thanks everybody for your work and regards.

Angel

from p1p2mqtt.

That would be really cool. It would be interesting if you can create two dumps:

1. a longer dump that just records what is going on when you are not making change. Mainly to see if and how there is interaction between the RTD-W and the main controller.
2. a short dump where you change setting through modbus

I create the dumps like this (replace with your mqtt server):

mosquitto_sub --host 192.168.32.23 -v -t "P1P2/R/040" > dump.txt

from p1p2mqtt.

@aluisperezh indeed as @bartv mentions: logs are useful both making no changes, when making changes on the main controller, and when making changes with the RTD-W.

Perhaps it is interesting to do a full log also when the system restarts, to determine if there is any particular extra communication with the RTD-W which is only there during/shortly after a system restart.

from p1p2mqtt.

I'm recording the "standard working" logs right now, but there are not many lines written: only one ("P1P2/R/078 R T 0.003: 40F0344B") in the last few minutes. Should I enable some verbose option or anything like that? I'll leave it recording all night and tomorrow I'll record some more changing things through RTD-W. Restarting the whole machine (I understand that that's what you mean, Arnold) is a little bit more difficult, but I'll try.

Regards

Angel

from p1p2mqtt.

Must be doing something wrong. No other lines in the output file but the one I saw yesterday...

from p1p2mqtt.

Must be doing something wrong. No other lines in the output file but the one I saw yesterday...

What command do you use to subscribe to the mqtt stream?

from p1p2mqtt.

This is what I'm using:

nohup mosquitto_sub --host 192.168.98.11 -u myuser -P mypassword -v -t "P1P2/R/078" > dump_standard_working.txt &

With mqtt Explorer I can't see any more messages. And I assumed that your 040 should be my 078 (final byte of IP address).

Regards

from p1p2mqtt.

I do not think so. You need the P1P2/R/... messages. So try this topic with a wildcard in it: "P1P2/R/#"

from p1p2mqtt.

There is nothing else there:

And I can see that the device is connected through telnet:

Edit: The wildcard produces the same results :(

from p1p2mqtt.

I restarted the Altherma machine. I won't be able to do it when I'm back home tonight, so I did it now. There are no other lines besides the one I sent yesterday, but the telnet session gives some more info. I have attached what I could see there.

My P1P2 device is powered by the P1P2 interface, so everything is restarted. I mean, no commands provided through telnet or any other way.

I can connect trhough telnet or to the MQTT server from home, so I can do some tests later.

Regards
Angel
Conexión Telnet.txt

from p1p2mqtt.

Hi @aluisperezh , thanks and interesting. [edit: the settings above only show messages with errors, not the real data, which is below in the compressed ZIP file.]

MQTT explorer cannot easily log all the P1P2/R/# data, but in telnet you will see all raw hex data by entering the command
j13013
Could you try that?

from p1p2mqtt.

Wow. More than 1M of text in a few minutes... I attached the zip-compressed file. Now I'm trying to find out how to update the firmware without breaking everything (I'm an expert on doing that). As soon as I do it I'll try to get both MQTT and telnet info.

Regards.
telnet_j13013.zip

from p1p2mqtt.

MQTT explorer cannot easily log all the P1P2/R/# data, but in telnet you will see all raw hex data

I have a small python program for logging mqtt topics to file as telnet is bothersome.
If needed I can share.

from p1p2mqtt.

Thanks for your inputs. My analysis so far is that there are differences:
@bartv has a EKHVH008BB6WN
@aluisperezh and @aluisperezh have a EKHBRD* system
and the raw packet data format is not the same.

For the EKHVHV, there are unfortunately no 00F0* messages in the logs above, suggesting the system does not support an auxiliary controller, whereas for EKHBRD* systems there are 00F0* messages and communication between main system and RTD-W, and the communication style is closer to the F* Daikin models than to the Altherma 3 models.

Packet type 000010 (from main controller):
-EKHVHV: 17 byte payload with a number of settings
-EKHBRD: 18 byte payload with a number of (similar) settings

Packet type 000011 (from main controller):
-both: 3 byte payload, likely with last 2 bytes representing measured room temperature (LE)

Packet type 400010 (from EKH):
-both: 20 bytes, with somewhat similar structure

Packet type 400011 (from EKH):
-EKHVHV: 12 bytes, 2 bytes unknown followed by 5 temperature sensors (BE (!))
-EKHBRD: 12 bytes, 2 bytes unknown followed by perhaps 5 temperature sensors (LE)

Packet types 38 with header 00F038/40F038 for main-aux control data (EKHBRD only) are
00F038 00 00 01 00 41 00 0A 00 20 00 08 00 00 00 00 00 00 06 00 05
40F038 00 01 00 41 00 0A 00 20 00 00 00 00 00 05
and most of these settings relate directly to the heat pump status information in 400010 from EKH to main controller:
400010 00 00 01 00 41 00 0A 00 20 00 18 00 00 00 00 00 02 00 00

It would be interesting to monitor 00F038* and 40F038* when making changes on the main controller and via RTD-W, and match time of these changes.

from p1p2mqtt.

Thanks for the info, Arnold. I will try to make some changes through RTD-W while monitoring the P1P2 device, but I'm not sure about timing. I manage RTD-W through Home Assistant, which is NTP synchronized, but I don't remember assigning an NTP server to P1P2. Let's hope Mosquitto in HA is in sync. I'll try to make changes with some time in between to be sure they don't get meses.

I can't try this until monday morning, but I'll be back with the results.

Thanks again everybody.

Edit. I don't think we can see those packets in MQTT, so I'll use telnet. Any way to show some kind of time stamp there?

from p1p2mqtt.

Hi @aluisperezh, and indeed I meant to log telnet while making the changes; time is then derivable from the 00F034 message which contains DayOfWeek, Hour, Minute, and Second.

There is no direct ESP time stamp in telnet yet (other than the Uptime info and the 00F034 time stamp), but a decent time stamp is on my todo-list.

But indeed it may be much easier to use HA to log any changes, let me make a EKHBRD firmware image so all relevant information is made available in HA. Not sure if I can manage that today.

from p1p2mqtt.

Don't worry. I'll log the telnet sesión and try to match times. And of course I can repeat that any time.

Regards

from p1p2mqtt.

Hello everybody.

I'm attaching 3 files. The txt just explains what I did and the results I can see through ModBus. I tried to get the best timing I could.

The "Enable Heating" telnet session is just that, the standard telnet output and the results of enabling heating in HA (through ModBus interface and RTD-W).

The "Heating+Thermostat" includes a few actions. In my installation, the remote thermostat (a Tuya WiFi thermostat) activates the external pump when On and deactivates it when Off. Besides, it is connected to the external Thermostat connector of the machine (I don't remember if it's connected directly to the motherboard or to the RTD-W, sorry).
I turned on the thermostat, and because Heating was already enabled (previous file), STart/Defrost mode was activated first and then compressor turned on too. I recorded the time when Leaving Water Temp got to 45º. Then I stopped heating. Detected changes and times are recorded too. Then I changed the heating Temp and recorded changes.

Finally I turned On and Off DHW.

If there is anything else I can test or need some more data (e.g. from MQTT or HA) or explanations, just tell me.

Thanks and regards.
Angel

Modbus RTD-W Actions.txt
enable_heating.zip
heating+thermostat.zip

Edit. The 13:49:54 line in the txt file should be "Changed DHW to Off", not to On

from p1p2mqtt.

Hi @aluisperezh , many thanks, very useful information, I'll process this later.

from p1p2mqtt.

Hi folks, I've just got a wonderful P1P2 interface from Arnold.
I've got a Daikin EDH016BB6V3 which is the same protocol as EKH (@bartv system)
Very grateful for the work done to get some decoding going.

On my system there are a few things that aren't quite right yet
*) Defrost Operation
*) Compressor active
*) Circ pump active

Things that have not yet been decoded I can think of:
*) Backup Heater Stage 1 active
*) Backup Heater Stage 2 active
*) DHW booster heater active

If only I knew where to start, I'd love to help identify these. Is there a pointer to how I can start to experiment and look at the decodes ?

from p1p2mqtt.

I've now digested the protocol info (thanks Arnold) and managed to start looking at the data.
Found a couple of bits that flick in the 40010 message when I call for heat (I suspect these are compressor and circulation pump, but they both happen at the same time)

400010 10 0B 01 0023000700010000000000 F8 08 00 1F 01 78 8E		heating off
400010 10 0B 01 0023000700010000000000 0E 09 00 1F 01 78 E0		heating off
400010 **20** 0B **21** 0023000700010000000000 EE 07 00 1F 01 78 42		heating on

Modified code accordingly to get them publishing via MQTT and will watch to see if they are compressor and pump.

from p1p2mqtt.

I've now digested the protocol info (thanks Arnold) and managed to start looking at the data. Found a couple of bits that flick in the 40010 message when I call for heat (I suspect these are compressor and circulation pump, but they both happen at the same time)

400010 10 0B 01 0023000700010000000000 F8 08 00 1F 01 78 8E		heating off
400010 10 0B 01 0023000700010000000000 0E 09 00 1F 01 78 E0		heating off
400010 **20** 0B **21** 0023000700010000000000 EE 07 00 1F 01 78 42		heating on

Modified code accordingly to get them publishing via MQTT and will watch to see if they are compressor and pump.

Maybe you can compare with the captured data I sent a couple messages above. I have both the P1/P2 interface and a ModBus interface, and with this one I can see which device is turned on. But I'm not sure if I have an internal circulation pump. For sure I have an external one, which is turned on by my thermostat, but I can't see anything about an internal pump in the ModBus interface. Perhaps it is in every EKH?

Regards.

from p1p2mqtt.

Thanks @aluisperezh that's not a bad idea. You have a slightly different system (EKHBRD) than mine (which is the same protocol as @bartv system). But it may be useful.

Seems my guess above was not correct regarding Compressor and Circ pump (my monobloc has a built in circulation pump).

By chance, it is now heating the DHW tank, with both compressor and pump running, but no room heating.

400010 now looks like this:

400010 10 0B 81 0123000700000000000000EE  07 00 1F 01 78 F9		hw, pump + comp

As you can see, byte 0 goes back to 10 (bit 5), and byte 3 goes to 81 (bit 5). In other words the bits that I thought were compressor and pump are not, and seem related to room heating only. Bit 7 of byte 3 is already correctly identified in the code as Valve_DHW_Tank and works correctly. Bit 5 of byte 3 was previously identified as Valve_Zone_Main, so I've reverted to that.

You would not think it would be this hard to identify 2 bit flips for the compressor and pump.

I'll keep looking.

from p1p2mqtt.

For my system, I believe I've now found the right bits for pump, comp and room heat request (first 2 bytes of 400011 message).

400011 07 08		= room heat requested, pump on
400011 07 09		= room heat requested, pump + comp on
400011 03 00		= NO room heat requested, pump off + comp off
400011 03 01		= NO room heat, comp on (happens just as thermostat switches off)

I'll figure out how to get a patch submitted to Arnold to add this to EKH decodes.

from p1p2mqtt.

I've created a pull request with the the known decodes for EKH/BB6 so far (includes @bartv work), uses a new .h for these machines and #define to select the heatpump variant (matches existing codebase). I'll add more decodes to this as I find them.

So far I've found (in addition to what was already known above)

Compressor Run
Pump Run
Backup Heater Stage1
Backup Heater Stage2
Defrost mode active
DHW Booster active
Heatpump On

from p1p2mqtt.

Hi all and thanks for the awesome work you've done!
Any intention to merge this to support EKH? or is there any workaround to use it?
Thanks!

from p1p2mqtt.