Feedback Atlantic Calypso 100L

[jellewie]

Just wanted to share my experience and feedback while getting AquaMQTT working on my Atlantic Calypso 100L system. Hopefully this helps improve the documentation and user experience for others in the future.

1. Location ExampleConfiguration In the README.md the example configuration path isn’t fully specified. It would be helpful to mention that the file lives at: /AquaMQTT/include/config/ExampleConfiguration.h

2. MQTT needs the device to start After flashing from pc the IP will not be in the MQTT since it is not yet connected to a device. This would be a nice feature to add (so it would connect and report IP only). or to add as a note

[mqtt] is now connected
[mqtt] stat update
[mqtt]: stack size (words)6900
[hmi] no main message yet, cannot forward

3. Uploading Uploading to an "Arduino Nano ESP32" was horrible for me. There is some combination that you need to do with the RST button, but I'm still unsure what the exact combo is. It just failed to flash with error

Cannot open DFU device 2341:0070 found on devnum 4 (LIBUSB_ERROR_NOT_FOUND) No DFU capable USB device available Failed uploading: uploading error: exit status 74

3. Chip foodprint the AquaMQTT/blob/main/pcb/v2.0/AquaMQTT_Board_Revision_v2_BOM.csv says i need an "SN74LVC2T45DCUR", so I orderd that one from RSonline but it was to small https://nl.rs-online.com/web/p/bus-transceivers/2184634 I did manage to solder it successfully into place anyway

