Looks like the HMI Controller is not getting any data. Maybe start with Listener Mode and see what happens. In this case the heat pump and original controller should work as expected. If it is also not working with Listener mode, then something is wrong with the connection or the board.

If the heat pump works with Listener mode, we can check MQTT attributes and see why MITM is not working properly.

Interestingly I have different version numbers, so I think a protocol dump would be also of interest. Bur first, try listener mode and we move forward step by step :)

So, the 'Listener' is active. And I'm receiving values on the HMI again.

In the MQTT debug topic, new data is coming in every second, changing continuously.

Ok, so in this case the board and the connectivity works as it should. Let's debug the software ;)

I guess by debug topic you mean you have set constexpr bool DEBUG_RAW_SERIAL_MESSAGES to true? In this case, you should have three debug topics in mqtt...aquamqtt/hmi/debug, aquamqtt/main/debug and aquamqtt/energy/debug. There is a python script which writes the messages of the debug topics into files. You might want to use that, so we can debug this issue better.

Can you post a screenshot from the MQTT traffic created using MQTT Explorer? I am curious how the stats look like. There should be MQTT topics msgHandled, msgUnhandled, msgCRCNOKanddroppedBytes`.

Or did you already went ahead and tried Troubleshooting using AquaDebug? And this log is actually output from that?

Hey @taloriko,

I had some free time in the train looking at your dumps. Obviously you already captured them using AquaDebug. Nice job!

The bad news is, that this is an overhauled protocol which differs from the one that is currently implemented. The good news is, that it's not impossible to be added. But you have to do the major part of analyzing the protocol, e.g. by changing settings in the HMI controller and looking at the traces.

Here is some investigation I did. Here I identified the messages within your serial dump:

C1 23 = MAIN MESSAGE (193), LENGTH IS 35
C2 22 = HMI MESSAGE (194), LENGTH IS 34
43 2D = ENERGY MESSAGE (67), LENGTH IS 45

C123 2E00230018001800150000000000000000000000008200000000454528CB000E011144
C222 32120000001000062C01D0020000003A211E0C0C000000004E450000060422013EFA
432D 0000071D0000000000000000071D0000EEB2390000000000000000000B4C105AFB27FB250B1B00000000000057
C123 2E00230018001800150000000000000000000000008200000000454528CB000E011144
C222 32120000001000062C01D0020000003A211E0C0C000000004E450000060422013EFA
432D 0000071D0000000000000000071D0000EEB2390000000000000000000B4C105AFB27FB250B1B00000000000057
C123 2E00230018001800150000000000000000000000008200000000454528CB000E011144
C222 32120000001000062C01D0020000003B211E0C0C000000004E450000060422013EFB
432D 0000071D0000000000000000071D0000EEB2390000000000000000000B4C105AFB27FB250B1B00000000000057
C123 2E00230018001800150000000000000000000000008200000000454528CB000E011144
C222 32120000001000062C01D0020000003B211E0C0C000000004E450000060422013EFB
432D 0000071D0000000000000000071D0000EEB2390000000000000000000B4C105AFB27FB250B1B00000000000057
C123 2E00230018001800150000000000000000000000008200000000454528CB000E011144
C222 32120000001000062C01D00200000000211E0D0C000000004E450000060422013EC1
432D 0000071D0000000000000000071D0000EEB2390000000000000000000B4C105AFB27FB250B1B00000000000057
C123 2E00230018001800150000000000000000000000008200000000454528CB000E011144
C222 32120000001000062C01D00200000001211E0D0C000000004E450000060422013EC0
432D 0000071D0000000000000000071D0000EEB2390000000000000000000B4C105AFB27FB250B1B00000000000057
C123 2E00230018001800150000000000000000000000008200000000454528CB000E011144
C222 32120000001000062C01D00200000001211E0D0C000000004E450000060422013EC0
432D 0000071D0000000000000000071D0000EEB2390000000000000000000B4C105AFB27FB250B1B00000000000057
C123 2E00230018001800150000000000000000000000008200000000454528CB000E011144
C222 32120000001000062001D00200000002211E0D0C000000004E450000060422013EC3

It seems they changed from CRC16 to an one-byte checksum which is not a CRC, instead it looks like a sum of all values to me. In the dump, only the HMI messages changes, since the time is provided from the HMI controller to the Main controller.

A more closer look to the HMI messages within your dump:

HMI Message
01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34
---------------------------------------------------------------------------------------------------------------------
32 12 00 00 00 10 00 06 2C 01 D0 02 00 00 00 3A 21 1E 0C 0C 00 00 00 00 4E 45 00 00 06 04 22 01 3E FA // Checksum 250
32 12 00 00 00 10 00 06 2C 01 D0 02 00 00 00 3B 21 1E 0C 0C 00 00 00 00 4E 45 00 00 06 04 22 01 3E FB // Checksum 251
32 12 00 00 00 10 00 06 2C 01 D0 02 00 00 00 00 21 1E 0D 0C 00 00 00 00 4E 45 00 00 06 04 22 01 3E C1 // Checksum 193: 3B (59) -> 00, 0C (12) -> 0D (13) => 251-59+1=193
32 12 00 00 00 10 00 06 2C 01 D0 02 00 00 00 01 21 1E 0D 0C 00 00 00 00 4E 45 00 00 06 04 22 01 3E C0 // Checksum 192
32 12 00 00 00 10 00 06 20 01 D0 02 00 00 00 02 21 1E 0D 0C 00 00 00 00 4E 45 00 00 06 04 22 01 3E C3 // Checksum 195

Identified: 
Pos. 16 = seconds
Pos. 19 = minutes
Pos. 34 = checksum

If you look at the isolated hmi messages, you actually see how the second and minute field is being increased and how the checksum differs for each changed message. To identify other values, you change a setting on your HMI controller and check how the message changed.

I can support you with a custom AquaMQTT version which dumps those messages to isolated mqtt topics for easy debugging. But the main part of analyzing the protocol would be up to you, since I don't have the hardware (and time) to support you way further. Goal would be another document similar to PROTOCOL.md. Of course it is very likely that there are similarities to the existing protocol, so it might be easier to spot the values.

In any way, I would love to see AquaMQTT support this newer protocol!

Looking forward!

Ok, so in this case the board and the connectivity works as it should. Let's debug the software ;)

I guess by debug topic you mean you have set constexpr bool DEBUG_RAW_SERIAL_MESSAGES to true? In this case, you should have three debug topics in mqtt...aquamqtt/hmi/debug, aquamqtt/main/debug and aquamqtt/energy/debug. There is a python script which writes the messages of the debug topics into files. You might want to use that, so we can debug this issue better.

Can you post a screenshot from the MQTT traffic created using MQTT Explorer? I am curious how the stats look like. There should be MQTT topics msgHandled, msgUnhandled, msgCRCNOKanddroppedBytes`.

