feat(protocol): support atlantic odyssee heatpumps

[tspopp]

This PR adds support for the protocol observed within an Calypso Odyssee device #68.

Help

⚠️ This PR needs help by the community, as I don't have a machine with the new protocol ⚠️

Missing Features / Open Tasks:

• Checksum Calculation
• HMI Message
  • time/date
  • target temperature
  • operation types (timer/always-on) NEW: off-peak hours
  • operation modes (boost, absence, eco...)
  • air-duct config (int/int..)
  • anti-legionella setting
  • enable emergency mode
  • disable heat-element
  • enable pv-input
  • timer window a/b
  • test modes
  • fan exhaust config (INT/EXT)
  • error request id / error number
• Main Message
  • hot water temp
  • NEW: upper hot water temp
  • NEW: lower hot water temp
  • input air temp
  • lower evaporator temp
  • upper evaporator temp
  • compressor outlet temp
  • states: heatpump, heatelement, ext, fan, defrost, pv-input, solar-input...
  • fan pwm
• Energy Message
  • total heatpump hours
  • total hours
  • total hours heat element
  • power heatpump
  • power heatelement
  • water production
  • total energy
  • diagnosis temperature values (min/max observed)
• Error Message
  • errorCode
  • requestId
  • optional: error message content
• Extra Message 217
  • power total
  • NEW: grid voltage
• Compatibility to legacy and next protocol
• MITM
  • Clarify origin of new message 217
  • Clarify frequences of emitted messages
  • Replay message 217 in correct frequency
  • Test Passthrough
  • Test Error Passthrough
  • Test Override Values
• MQTT Discovery depending on protocol version

How to help?

This branch contains a modified version of AquaMQTT which is meant to be installed in LISTENER mode. It is currently able to identify hmi, main, energy and extra messages from the new protocol #68 . These are provided to mqtt on the three topics:

aquamqtt/hmi/debug
aquamqtt/main/debug
aquamqtt/energy/debug
aquamqtt/extra/debug
aquamqtt/error/debug

The new protocol findings are documented within PROTOCOL_ODYSSEE.md

Tracing

Using the debug python script https://github.com/tspopp/AquaMQTT/blob/main/tools/debug.py you are able to record changing messages over time and identify which location holds what kind of attribute.

Create the python environment

python3 -m venv venv
source venv/bin/activate
pip install paho-mqtt

Run the python script

source venv/bin/activate
python3 debug.py

How to help here?

• start a recording of the serial messages
• change a single (previously unidentified) value at the hmi, e.g. water target temperature from 50 to 52
• stop the recording of the serial message
• attach the traces together with a description ("changed water target temperature from 50 to 52 and back")

[FSlunkk]

I completed some data on the protocol table.
However, I can't find the matches for the max and min values.

194 29 54 2 0 33 0 0 0 0 0 0 0 0 0 0 0 0 43 50 39 7 0 0 0 0 65 66 0 0 50
67 25 65 0 1 16 0 0 0 0 196 0 0 0 182 46 0 0 0 0 0 0 0 0 0 0 21
217 31 0 0 233 0 1 0 0 0 242 222 88 0 14 1 183 0 0 1 0 0 2 0 0 0 0 0 0 0 0 0 56
193 29 19 0 14 0 12 0 11 0 13 0 0 0 36 0 14 0 0 0 0 0 0 2 0 0 0 0 82 66 50

I think that 217 is also main "233" seems to be the voltage and the "1" after the power in Watt. I will confirm this soon.

[tspopp]

I've added the latest findings based on the document in your branch. Let me know if it works :)

[FSlunkk]

This is what i found for the byte 2 :

off-peak hours
Boost : 10 with byte n°14 duration in days
Eco off : 2
Eco on : 1
Auto : 0
Absence : 6 with byte n°13 duration in days

Continuous
Boost : 72 with byte n°14 duration in days
Eco off : 66
Eco on : 65
Auto : 64
Absence : 68 with byte n°13 duration in days

Timer
Boost : 24 with byte n°14 duration in days
Eco off : 18
Eco on : 17
Auto : 16
Absence : 20 with byte n°13 duration in days

When i actived the super secret menu :
194 29 54 2 0 33 0 0 0 0 0 0 0 0 0 0 0 0 43 50 15 18 0 0 0 0 65 66 15 46 46
74 68 46 24 54 0 75 0 23 0 24 0 35 0 0 0 54 0 55 0 65 3 0 0 0 0 0 0 0 0 81 38 0 0 152 0 0 0 123 12 0 0 47 13 0 0 152 26 0 0 46 1 0 0 221 46 58 12 1 24 0 0 0 0 0 0 0 0 43 128
67 25 65 0 6 16 0 0 0 0 196 0 0 0 187 46 0 0 0 0 0 0 0 0 0 0 31
217 31 0 0 234 0 2 0 127 1 237 235 88 0 14 1 194 0 0 1 0 0 2 0 0 0 0 0 0 0 0 0 25
193 29 53 0 37 0 18 0 18 0 23 0 0 0 53 0 46 0 0 0 0 0 0 2 0 0 0 0 82 66 19

And i disconnected the HMI, the 217 line is still here.

PS : I will test the mod tomorrow.

[FSlunkk]

Your mod works in listenner mode.

I found this :

193 :

Byte 18 : Fan speed : 50 low / 100 high

217 :