4. PCB markings esp orientation The PCB (I use 2.0) does not have easy markings what direction the board needs to have (I'ce just matched the bottom pin bottom pin names) Maybe add something to the sikscreen?

5. Diffrent HMI I got a different HMI flavour, I ended up soldereding wires to the main board to connect everything. The coloring was also different of the cable

6. Schematic I've also got this schematic with information about the main board on my unit

Results

I'm still checking if everything works properly, but this is what it reports in HA

[tspopp]

Thanks for this feedback, I will try to incorporate it any time soon.

Uploading to an "Arduino Nano ESP32" was horrible for me. There is some combination that you need to do with the RST button, but I'm still unsure what the exact combo is. It just failed to flash with error

Just press the RST button multiple times quickly, until it starts blinking green. It shouldn't be needed, but if the esp is in some strange condition, it can be helpful. See Arduino Bootloader Mode in the official docs: https://docs.arduino.cc/tutorials/nano-esp32/cheat-sheet/

Chip foodprint

I think you missed the section where it states that the V2 board is not meant for self-soldering. It is meant to be bought pre-assembled 😅

https://github.com/tspopp/AquaMQTT/blob/b9317c1a8ef49687d6b6e119d3548a1652b1ba36/pcb/README.md?plain=1#L34

Schematic

I have a similar one one in my heatpump, but I didn't share it intentionally, since I am not the creator/owner of this schematic.

Really glad that it in the end it worked all out, looks like you spend some time on this project 🥇 :tada:

[jellewie]

Still testing and observing how the system works, but here are some early observations

I have some sensors with weird numbers sensor.aquamqtt_dhw_heat_pump_fan_pwm = 0 or 0.1 sensor.aquamqtt_dhw_heat_pump_minimum_water_target_temperature = 0 or 1

I have some sensors that are not functional for me binary_sensor.aquamqtt_dhw_heat_pump_external_boiler = Off sensor.aquamqtt_dhw_heat_pump_hmi_software_version = Unknown sensor.aquamqtt_dhw_heat_pump_lower_evaporator_air_temperature = 0 sensor.aquamqtt_dhw_heat_pump_minimum_water_temperature_anti_legionella = 0 sensor.aquamqtt_dhw_heat_pump_pwm_fan_level_1 = 0 sensor.aquamqtt_dhw_heat_pump_pwm_fan_level_2 = 0 sensor.aquamqtt_dhw_heat_pump_pwm_fan_level_3 = 0 sensor.aquamqtt_dhw_heat_pump_supply_air_temperature = 0 sensor.aquamqtt_dhw_heat_pump_wattage_installed_heat_element = 0 select.aquamqtt_dhw_heat_pump_fan_exhaust_configuration = STOP

Sidenote: Soldering was not a problem for me (my work) it was the wrong chip format listed

[tspopp]

Seems like the protocol is slightly different, while overall compatible. Maybe you can enable DEBUG_RAW_SERIAL_MESSAGES in the Confirmation file an share a few messages sent on main/debug and hmi/debug

[jellewie]

I've followed TROUBLESHOOTING, I've changed the python code to have the client = mqtt.Client(callback_api_version=mqtt.CallbackAPIVersion.VERSION2) to fix an warning. I went though a few menus to make sure some HMI messages where send. Below data came from it after a few minutes, is this useful to you? What do you else need

aquamqtt_main_debug_hex.csv aquamqtt_energy_debug_dec.csv aquamqtt_energy_debug_hex.csv aquamqtt_hmi_debug_dec.csv aquamqtt_hmi_debug_hex.csv aquamqtt_main_debug_dec.csv

aquamqtt_hmi_debug_dec.csv aquamqtt_hmi_debug_hex.csv

[jellewie]

I have been analyzing the data to better understand the meaning of individual bits and to identify issues. While a comprehensive mapping of all signals is not yet complete, I have the following dataset. It includes the raw data, a manually recorded log, and Home Assistant (HA) data. In the HA data, Sonoff represents the PV switch. and Plug represents the power consumption of the boiler. aquamqtt_debug.xlsm

aquamqtt_energy_debug_hex.csv aquamqtt_hmi_debug_dec.csv aquamqtt_main_debug_dec.csv

[tspopp]

Finally found some time to check your dumps. The protocol is indeed the legacy protocol , but it seems values we have at other heatpumps are just zero in your protocol. Even more interesting, the software version from the HMI controller is 0 - usually it is a ASCII letter like A,B,C,D,E, F, G... etc. Does your HMI controller looks familiar to the ones we already have?

Unfortunately, it might be a bit difficult to add some automatic detection and disable certain properties. Right now, the amount of properties is bound to the protocol version which has been detected and there are no checks to validate the content of each property

What you can do, is disabling certain properties from the HomeAssistant MQTT Discovery.. You just have to return false in each case/property which is not available:

https://github.com/tspopp/AquaMQTT/blob/b9317c1a8ef49687d6b6e119d3548a1652b1ba36/AquaMQTT/lib/AtlanticSerialProtocol/include/mqtt/MQTTDiscovery.h#L719-L724

Maybe it is also possible to disable them in HomeAssistant directly.

Another alternative is to disable automatic discovery and build your own custom HomeAssistant configuration as described in https://github.com/tspopp/AquaMQTT/blob/main/HOMEASSISTANT.md

[jellewie]

As written in the debug excel file in the log. I the HMI reports to have version E and the board has version F. I haven't yet found there this is transfered in the protocol yet, but I want to.

Which file should this be stored in?

[jellewie]

Found what bit they should have been. Indeed te dump seems to not include the 69 (E) version code anywhere

Main Bit_28 = 'Controller Software Version' = "70" for me, char(70)=F

HMI Bit_27 = 'HMI Software Version' = "0" for me. But my version is E

[jellewie]

"HMI_Bit_6 = = when 'Emergency Mode Off' and 1 when 'Emergency Mode Off'. It seems that in the protocol docs you have more enabled that creates the 240 dec (0b11110000) value https://github.com/tspopp/AquaMQTT/blob/main/PROTOCOL.md#send-from-the-hmi-controller

Main_Bit_22 has an extra bit 0b00000010 with meaning. The other bits do seem right

Main_Bit_7 Seems to be evaporator_T in 0.1C digits (85=8.5C) Main_Bit_9 Seems to be incomming_air_T in 0.1C digits (143=14.3C) float temperature = (float) message / 10;

These bits seem to already have the right function: HMI_Bit_0 HMI_Bit_1-2 HMI_Bit_5 HMI_Bit_10 HMI_Bit_11 HMI_Bit_12 HMI_Bit_13 HMI_Bit_17 HMI_Bit_18 HMI_Bit_19 HMI_Bit_20 HMI_Bit_22 Main_Bit_0 Main_Bit_1-2 (Temperature seems about right) Main_Bit_7-8 (Temperature seems about right) Main_Bit_28 Main_Bit_33-34 Main_Bit_35

HMI_Bit_9 (Heating-Element / SetupState / PV allowed) Git says: `` 0b0000_0100 4: Heating-Element Automatic-Mode == 4 0b0000_0000 0: Heating-Element Disabled == 0 0b1010_0100 164: Setup Factory Settings == 164 0b0010_0100 36: Setup Airduct Set == 36 0b0000_0100 4: Setup Finished == 4 ... and PV allowed but not enabled = 4, 0b0000_0110 6: PV allowed and enabled = 6

Which is weirdly worded, since the number 4 is defined 3 times. For me the number is diffent, I'm trying to figure it out
0b0000_0010 2 boiler is on because pv connection was on
0b0000_0110 6 HMI boost on/Off 
i THINK it means more like this, but I need to run some more tests
0b0000_0000 0: Heating-Element Disabled
0b0000_0010 2: PV allowed and enabled
0b0000_0100 4: Heating-Element Automatic-Mode
0b0010_0000 32: Setup Airduct Set
0b1000_0000 128: Setup Factory Settings

power formula is (example for Energy_Bit_1-2)
float temperature = (float) (((int16_t) message[2] << 8) | message[1]) / 1000.0; (was not yet listed in git)


main_bit_20 seems to be 0b0000 when picturemask does not have 0b0010 ""heatpump on""
when bitmask main_bit_17=10 then main_bit_20 = 1
when bitmask main_bit_17=0,8,32,40 then main_bit_20 = 0"

[tspopp]

Which is weirdly worded, since the number 4 is defined 3 times.

Yes, actually these were my findings back then. In the end, it is all boiled down to a bitflags. So within the byte, certain bits individually represent something.

It's a bit unlucky that the manufacturer broke compatibility to their own protocol. They kept the same message ids and length and even checksums, but interpret the values differently. I have to make up my mind how to solve this. Maybe we could add some manual switch to the configuration for handling values differently.

[jellewie]

I would be committed enough to reverse engineer what every bit means on my unit. And do any test or checks required. But I've been looking into this gits code and I don't think I would be able to make the changes on my own without a lot of help.

An manual option for if the automatic one fails sounds like a good option

[tspopp]

I prepared a branch and I will take care of implementing it. But yes, I need you to spot the differences to the existing protocol.

Maybe you can create a list of all attributes which are currently broken, and how they should actually parsed in your case. So I can fix them one by one in the branch :)