Or did you already went ahead and tried Troubleshooting using AquaDebug? And this log is actually output from

Yes, the data comes from AquaDebug.

I’ve reinstalled the regular version.

I’m getting these topics:

Unfortunately, my time is very limited this week, but I’ll get back to you as soon as I have more time to work on this.

I had a bit of time and tried to analyze the set temperature change from 47°C to 48°C on the HMI.

To do this, I input the dump into ChatGPT to locate the relevant byte. The result looks like this:

Upon closer inspection, the change is as follows:

The byte sequence:

0000381D00002F0200000000381D0000AF

changes to:

0000381D0000300200000000381D0000AF

Here, the value changes at byte position 27 (starting from byte 00). The value shifts from 2F (which corresponds to 47 in decimal) to 30 (48 in decimal).

Result:

Therefore, it is very likely that the target temperature is located at byte position 27 in this dump.

Is this what you had in mind?

Hey, yes, I am not sure if ChatGPT will be really a help (because if it has no clue it will hallucinate quite a lot), but if that works for you in identifying positions of attributes I am surely ok with this approach.

I try to provide you a customized AquaMQTT version soon, which is aware of the new message format and then dumps the individual messages (hmi message, main message and energy message) to different mqtt topics. If will be way easier to locate changes if you look at a time series of isolated messages such as the hmi message changing over tim, similar to my little example above. Anyhow, which water target temperate was set in your first provided dump? I can't spot a 2F of an 30 in the hmi messages, so I guess you had set a different temperature back then?

I can’t tell you what temperature was set in the first dump anymore.

I tried a bit today to identify the bytes, but I need to get a laptop first. Going from the basement to the attic with each change is too cumbersome.

A version with split topics would definitely make things easier.

Thank you very much for your support.