217 31 209 0 232 0 230 1 210 0 77 241 88 0 14 1 208 0 0 1 0 0 2 0 0 0 0 0 0 0 0 0 43
Byte 3 : tension in Volt 230 Volts
Bytes 5 et 6 : power en watts : 230 (Byte5) + 1 (byte6) *256 = 486 watts

194 :

194 29 54 2 0 33 0 0 0 0 0 0 0 0 0 0 0 0 44 50 52 16 0 0 0 0 65 66 0 0 49
Byte 4 : Anti-Legionella Mode / AirDuct Mode
Off and Int/Int : 0
On and Int/Int : 1
Off and Int/Ext : 16
On and Int/Ext : 17
Off and Ext/ext : 32
On and Ext/Ext : 33

Byte 5 :
Emergency-Mode : Off : 0 / On : 1

Byte 17 :
Day and month like your protocol
Byte 18
Year like yout protocol
Byte 20
Minutes
Byte 21
Hours

[tspopp]

Great news. Just incorporate your findings in the document and I will take care of adding them to the implementation. According to your finding there are many similarities to the NEXT protocol 👍

Regarding the super secret menu / error messages, I need you to go back to AquaDebug once and dump a whole series of messages (.csv) while opening the menu. I need to determine how the HMI is actually requesting errors. Maybe you can also share the amount of errors you have and create a photo of one of the errors shown in the super secret menu.

[FSlunkk]

super secret menu.csv
There is the whole serie of message. Is this fine for you?

[FSlunkk]

I have 30 error messages.

[tspopp]

These dumps are perfect 👍 I will add error message handling soon most likely tomorrow evening.

Do you have a logic analyzer? To replicate the serial behavior in MITM mode we should use the same timing for the messages. And since there is a new message, I am not sure if the current behavior is still correct. If you don't have one, I might add some code which measures the frequency, but if you have a logic analyzer it would be probably easier...

[FSlunkk]

Sorry, i don't have a logic analyser.

[tspopp]

No worries, we will get there 👍

[tspopp]

byte 2 :

off-peak hours
Boost : 10 with byte n°14 duration in days
Eco off : 2
Eco on : 1
Auto : 0
Absence : 6 with byte n°13 duration in days

Are you sure with the values for Boost and Absence? I'd expected something else 🤔

Byte 4 : Anti-Legionella Mode

Is there an option to set the number of runs of the anti-legionella mode per month or do you just have switch on/off?

217 :

217 31 209 0 232 0 230 1 210 0 77 241 88 0 14 1 208 0 0 1 0 0 2 0 0 0 0 0 0 0 0 0 43
Byte 3 : tension in Volt 230 Volts

You sure that this is really the voltage of the grid? We never had such thing before, it could be something else?

off-peak hours

What is Off-Peak Hours, is that a mode on the same level to Always-On/Timer. Can you share a photo?

[FSlunkk]

Yes, i'm sure for Boost and Absence.

For the anti-legionella mode, it's just off or 1 per month.

I'm pretty sure it's the voltage. The readings I took matched.

And Off peak hours is as the same level.

[tspopp]

Ok, intresting that there are so many differences between these heatpumps. How old is that machine. Is it from 2024?

Actually I implemented and added most of the items from your last comments. Hope it works so far 👍

[FSlunkk]

My machine is from 2015.

[tspopp]

🤯

[FSlunkk]

It's old but it could be useful to other people who want to automate their old home.

[tspopp]

Yeah, absolutely. I just thought this is next-gen. Instead this is last-gen, but you are right. Do these old heatpumps have the option to use cozytouch?

Regarding power consumption: Previous heatpumps had "totalPower" (heatpump and heatelement combined) and "powerHeatpump" and "powerHeatelement". Currently it is not clear if there is "totalPower" or "powerHeatpump" in Byte 5/6 of 217. You may want to run your machine on BOOST to identify it properly.

Latest version should have all the things implemented you've provided, except power and grid voltage. Please test :)

[FSlunkk]

I loaded the last version. It's strange because some data is missing, initially I only had water temp upper, then water temp, then compressor outlet temp.

[FSlunkk]

And now, i have this. Not all data is updated at the same time.

[tspopp]

Ah, this looks very well 👍 Actually it is expected behavior: Updates to the MQTT broker are only send in case a value changes. Additionally there is a fixed time value set by Configuration.h which causes full update of all attributes:

/**
 * Change the time interval where all known attributes are re-published to the MQTT broker.
 */
constexpr uint32_t MQTT_FULL_UPDATE_MS = 1000 * 60 * 30;

If you want all attributes to be updated every minute, you can set this for exampel to 1000 * 60.

Since backends like homeassistant cache the last value, AquaMQTT does not need to rebroadcast values which haven't changed.

Moreover, temperature values are filtered using kalman, so we remove the temperature sensor noise to reduce the amount of updates even more.

[FSlunkk]

Ok, good! I test boost tomorrow.

[FSlunkk]

I tested Boost, Byte 5/6 of 217 is totalpower.

[tspopp]

I added some code to determine the timing of the frames. I have not tested this on my heatpump, yet. But in theory, it should provide you frame timings e.g. to aquamqtt/stats/timing/194-193 In this case, time it took after we received 194 and waited for message 193 in milliseconds. There should be multiple message timings such as 194-193, 193-217 etc.

If this works, you may want to open the super secret menu once (so we also have the timing of the error message as well) and post a screenshot of MQTT explorer will all the timing values visible.

I think I can deduce the message frequency from this information, needed by the MITM mode. Other possibility is a logic analyzer 🤷. But let's try this first, maybe we can get it work without that.