ESPAltherma
ESPAltherma copied to clipboard
raomin
Unable to read anything from older Daikin Altherma EKHBX008AA9T1
Hi, I have been testing your work against my older Daikin Altherma. And it does not work. I fully understand that you have not tested this, and that I am a bit on my own here. But nevertheless...
I have come this far:
- I get a NACK response {0x15, 0xEA} if I send something the unit does not accept.
- Attempt to read any register (0-255) using your msg format {0x03, 0x40, regNo, CS} gives the above NACK response. I have tried all 256 values.
- I have looked at serial port signals using an oscilloscope and they seem fine.
- I have verified that the first byte of the message is indeed the message length. If I send fewer bytes that the length byte indicates, I get no response.
- I have tried to remove the checksum (and set length to 0x02) and I still get the NACK response.
So it is clear that the serial communication by itself works. And it seems that my unit use a different but similar message protocol than what you have implemented.
My questions then are:
- what approach did you use in your initial work to reverse engineer the message protocol
- do you (or someone you know about) sit on any information that would enable me to try to read data from my unit.
Any info would be appreciated. And of course, I would be willing to contribute all my findings to your project.
Thanks and kind regards Jon
Hello @Jonkrist Sorry for the late reply.
Until now, all the ESPAltherma users reported a full compatibility with their Altherma/ROTEX with X10A port. But it seems that some (old?) Althermas do not implement the same protocol as all others and reject (0x15, 0xAC) every registry queries...
The approach I would suggest (which is the approach I initially used) is to use DChecker (a Daikin software interfacing with X10A) and see first if it gets data from your heat pump and, if so, using which protocol.
Seeing that the NACK reply is consistent with the protocol used in other Althermas, I would assume that the difference is minimal. Hope you can figure it out!
Hi,
Thanks for replying.
I Will see if I can find a place a link to DChecker and give it a try. If you have a download link that would be highly appreciated. Right now I am testing Arnold Niessen’s P1P2 approach.
Thanks again. Jon
søn. 16. jan. 2022 kl. 22:47 skrev Raomin @.***>:
Hello @Jonkrist https://github.com/Jonkrist Sorry for the late reply.
Until now, all the ESPAltherma users reported a full compatibility with their Altherma/ROTEX with X10A port. But it seems that some (old?) Althermas do not implement the same protocol as all others and reject (0x15, 0xAC) every registry queries...
The approach I would suggest (which is the approach I initially used) is to use DChecker (a Daikin software interfacing with X10A) and see first if it gets data from your heat pump and, if so, using which protocol.
Seeing that the NACK reply is consistent with the protocol used in other Althermas, I would assume that the difference is minimal. Hope you can figure it out!
— Reply to this email directly, view it on GitHub https://github.com/raomin/ESPAltherma/issues/74#issuecomment-1013958711, or unsubscribe https://github.com/notifications/unsubscribe-auth/AKSVNHSUCWNCHS2VRV2MXWLUWM4IZANCNFSM5LD2YH3Q . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you were mentioned.Message ID: @.***>
You'll find it here: https://www.thermalsupplyinc.com/daikin-service-checkers/
Thanksa lot - found it 😊
Jon
Fra: Raomin @.> Sendt: 17. januar 2022 22:08 Til: raomin/ESPAltherma @.> Kopi: Jonkrist @.>; Mention @.> Emne: Re: [raomin/ESPAltherma] Unable to read anything from older Daikin Altherma EKHBX008AA9T1 (Issue #74)
You'll find it here: https://www.thermalsupplyinc.com/daikin-service-checkers/
— Reply to this email directly, view it on GitHub https://github.com/raomin/ESPAltherma/issues/74#issuecomment-1014885894 , or unsubscribe https://github.com/notifications/unsubscribe-auth/AKSVNHS4PV2KPT2I2WWG673UWSAJHANCNFSM5LD2YH3Q . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub . You are receiving this because you were mentioned.Message ID: @.***>
Hej, same issue here, getting this back, which I guess confirms the connection is fine. I was so excited when I found this project - but had some doubts as the unit is also quite old, also an EKHB.
espaltherma/log Querying register 0x61...
espaltherma/log ERR: Time out on register 0x61! got 2/10 bytes
espaltherma/log 0x15 0xea
...
@Jonkrist Any luck yet with the protocol? Happy to do some testing here too ...
Best,
-T
Quick update, I am very sure now this is the same protocol as here in #46. To confirm I modified a few things according to the guidance from @raomin in this post.
So pretty much changed
char prep[] = {0x03, 0x40, regID, 0x00} to char prep[] = {0x02, regID, 0x00} and then only adjusted the command lengths.
And then in default.h did
{0x54,2,103,2,1,"test"}
And that gives me something more useful. Now I am pretty much stuck as I don't know how to adjust the converters/labels ... :) But this seems to confirm it uses the same protocol from issue 46 ...
espaltherma/log Querying register 0x54...
espaltherma/log ERR: Time out on register 0x54! got 18/22 bytes
espaltherma/log 0x54 0x20 0x16 0x50 0x15 0x78 0x17 0xc4 0x14 0xdc 0x15 0x01 0x00 0x1c 0x00 0x00 0x00 0x9b
or
espaltherma/log 0x54 0x20 0x16 0x50 0x15 0x60 0x17 0xc4 0x14 0xdc 0x15 0x01 0x00 0x1c 0x00 0x00 0x00 0xb3
Hey! That's good progress indeed...!
From #46 it appears that only 4 registries are available, U T P S, ie 0x55 0x54 0x50 0x53
They are indeed queried with {0x02, regID, CRC}
From what I could find in D-Checker, it's what Daikin calls 'S protocol".
Looking inside D-Checker file under \Storage\DataModule\Conv\S there is a default.txt file, it contains precious info on the S protocol and some info on values:
U,0,1,201,%s,,1,1,0,Operation Mode,-1,-1,-1,-1,-1,-1,-1,1,
T,13,1,151,%.0f,A,1,1,0,R/C Setpoint,-1,-1,1,-1,-1,-1,1,0,
T,12,1,312,%.2f,A,1,1,0,Delta-Tr(deg),-1,-1,1,-1,-1,-1,-1,0,
U,1,1,204,%s,,1,1,0,Error Code,-1,-1,-1,-1,-1,-1,-1,0,
U,2,1,204,%s,,1,1,0,Thermo Off Error,-1,-1,-1,-1,-1,-1,-1,0,
U,3,1,204,%s,,1,1,0,Warning Code,-1,-1,-1,-1,-1,-1,-1,0,
U,4,1,204,%s,,1,1,0,Caution Code,-1,-1,-1,-1,-1,-1,-1,0,
T,0,2,103,%.2f,A,1,1,0,Indoor Suction Air Temp.,0,-1,1,-1,-1,-1,1,0,
T,2,2,103,%.2f,A,1,1,0,Indoor Heat Exchanger Temp.,1,-1,1,-1,-1,-1,1,0,
T,4,2,103,%.2f,A,1,1,0,Outdoor air temp.,2,-1,1,-1,-1,-1,1,2,
T,6,2,103,%.2f,A,1,1,0,Outdoor heat exchanger temp.,3,-1,1,-1,-1,-1,1,0,
T,8,2,109,%.2f,A,1,1,0,Discharge pipe temp.,4,-1,2,-1,-1,-1,1,5,
T,10,2,103,%.2f,A,1,1,0,Fin Temp.,-1,-1,1,-1,-1,-1,1,0,
P,0,2,103,%.2f,A,1,1,0,HP Sensor,-1,-1,1,-1,-1,-1,2,3,
P,2,2,103,%.2f,A,1,1,0,LP Sensor,5,-1,1,-1,-1,-1,2,4,
S,4,1,200,%.0f,A,1,1,0,INV Comp. Frequency(Hz),6,-1,2,-1,-1,-1,-1,7,
S,6,1,200,%s,D,1,1,0,52C Output,0,-1,-1,-1,-1,-1,-1,0,
S,0,2,152,%.0f,A,1,1,0,EV (pls),7,-1,3,-1,-1,-1,-1,0,
S,2,1,164,%.0f,A,1,1,0,Outdoor Fan (Upper)(rps),-1,-1,3,-1,-1,-1,-1,0,
S,3,1,164,%.0f,A,1,1,0,Outdoor Fan (Lower)(rps),-1,-1,3,-1,-1,-1,-1,0,
S,8,1,200,%s,D,1,1,0,20R (SV) Output,1,-1,-1,-1,-1,-1,-1,0,
S,7,1,200,%s,D,1,1,0,20S (4-way) Output,2,-1,-1,-1,-1,-1,-1,0,
S,10,1,200,%s,D,1,1,0,Crankcase Heater,3,-1,-1,-1,-1,-1,-1,0,
S,5,1,200,%s,D,1,1,0,Comp. Preheat,-1,-1,-1,-1,-1,-1,-1,0,
S,11,1,200,%s,D,1,1,0,Ener-Cut Output,-1,-1,-1,-1,-1,-1,-1,0
My understanding of this file:
[RegID],[Offset/Position in the response],[data size], [convID],[type for display]...[label]...
So you should take default.h and adjust like so with the values in the file:
[RegID],[Offset/Position in the response],[convID],[data size],-1, [label]
For the converters, the ones in ESPAltherma should match.
Looking back at #46, it looks that the HP always return 16 bytes, whilw ESPAltherma (protocol @) has a variable length given in the response. So you should change this too.
Something like: comm.h:32
while ((len < 16 + 2) && (millis() < (start + SER_TIMEOUT)))
this should work.
Have fun!
Almost there (I hope). Implemented as per your kind guidance. 0x50 gives no response - which actually correlates with the screenshot from #46 - no "HP Sensor" & "LP Sensor" in the screenshot of the Daikin tool either over there. So commented these 2 lines out.
Got no actual errors but also no values so looked into the code and in converters.h changed below to account for the changed offset of the response.
// readRegistryValues(data[1], data);
readRegistryValues(data[0], data);
...
// input += labels[i]->offset + 3;
input += labels[i]->offset + 1;
And got (limited) success! (also added some debug code to see the raw values).
Converter 164 & 312 missing. The temperatures make little sense, unit was not running. The 20 ... 22 °C could be some indoor temp, but outside temp. was more like 5 °C. Note that #46 screenshot also shows some weirdness, discharge pipe temperature @-64 °C etc. @DDoykov.
espaltherma/log Querying register 0x55...
espaltherma/log 0x55 0x01 0x00 0x00 0x00 0x00 0x1e 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x8b
espaltherma/log Querying register 0x54...
espaltherma/log 0x54 0xf0 0x15 0xdc 0x14 0x4c 0x16 0xdc 0x14 0x14 0x2a 0x01 0x00 0x1d 0x00 0x00 0x00 0x08
espaltherma/log Querying register 0x53...
espaltherma/log 0x53 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0xac
espaltherma/ATTR {"Operation Mode":"Heating",
"Error Code":" 0",
"Thermo Off Error":" 0",
"Warning Code":" 0",
"Caution Code":" 0",
"R/C Setpoint":0,
"Delta-Tr(deg)":"Conv 312 not avail.",
"Indoor Suction Air Temp.":21.9375,
"Indoor Heat Exchanger Temp.":20.8594,
"Outdoor air temp.":22.2969,
"Outdoor heat exchanger temp.":20.8594,
"Discharge pipe temp.":84.1562,
"Fin Temp.":0.00390625,
"INV Comp. Frequency(Hz)":"OFF",
"52C Output":"OFF",
"EV (pls)":0,
"Outdoor Fan (Upper)(rps)":"Conv 164 not avail.",
"Outdoor Fan (Lower)(rps)":"Conv 164 not avail.",
"20R (SV) Output":"OFF",
"20S (4-way) Output":"OFF",
"Crankcase Heater":"OFF",
"Comp. Preheat":"OFF",
"Ener-Cut Output":"OFF"}
I would say this was fun in any case so far, will see what gets reported once it is running.
Hi,
Great work !
I had laud this avsides for a while and have tried the S1S2 interface approach. Ref. https://github.com/Arnold-n/P1P2Serial
I have got this working somewhat - I can read some temperatures and operational status.
But your feedback gives some hope, and I will give it a try as soon as I get a chance.
I will post my S1S2 work as soon as I have wrapped it up.
Thanks for posting your findings.
Best regards Jon
ons. 16. feb. 2022 kl. 00:15 skrev Kobbe1 @.***>:
Almost there (I hope). Implemented as per your kind guidance. 0x50 gives no response - which actually correlates with the screenshot from #46 https://github.com/raomin/ESPAltherma/issues/46 (no "HP Sensor" & "LP Sensor" in the screenshot of the Daikin tool either over there. So commented these 2 lines out.
Got no actual errors but also no values so looked into the code and in converters.h changed below to account for the changed offset of the response.
// readRegistryValues(data[1], data);
readRegistryValues(data[0], data);
...
// input += labels[i]->offset + 3;
input += labels[i]->offset + 1;
And got (limited) success! (also added some debug code to see the raw values).
Converter 164 & 312 missing. The temperatures make little sense, unit was not running. The 20 ... 22 °C could be some indoor temp, but outside temp. was more like 5 °C. Note that #46 https://github.com/raomin/ESPAltherma/issues/46 screenshot also shows some weirdness, discharge pipe temperature @-64 °C etc. @DDoykov https://github.com/DDoykov.
espaltherma/log Querying register 0x55...
espaltherma/log 0x55 0x01 0x00 0x00 0x00 0x00 0x1e 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x8b
espaltherma/log Querying register 0x54...
espaltherma/log 0x54 0xf0 0x15 0xdc 0x14 0x4c 0x16 0xdc 0x14 0x14 0x2a 0x01 0x00 0x1d 0x00 0x00 0x00 0x08
espaltherma/log Querying register 0x53...
espaltherma/log 0x53 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0xac
espaltherma/ATTR {"Operation Mode":"Heating",
"Error Code":" 0",
"Thermo Off Error":" 0",
"Warning Code":" 0",
"Caution Code":" 0",
"R/C Setpoint":0,
"Delta-Tr(deg)":"Conv 312 not avail.",
"Indoor Suction Air Temp.":21.9375,
"Indoor Heat Exchanger Temp.":20.8594,
"Outdoor air temp.":22.2969,
"Outdoor heat exchanger temp.":20.8594,
"Discharge pipe temp.":84.1562,
"Fin Temp.":0.00390625,
"INV Comp. Frequency(Hz)":"OFF",
"52C Output":"OFF",
"EV (pls)":0,
"Outdoor Fan (Upper)(rps)":"Conv 164 not avail.",
"Outdoor Fan (Lower)(rps)":"Conv 164 not avail.",
"20R (SV) Output":"OFF",
"20S (4-way) Output":"OFF",
"Crankcase Heater":"OFF",
"Comp. Preheat":"OFF",
"Ener-Cut Output":"OFF"}
— Reply to this email directly, view it on GitHub https://github.com/raomin/ESPAltherma/issues/74#issuecomment-1040892730, or unsubscribe https://github.com/notifications/unsubscribe-auth/AKSVNHS27QSUPBI64X7UHXDU3LNBLANCNFSM5LD2YH3Q . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you were mentioned.Message ID: @.***>
Sure. Things work more or less. I had to manually assign the correct descriptions by comparing to the values displayed on the unit, and also changed some of the converters.
And the ones marked in yellow are not really doing anything (well the outdoor heatex temp does change more or less with inlet temp but I have not figured out what exactly this is). Refrigerant is also cooler than the others, but that is also the case for the unit display).
I had hoped to hear from @Jonkrist before I finalize, but I could not wait any longer, it was too exciting. I am pretty happy with the current setup (fan speed/Inverter speed would have been cool but I do not think this is in the data).
@Kobbe1 and @raomin Sorry - I have not had that much time to play with this lately. But finally got some spare time today. As I said earlier, I have successfully implemented the P1P2 adapter by Arnold and have managed to decode some data from it.
Looking at what I get from Dchecker, it is not very much that agree. I have a Altherma floor heating/hot water system, and I expect the the S protocol DEFAULT file is not set up for that. I will try to do some digging into these files to see if I get any further. One problem I have is that I only found D-Checker version 3.6.0.2 and the S protocol DEFAULT file has an .ldd extension and is not readable. Any suggestions?
Here is a screenshot of what I get together with what I get from the P1P2 adapter:
The only temperatures that match is "outdoor heat exchange temp" vs water temp (which is most probably the outgoing water temp to the floor loops,
I also see that the OnOff values to the right seems to change with compressor on/off.
My next step now is to have a look at @Kobbe1 's changes and see if I can get something meaningful from this data.
I will keep you posted, but this is not my highest priority just now. Sry about that.
Here is how I left it back then. Not all of them give useful data but getting most important temperatures and wether unit is on or off. Has been in operation since then without changes.
`{0x55,1,204,1,-1,"Error Code"}, {0x55,0,201,1,-1,"Operation Mode"},
{0x54,8,103,2,-1,"Storage Temp."},
{0x54,10,103,2,-1,"Fin Temp."},
{0x54,0,103,2,-1,"E03 Refrigerant Temp."},
{0x54,2,103,2,-1,"E04 Inlet Temp."},
{0x54,4,103,2,-1,"Outdoor air temp."},
{0x54,6,103,2,-1,"Outlet Temp."},
{0x54,13,151,1,-1,"R/C Setpoint"}, {0x54,12,312,1,-1,"Delta-Tr(deg)"},
{0x55,2,204,1,-1,"Thermo Off Error"}, {0x55,3,204,1,-1,"Warning Code"}, {0x55,4,204,1,-1,"Caution Code"},
//{0x50,0,103,2,-1,"HP Sensor"}, //{0x50,2,103,2,-1,"LP Sensor"},
{0x53,4,200,1,-1,"INV Comp. Frequency(Hz)"}, {0x53,6,200,1,-1,"52C Output"}, {0x53,0,152,2,-1,"EV (pls)"}, {0x53,2,164,1,-1,"Outdoor Fan (Upper)(rps)"}, {0x53,3,164,1,-1,"Outdoor Fan (Lower)(rps)"},
//{0x53,2,152,1,-1,"Outdoor Fan (Upper)(rps)"}, //{0x53,3,152,1,-1,"Outdoor Fan (Lower)(rps)"},
{0x53,8,200,1,-1,"20R (SV) Output"}, {0x53,7,200,1,-1,"20S (4-way) Output"}, {0x53,10,200,1,-1,"Crankcase Heater"}, {0x53,5,200,1,-1,"Comp. Preheat"}, {0x53,11,200,1,-1,"Ener-Cut Output"},
`
Hello,
i'm using a HPSU 508 BJ 2012. X10A has 8 ports. i'm connecting the NODEMCU v3 with the X10A but only 0x15 0xea is reported in the terminal.
i used the code from pitylee: #include "labeldef.h" // This file is a definition file for the ESPAtherma. // uncomment each value you want to query for your installation.
LabelDef PROGMEM labelDefs[] = { {0x75,0,1,201,-1,"Operation Mode"}, {0x54,13,1,151,-1,"R/C Setpoint"}, {0x54,12,1,312,-1,"Delta-Tr(deg)"}, {0x75,1,1,204,-1,"Error Code"}, {0x75,2,1,204,-1,"Thermo Off Error"}, {0x75,3,1,204,-1,"Warning Code"}, {0x75,4,1,204,-1,"Caution Code"}, {0x54,0,2,103,-1,"Indoor Suction Air Temp."}, {0x54,2,2,103,-1,"Indoor Heat Exchanger Temp."}, {0x54,4,2,103,-1,"Outdoor air temp."}, {0x54,6,2,103,-1,"Outdoor heat exchanger temp."}, {0x54,8,2,109,-1,"Discharge pipe temp."}, {0x54,10,2,103,-1,"Fin Temp."}, {0x50,0,2,103,-1,"HP Sensor"}, {0x50,2,2,103,-1,"LP Sensor"}, {0x53,4,1,200,-1,"INV Comp. Frequency(Hz)"}, {0x53,6,1,200,-1,"52C Output"}, {0x53,0,2,152,-1,"EV (pls)"}, {0x53,2,1,164,-1,"Outdoor Fan (Upper)(rps)"}, {0x53,3,1,164,-1,"Outdoor Fan (Lower)(rps)"}, {0x53,8,1,200,-1,"20R (SV) Output"}, {0x53,7,1,200,-1,"20S (4-way) Output"}, {0x53,10,1,200,-1,"Crankcase Heater"}, {0x53,5,1,200,-1,"Comp. Preheat"}, {0x53,11,1,200,-1,"Ener-Cut Output"}, };
is it possible to read the "grey" HPSU?
Hello,
i'm using a HPSU 508 BJ 2012. X10A has 8 ports. i'm connecting the NODEMCU v3 with the X10A but only 0x15 0xea is reported in the terminal.
i used the code from pitylee: #include "labeldef.h" // This file is a definition file for the ESPAtherma. // uncomment each value you want to query for your installation.
LabelDef PROGMEM labelDefs[] = { {0x75,0,1,201,-1,"Operation Mode"}, {0x54,13,1,151,-1,"R/C Setpoint"}, {0x54,12,1,312,-1,"Delta-Tr(deg)"}, {0x75,1,1,204,-1,"Error Code"}, {0x75,2,1,204,-1,"Thermo Off Error"}, {0x75,3,1,204,-1,"Warning Code"}, {0x75,4,1,204,-1,"Caution Code"}, {0x54,0,2,103,-1,"Indoor Suction Air Temp."}, {0x54,2,2,103,-1,"Indoor Heat Exchanger Temp."}, {0x54,4,2,103,-1,"Outdoor air temp."}, {0x54,6,2,103,-1,"Outdoor heat exchanger temp."}, {0x54,8,2,109,-1,"Discharge pipe temp."}, {0x54,10,2,103,-1,"Fin Temp."}, {0x50,0,2,103,-1,"HP Sensor"}, {0x50,2,2,103,-1,"LP Sensor"}, {0x53,4,1,200,-1,"INV Comp. Frequency(Hz)"}, {0x53,6,1,200,-1,"52C Output"}, {0x53,0,2,152,-1,"EV (pls)"}, {0x53,2,1,164,-1,"Outdoor Fan (Upper)(rps)"}, {0x53,3,1,164,-1,"Outdoor Fan (Lower)(rps)"}, {0x53,8,1,200,-1,"20R (SV) Output"}, {0x53,7,1,200,-1,"20S (4-way) Output"}, {0x53,10,1,200,-1,"Crankcase Heater"}, {0x53,5,1,200,-1,"Comp. Preheat"}, {0x53,11,1,200,-1,"Ener-Cut Output"}, };
is it possible to read the "grey" HPSU?
You have to make the converter and comm changes.
Also where is that definition from?
Here is how I left it back then. Not all of them give useful data but getting most important temperatures and wether unit is on or off. Has been in operation since then without changes.
`{0x55,1,204,1,-1,"Error Code"}, {0x55,0,201,1,-1,"Operation Mode"},
{0x54,8,103,2,-1,"Storage Temp."},
{0x54,10,103,2,-1,"Fin Temp."},
{0x54,0,103,2,-1,"E03 Refrigerant Temp."},
{0x54,2,103,2,-1,"E04 Inlet Temp."},
{0x54,4,103,2,-1,"Outdoor air temp."},
{0x54,6,103,2,-1,"Outlet Temp."},
{0x54,13,151,1,-1,"R/C Setpoint"}, {0x54,12,312,1,-1,"Delta-Tr(deg)"},
{0x55,2,204,1,-1,"Thermo Off Error"}, {0x55,3,204,1,-1,"Warning Code"}, {0x55,4,204,1,-1,"Caution Code"},
//{0x50,0,103,2,-1,"HP Sensor"}, //{0x50,2,103,2,-1,"LP Sensor"},
{0x53,4,200,1,-1,"INV Comp. Frequency(Hz)"}, {0x53,6,200,1,-1,"52C Output"}, {0x53,0,152,2,-1,"EV (pls)"}, {0x53,2,164,1,-1,"Outdoor Fan (Upper)(rps)"}, {0x53,3,164,1,-1,"Outdoor Fan (Lower)(rps)"},
//{0x53,2,152,1,-1,"Outdoor Fan (Upper)(rps)"}, //{0x53,3,152,1,-1,"Outdoor Fan (Lower)(rps)"},
{0x53,8,200,1,-1,"20R (SV) Output"}, {0x53,7,200,1,-1,"20S (4-way) Output"}, {0x53,10,200,1,-1,"Crankcase Heater"}, {0x53,5,200,1,-1,"Comp. Preheat"}, {0x53,11,200,1,-1,"Ener-Cut Output"},
`
For me, there is no error, but also only ssid is in the json that I receive in mqtt. :(
Hallo, Ich verwende eine HPSU 508 BJ 2012. X10A hat 8 Ports. Ich verbinde die NODEMCU v3 mit dem X10A, aber im Terminal wird nur 0x15 0xea gemeldet. Ich habe den Code von pitylee verwendet: #include "labeldef.h" // Diese Datei ist eine Definitionsdatei für den ESPAtherma. // Kommentieren Sie jeden Wert aus, den Sie für Ihre Installation abfragen möchten. LabelDef PROGMEM labelDefs[] = {{0x75,0,1,201,-1,"Operation Mode"}, {0x54,13,1,151,-1,"R/C Setpoint"}, {0x54,12,1,312,-1 ,"Delta-Tr(Grad)"}, {0x75,1,1,204,-1,"Fehlercode"}, {0x75,2,1,204,-1,"Thermo-Aus-Fehler"}, {0x75,3,1,204 ,-1,"Warncode"}, {0x75,4,1,204,-1,"Warncode"}, {0x54,0,2,103,-1,"Ansauglufttemperatur im Innenbereich."}, {0x54,2, 2,103,-1,"Innenwärmetauschertemperatur."}, {0x54,4,2,103,-1,"Außenlufttemperatur."}, {0x54,6,2,103,-1,"Außenwärmetauschertemperatur."} , {0x54,8,2,109,-1,"Druckrohrtemperatur."}, {0x54,10,2,103,-1,"Lamellentemperatur."}, {0x50,0,2,103,-1,"HP-Sensor" }, {0x50,2,2,103,-1,"LP Sensor"}, {0x53,4,1,200,-1,"INV Comp. Frequency(Hz)"}, {0x53,6,1,200,-1," 52C Ausgang"}, {0x53,0,2,152,-1,"EV (pls)"}, {0x53,2,1,164,-1,"Außenlüfter (oben)(rps)"}, {0x53,3,1,164,-1,"Außenlüfter (unten)( rps)"}, {0x53,8,1,200,-1,"20R (SV) Ausgang"}, {0x53,7,1,200,-1,"20S (4-Wege) Ausgang"}, {0x53,10, 1.200,-1,"Crankcase Heater"}, {0x53,5,1,200,-1,"Comp. Preheat"}, {0x53,11,1,200,-1,"Ener-Cut Output"}, }; ist es möglich, die "graue" HPSU zu lesen?
Sie müssen den Konverter und die Kommunikationsänderungen vornehmen.
Und woher kommt diese Definition?
Hello, sorry for my bad English,
what changes do I need to make for communication? Unfortunately, I'm not so good at programming.
Hello, sorry for my bad English,
what changes do I need to make for communication? Unfortunately, I'm not so good at programming.
Hello, sorry for my bad English,
what changes do I need to make for communication? Unfortunately, I'm not so good at programming.
Hi, I will share my experience as I have a very close HP (EKHBX008AA3V3) I had several issues at the same time and you need to check them also
- Wrong board selected in my platformio.ini and I needed to create a custom profile for my ESP32 board (AZ delivery)
[platformio]
default_envs = esp32_az_delivery
[env:esp32_az_delivery]
platform = espressif32
board = az-delivery-devkit-v4
framework = arduino
monitor_speed = 115200
upload_speed = 115200
; Uncomment this line to allow for remote upgrade. If name resolution does not work for you, replace with the IP of ESPAltherma
; upload_port = ESPAltherma.local
; Uncomment this line if you want to define the protocol. Autodetected otherwise.
; upload_protocol = espota
lib_deps =
PubSubClient
-
There were defects on the cable connection and need to change my dupont connectors
-
I used the wrong profile for my heat pump which is quite old (2009 I guess) Like some users, I'm using an Altherma HP with a 8-pins X10 connector so I made custom 8-pins Dupont connectors in order to avoid problems and avoid mistakes. Important : for such old HP, I need to stick on PROTOCOL_S_ROTEX or PROTOCOL_S (except 0x50 registers) HP profiles
#include "def/PROTOCOL_S.h"Now everything is fine and I'm receiving values from the HP. Looking good.
@nicolasvila Your post made me review this again, and I realized that I am still using my old code while it seems by now the S-protocol got merged into the code, must have missed that before. As you seem to have the same unit as mine - can you tell me what readings exactly you are getting? I mean what sensors you can read ... I might upgrade if there is anything in there that I missed back then in February :)
Yes @Kobbe1, S-protocol has been added in October by @agrenott. I'll close this one as the issue is solved.
@Kobbe1 Here is my current status (see added comments on how much I trust each): ` // 0x50 not supported by RDLQ014AA6V3
// 0x53 seems to be a collection of booleans
{0x53, 0, 200, 1, -1, "Circulation pump"}, // Nov 2022 -> OK, verified against control console
{0x53, 3, 200, 1, -1, "External heater?"}, // Nov 2022 -> OK
{0x53, 5, 200, 1, -1, "Priority to domestic water"}, // Nov 2022 -> OK
{0x53, 6, 200, 1, -1, "Burner inhibit from solaris"}, // Nov 2022 -> OK
// Testing stuff....
{0x54, 0, 153, 2, -1, "Refrig. Temp. liquid side(C)"}, // Nov 2022 -> OK, verified against control console E-03 / R13T
{0x54, 2, 153, 2, -1, "Inlet water temp.(C)"}, // Nov 2022 -> OK, verified against control console E-04 / R14T
{0x54, 4, 153, 2, -1, "Outlet Water Temp.(C)"}, // Nov 2022 -> OK, verified against control console / R12T
{0x54, 6, 153, 2, -1, "D(C)"}, // Nov 2022 -> Could be R11T?
{0x54, 8, 153, 2, -1, "DHW tank temp.(C)"}, // Nov 2022 -> OK, verified against control console
{0x54, 10, 103, 2, -1, "F(C)"}, // Nov 2022 -> Wrong! Seems to be one/two booleans?!
// Byte 12 seems to be a 1 byte value, evolving during day in continuous way
// 0x1b mid-day, 0x24 mid night -> some delta temp??
{0x54, 12, 101, 1, -1, "Delta-Tr(deg)"}, // Nov 2022 -> most probably the "Weather dependent set point"
{0x54, 13, 151, 1, -1, "R/C Setpoint(C)"},
{0x55, 0, 201, 1, -1, "Operation Mode"},
{0x55, 1, 204, 1, -1, "Error Code"},
{0x55, 2, 204, 1, -1, "Thermo Off Error"},
{0x55, 3, 204, 1, -1, "Warning Code"},
{0x55, 4, 204, 1, -1, "Caution Code"},
// TODO: seems to reply on 0x56 as well, but not used by dchecker...
{0x56, 0, 103, 2, -1, "????"},
`
The RxxT match this schema:
And the kind of graphs I get:
@nicolasvila Your post made me review this again, and I realized that I am still using my old code while it seems by now the S-protocol got merged into the code, must have missed that before. As you seem to have the same unit as mine - can you tell me what readings exactly you are getting? I mean what sensors you can read ... I might upgrade if there is anything in there that I missed back then in February :)
@Kobbe1, Here are below the kind of values I obtain from def/PROTOCOL_S.h
Quite similar as you display on your dashboard. I still have doubts on the real "labels" matching these values, as for example outdoor temp is way to high (currently we are around 10°C)
Thanks, very similar indeed. The standard labels do not apply for our model. You can easily manually match 4 temperatures by comparing with the unit display: outlet water temp + storage tank temp are on the normal display, and refrigerant and water inlet are accessible through the parameter menu under E03 & E04. Or see agrenott's post and edit the def file accordingly ...
Only 1 temperature not fully clear - @agrenott seems to think its the inlet to the backup heater, which could very well be as it is very close to the outlet temp. Way to verify would be to compare when the backup heater is on - but it is still way too warm for that here :)
Hi,
I have a question regarding my HP unit (EKHBX008AA3V3) which seems to accept PROTOCOL_S_ROTEX and PROTOCOL_S. (I believe parameters from PROTOCOL_S_ROTEX make more sense for my unit)
Whatever the file I'm using, I got values. For example I can retrieve temperature values using both definition files with a different mapping. Would it be possible (and make sense) to merge the 2 files? Here's below what I obtain for PROTOCOL_S :
and PROTOCOL_S_ROTEX:
Not sure it makes sense to merge them:
- PROTOCOL_S comes from Daikin diagnostic tool. I expect it might be better for older Daikin units (ie. before protocol I)
- PROTOCOL_S_ROTEX is a reverse engineering of the fields I'm doing with my (even older) Rotex unit (seems right when rotex was bought by Daikin)
BTW, your DHW (domestic hot water) temp is surprisingly high - my tank can't accept anything higher than 85C.
Yes, I understand. I'll stick with PROTOCOL_S_ROTEX then. For DHW, I guess this value is unreliable as my HP is not used for DHW :-) Back to the different protocols, that's surprising anyway to obtain the same values with different calls. What does mean the third field ? I obtain the same value with 103 or 153.
using PROTOCOL_S_ROTEX {0x54, 0, 153, 2, -1, "Refrig. Temp. liquid side(C)"}, {0x54, 2, 153, 2, -1, "Inlet water temp.(C)"}, {0x54, 4, 153, 2, -1, "Outlet Water Temp.(C)"}, {0x54, 6, 153, 2, -1, "D(C)"},
using PROTOCOL_S {0x54, 0, 103, 2, -1, "Indoor Suction Air Temp.(C)"}, {0x54, 2, 103, 2, -1, "Indoor Heat Exchanger Temp.(C)"}, {0x54, 4, 103, 2, -1, "Outdoor air temp.(C)"}, {0x54, 6, 103, 2, -1, "Outdoor heat exchanger temp.(C)"},
You can see the various converters: https://github.com/raomin/ESPAltherma/blob/main/include/converters.h#L84 103 vs. 153 is signed vs. unsigned values; so you'll get same results for raw values "< max / 2" (eg. 0-127 for 1 byte)