Support for EKHWET-BAV3 (Multi DHW Tank) sensor mapping from ESPAltherma

[tamet83]

Hi,

first of all, thank you for this project. I am currently using the original ESPAltherma project by raomin on my Daikin/Altherma system:

https://github.com/raomin/ESPAltherma

My current working ESPAltherma definition file is:

https://github.com/raomin/ESPAltherma/blob/main/include/def/EKHWET-BAV3(MULTI%20DHW%20TANK).h

I would like to know whether this definition could be integrated into esphome-altherma as an additional supported mapping.

From what I can see, this project already contains model-specific mappings under confs/, for example:

• confs/erga_eh_da_04_08.yaml
• confs/erla_d_ebsh_11_16_ech2o.yaml

However, I could not find an equivalent mapping for:

EKHWET-BAV3 (Multi DHW Tank)

Since the original ESPAltherma definition already provides the relevant register metadata, such as:

• UART register
• offset
• converter ID
• data size
• sensor label/name

I was wondering if it would be possible to port it into an ESPHome YAML mapping file, for example:

confs/ekhwet_bav3_multi_dhw_tank.yaml

My understanding is that the ESPAltherma definition entries should be portable, because each entry already contains the information required by this ESPHome component.

For example, ESPAltherma entries from the .h definition file could potentially be converted into ESPHome entries like:

sensor:
  - platform: altherma_hub
    altherma_hub_id: altherma_hub_1
    name: Example sensor name
    register: 0xXX
    offset: X
    convid: XXX
    datasize: X

I should also mention that I am not currently using all the sensors exposed by the ESPAltherma definition file. My current setup only relies on a subset of the available values.

However, I would be interested in understanding which sensors this ESPHome component would be able to expose from that definition, and whether a partial mapping would already make sense.

I am not sure whether all entries can be converted directly, since some values may need to become sensor, binary_sensor, or text_sensor entities depending on the converter output.

I would be available to test the mapping on my actual system and report which entities work correctly and which ones are actually useful in my setup.

My questions are:

1. Would this model/mapping be suitable for integration into this project?
2. Is converting the ESPAltherma .h definition into a YAML mapping the correct approach?
3. Would you accept a pull request for this if the mapping is tested?
4. Are there any conventions I should follow when classifying entries as sensor, binary_sensor, or text_sensor?

Thanks for your work on this project.

[jjohnsen]

Hi @tamet83,

Yes, this should be possible.

The default mapping, erga_eh_da_04_08.yaml, is based on the original ESPAltherma definition here: https://github.com/raomin/ESPAltherma/blob/main/include/def/Altherma(ERGA%20D%20EHV-EHB-EHVZ%20DA%20series%2004-08kW).h

In practice, there seem to be minimal differences between many of the ESPAltherma definition files, except for the protocol-S pump definitions.

I have been meaning to add documentation explaining how these mappings relate to the original ESPAltherma .h definition files, but I have not gotten that far yet.

I did a quick comparison between:

• Altherma(ERGA D EHV-EHB-EHVZ DA series 04-08kW).h
• EKHWET-BAV3(MULTI DHW TANK).h

From that quick check, it does not look like you are missing any important sensors compared to the default mapping.

My suggestion would be to first try the default config and see how well it works on your system. If you find that some values are missing, you can use the experimental register discovery support to identify additional registers: https://github.com/jjohnsen/esphome-altherma?rel=1.1.0#register-discovery-experimental

Those missing registers can then be added to a dedicated definition/mapping if needed.

To answer your questions directly:

1. Yes, this model/mapping would be suitable for integration.
2. Yes, converting the ESPAltherma .h definition into a YAML mapping is the correct approach.
3. Yes, I would accept a pull request, especially if the mapping has been tested on real hardware.
4. Yes, entries should be classified as sensor, binary_sensor, or text_sensor based on the converter/output type. In most cases this should be fairly easy to determine once you look at the values exposed by the mapping.

A partial mapping also makes sense. It is usually better to start with the values that are known to work and are useful, then extend it as more registers are confirmed.