Thermor Aeromax Access (or Atlantic Egéo)

[emagnier]

I have a Thermor Aeromax Access water heater (equivalent to an Atlantic Egéo), which seems to be a more basic/low-end model from the Atlantic group.

I guess this model is not supported by default. But do you think it would be possible to connect a PCB v2 to this board, just in “listening mode”?

I don’t really have knowledge in electronics, so I’m not sure if it is safe or even doable. However, I am a software developer, so I could try to learn how to do some reverse engineering on this water heater.

FYI, I can connect my water heater via the Overkiz cloud API, but this API is very slow and unstable (I dream of not having to use it!!).

[tspopp]

Hey, sorry for the late answer. Yes, of course. It is very likely that they use the same communication standard (one wire usart) for this HMI, too. If they use an entirely different protocol, AquaMQTT will not be able to parse messages, but there is AquaDebug in this repo which is a good start for inspecting / debugging the protocol.

If you want to start without the AquaMQTT board, you might just get a cheap logic analyzer or any Arduino / ESP32 capable of reading from the 5V serial connection and see if there are similarities to the existing protocols. If you provide a dump, I can also look into it.

Maybe related to this: #84, so I would suggest trying to inspect the protocol with an analyzer

[Cyril035]

Hi
I've that Thermor Aeromax Access too, and bought the aquamqtt v2 board
How do I plug the aquamqtt, do I need a new wire to work on MITM ?

[vlaforet]

Hi,

I have a De Dietrich CESL 65. The control board is exactly the same as the one you have in your Thermor Aeromax Access. I guess the protocol is the same.

However, the protocol version is unknown when I connect an AquatMQTT v2 board to it.

I will try to look into it soon when I get more time. Hopefully I can implement this protocol into AquaMQTT. In the meantime, here is the dump from AquaDebug if anyone with a similar device wants to work on it before ordering a board.

aquadbg_debug_dec.csv
aquadbg_debug_hex.csv

[emagnier]

Hi @vlaforet,

Thanks a lot for sharing those dumps! I bought the AquaMQTT v2 board but I haven't taken the time to wire it up to my heat pump yet. BTW, I'd be really curious to see some photos of how you connected the board to your De Dietrich CESL 65, that would help me a lot when I get around to mine!

I did a quick analysis of your 2 .CSV files with Claude Opus, and I have an early confirmation that this heat pump is not using any of the 3 protocols currently supported by AquaMQTT (LEGACY, NEXT, ODYSSEE). It looks like a different protocol that isn't handled by the platform yet.

A few observations from the dump (with the help of Claude):

• ~5100 frames captured, all exactly 9 bytes long, with a very stable structure: B9 D6 [XX] 64 [YY] D5 38 07 86
• Only 5 unique frame variants in the whole capture — only 2 bytes ever change (positions 2 and 4)
• This is very different from the existing protocols, which use longer frames (25–68 bytes) with an ID + LEN + PAYLOAD + CRC/XOR structure

Claude also pointed out that the dump probably captured a stationary state (HMI at rest, no user interaction), which would explain why so little varies. To actually decode the protocol, it would help to re-capture while doing specific actions, for example:

1. Change the target temperature (e.g. 55°C → 60°C) during the capture
2. Trigger a boost or switch mode (ECO / AUTO / MANUAL)
3. Capture during a compressor ON cycle vs OFF
4. Enable absence mode

If anyone has some free time to keep digging into this, that would be great. Otherwise, I'll try to find some time in the coming weeks to finally wire up my AquaMQTT v2 board and play with it myself.