[jellewie]

Back from holiday, and just installed my setup in Linux, I've updated to 1.8.1 and running the python still gives the <my local path>/AquaMQTT/tools/debug.py:32: DeprecationWarning: Callback API version 1 is deprecated, update to latest version client = mqtt.Client() warning. I've applied the same fix as descibed here before and that fixed it. Running another log atm, need to find out a few last options. I hope to get back to you withing a week or so with all the data

[jellewie]

aquamqtt_hmi_debug_dec

bit = values recorded = definition

0 = 35 = overlap with 'Length Field'
1 = 108,144,174,244
2 = 2,1
3 = 34,35 = Seems to overlap with 'Operation Mode'
4 = 60
5 = 0,16,32,33 = Seems to overlap with 'Anti-Legionella Mode / AirDuct Mode'
6 = 0,1 = Seems to overlap with 'Emergency-Mode'. (Docs might need an update that bit 0b1 is this)
7 = 0
8 = 0
9 = 2,4,6 = 0b0010 = pv signal connection option enabled, 0b0100 = HMI boost enabled (looks like an overlap too?)
10 = 36 = overlap with 'Timer Mode: Window 1 Start'
11 = 32 = overlap with 'Timer Mode: Window 1 Length'
12 = 70 = overlap with 'Timer Mode: Window 2 Start'
13 = 16 = overlap with 'Timer Mode: Window 2 Length'
14 = 0 
15 = 0
16 = 0
17 = 0to59 = overlap with 'Current Time Seconds'
18 = 81,113 = Seems to overlap with 'Current Day, Current Month in Half-Year'
19 = 51 = Seems to overlap with 'Current Year, Half-Year'
20 = 8to47 = Seems to overlap with 'Current Time Minutes'
21 = 14,20 = Seems to overlap with 'Current Time Hour'
22 = 0,1,4,5,2,3,6 = Seems to overlap with 'TestMode Status'
23 = 0
24 = 0
25 = 0
26 = 7
27 = 0 = HMI Software Version of "Interface E"??
28 = 0
29 = 0
30 = 0
31 = 0
32 = 255
33 = 255
34 = 255

aquamqtt_main_debug_dec.csv

bit = values recorded = definition

0 = 37 = Length Field
1 - 2 = 71,72,73,74,75,76,77,78,79,80,81,82,83,84,85 - 2 = Seems to overlap with 'Hot Water Temp'
3 = 0
4 = 0
5 = 0
6 = 0
7 = 85to147 = Evaporator Temp
8 = 0 = 
9 = 143to152 = Input Air Temp
10 = 0
11 = 0
12 = 0
13 = 0
14 = 0
15 = 0
16 = 0
17 = 0,8,10,32,40 = UNK, seems to be a status bitmask but it swings to much to decode from data. Not the exact same as this libary suggest at least
18 = 0,1 = fan on (0b0001)
19 = 0
20 = 1,0
21 = 0
22 = 34,50,18,16 
23 = 255
24 = 255
25 = 255
26 = 87
27 = 7
28 = 70
29 = 108
30 = 2
31 = 0
32 = 0
33 - 34 = 100 - 0 = 'Setting: Boiler Capacity (l)'
35 = 65 = 'Setting: Brand' (Atlantic)
36 = 0

aquamqtt_energy_debug_dec

Seems to be unchanged

Basically, mostly a confirmation of what I've already guessed before. There are still some bitmasks to figure out, but I can't find much logic in them yet All the data is in this file (raw and process versions) and the conclusion: aquamqtt_debug

[tspopp]

Hey,

I fixed a few things in my branch. You may want to try the changes. So far I...

• removed the hmi software version (missing in protocol)
• removed lower evaporator (missing in protocol)
• fix evaporator air temp (new formula). I did some guessing that it is interpreted as int16 - you will notice if the formular is correct as soon as there are negative temperatures (below 0°C)
• fix input air temp (new formula, same as above)
• removed fan speed pwm
• removed min temperature, min legionalle temperature, fan speed levels (missing in protocol)

Make sure to set constexpr bool PROTOCOL_USE_LEGACY_ALTERNATIVE = true; in the Configuration file, since there is no autodetection of this alternative protocol.

You may want to check power consumption values in your energy message, they look odd, too. Power Consumption Heatpump should be around 300 and 600 Watts and Power Consumption Heatelement should be 0W in your case, cause there is no heating element right? Combined consumption should match the power consumption of the heatpump. I guess the protocol is misinterpreted here, too.

[jellewie]

Electric unit is 1200W, heatpump is about 250-330W. Energy data looked to be fine to me?

Will flash and try the change

[tspopp]

Strange, these values definitely look odd.

[jellewie]

At 2025-10-17 14:15 the HMI data reported

Energy savings last 7 days ; 92%HP
Consumption last 7 days: 4kWh
Sep 20 kWh
Past 12months 27kWh
Since start 28kWh
Partial time in use hp 91h
Partial time in use elec 3h

The data from this intergration reports

23.47kWh consumption heatpump
4.722kWh consumption heating element
28.192kWh total consumption

Are you maybe used to look at old units? This was a quite a new instal so the numbers are still low

[jellewie]

Ow and a snippits of the new version working:

HA log.csv

[tspopp]

Ok, from what I've seen in the screenshots:

• Wattage Power Element is also not available and should be removed
• Boiler PWM Fan Levels have been removed. You need to remove the device from HA/MQTT once entirely and restart AquaMQTT to remove non-existing attributes which have been provided by earlier HomeAssistant Auto-Discovery.
• Boiler Power Consumed and Boiler Heatpump Power Consumed are still wrong. Power is supposed to be a value in W, not Wh (Energy). In your case it seems both values are some (additional) energy counter. In my case Power Heatelement is fixed to 1800W if the heat element is on and Power Heatpump varies in a range 300-600W. So you may want to check what these values mean - or we disable them until it's clear what they stand for? Edit: Ah, I missed your previous comment. It is likely that you have additional energy counters. Maybe you can give them a name, what do they count?
• Temperature values are looking good now, you agree?

[jellewie]

1. Correct, wattage seems to be '0' while our electric heating element is 1200W
2. I have now purged my HA entry like you've asked
3. No clue why sensor.aquamqtt_dhw_heat_pump_total_energy is in WH, I've not edited anything besides the basic configs
4. Temps look like I expect them to be

aquamqtt_energy_debug_dec.csv aquamqtt_energy_debug_hex.csv aquamqtt_hmi_debug_dec.csv aquamqtt_hmi_debug_hex.csv aquamqtt_main_debug_dec.csv aquamqtt_main_debug_hex.csv Log.txt HA history.csv

I have done no analysis on the above data yet.

Main bit 28 = 70 = "F" Controller Software Version. Correct