Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improvements to the Axen heat pump configuration #2787

Open
wants to merge 3 commits into
base: main
Choose a base branch
from

Conversation

amantia
Copy link

@amantia amantia commented Jan 15, 2025

  • added rest of DPS
  • commented some actions
  • added comments about problems

@amantia
Copy link
Author

amantia commented Jan 15, 2025

I own an Axen/Dotels 10KW split pump where I wrote a configuration just before the Axen configuration was added.
I migrated the missing parts here, but I still have issues with the current config that I couldn't figure out yet myself, so help is welcome.
Those are mostly marked in the file, but the most important would be the problem with the operation mode of the water heater.
Personally I find the way how the water heater and climate setting are separated not ideal, due to the fact that the device actually just heats the water based on certain configurations and whatever you do with that later is up to the user.
Eg. the climate values are not for room temperatures, but for the heating agent.
I pretty much would prefer just having individual settings per configurations and use a generic thermostat from HA to control the device. I could do that (as I have that locally), but I didn't want to be too disruptive. It would be similar approach to https://github.com/make-all/tuya-local/pull/2705/files

Some DPS i renamed slightly based on what the Tuya app, the documentation and the DPS query returns.

I attach also the (auto-translated) JSON file describing the DPS.
r32_heat_pump_query_english.json

@amantia amantia changed the title Improvements to the Axen pump configuration Improvements to the Axen heat pump configuration Jan 15, 2025
- entity: water_heater
name: Water heater
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is no need to add a name that is the same as the entity name. It will only override the default translation with an untranslated name.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am not yet very familiar with how the strings are translated. I changed the names because otherwise all I got was the lower case and with underscore texts in the frontend and i see similar code in other devices, where names were provided as English strings. I will look up though how to do it properly.

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What language is your HA front end set to? It may be that we still need translations for that language.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I use English for the HA frontend for now.
I tried to add the translations and it works for the separate entity for operation mode, but not when used inside the water heater:
Screenshot_20250119_191419
Screenshot_20250119_191619

- entity: water_heater
name: Water heater
dps:
- id: 1
type: boolean
name: operation_mode
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess this means that this device does not like having two dps set in one command.

Probably the best way to deal with this is to separate dp 1 into a separate switch entity, and make dp 109 directly operation mode (maybe leaving dp 1 as "available" like in the climate entity).

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems to work, minus the missing translation for the operation_mode. I couldn't figure out how to solve that, tried also adding things like

    "water_heater": {
      "operation_mode": {
        "state": {
          "cooling": "Cooling",
          "heating": "Heating",
          "auto": "Auto",
          "hot_water": "Hot water",
          "cool_hot_water": "Hot water and cooling",
          "heat_hot_water": "Hot water and heating",
          "auto_dhw": " Auto and hot water"
        }
      }
    }

or

    "water_heater": {
      "state_attributes": {
        "operation_mode": {
          "state": {
            "cooling": "Cooling",
            "heating": "Heating",
            "auto": "Auto",
            "hot_water": "Hot water",
            "cool_hot_water": "Hot water and cooling",
            "heat_hot_water": "Hot water and heating",
            "auto_dhw": " Auto and hot water"
          }
        }
      }
    }

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You need an extra layer which is the translation_key. For the default case, "_" is used.

# - dps_val: 1
# value: "1"

# Below items are reported by the device.
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If they are not useful enough to be sensor entities on their own, they can be added as attributes to another entity with which they are linked.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some min/max values indeed might be linked, but they don't match very well, as there can be different max value for heating temperature depending on other configurations, like how many zones there are defined. The heat pump can deal with no zones, one zone or two zones and a different set of combination how the heating behaves per zone.
I was mostly referring that some of these cannot be modified remotely, you need to modify on the device itself, which makes it less useful for normal use case, but could be useful for advanced users to remotely see the configuration, especially that all this information is very much hidden in the official app as well behind Chinese names.

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have now also added the possibility to mark entities as hidden, in which case they will not be included in HA by default, but are available for the user to enable if they want them. This may also be suitable for these sensors.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I added hidden: true for those sensors, but I don't see a change, they are still fully visible. I saw for other devices a possibility to have by default hidden entities, e.g it show +4 entities not shown

value: "Zone 1 & 2"
icon: "mdi:home"
# TODO: Find the meaning of the values and provide a user friend description
- entity: sensor
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is possibly a bitfield that defines which modes are available in the specific model, in which case it should be used in available attributes in the appropriate entity.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is

                        {
                            "abilityId": 131,
                            "accessMode": "ro",
                            "code": "mode_valid",
                            "description": "",
                            "name": "valid mode",
                            "typeSpec": {
                                "type": "enum",
                                "range": [
                                    "0",
                                    "1",
                                    "2",
                                    "3",
                                    "4",
                                    "5",
                                    "6",
                                    "7"
                                ]
                            }
                        },

but couldn't correlate yet to any real functionality, hence the comment.


# Indoor means the room where the internal unit is located
- entity: sensor
name: Indoor temperature
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Possibly this might be a better dp to use for current_temperature in the climate entity if the previously used ambient temperature dp is not suitable.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think both are not good choice. The ambient temperature reported is the outside temperature, which makes no sense to report. The internal temperature is the temperature of the room where the unit is, again not that useful for the end user. The only thing that I see valuable are one the below:

  • temperature of the heating water
  • temperature of the returned water
  • temperature of the water tank (for the domestic hot water)

As I wrote in the first comment, I am not sure using water_heater or even more climate is really good choice for such devices. Personally what I am doing is controlling fully the device from HA, thus the best is to directly access all the DPS values, not through an intermediate device, like water_heater or climate. There might be other use cases though, that is why I didn't push for that.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

FTR, I set the water heater to show the water tank temperature, the climate to show the inlet water temperature as that is what you can control with.

value: "Manual setting"
- dps_val: 1
value: "Room temperature"
# TODO: This needs a double check as the manual is not clear.
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It seems to be selecting between a small number of options, the meaning of each option is needed.

Copy link
Author

@amantia amantia Jan 15, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That is unclear unfortunately, so far I couldn't figure out from the different user manuals or the UI of the pump. I am fine not having those entities in the config file or having them disabled until me or someone else can come up with the real meaning.

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What I would normally do in this case is to put them as attributes, so they are not directly exposed in the UI, but are still available for observation so users can figure out the meanings if motivated.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I honestly not sure how to do it and won't have time to deal with it for at least a week. I am fine if they are hidden by default.

Copy link
Author

@amantia amantia left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the comments, I will try to improve the file and if you can give some hints to do the translations/naming properly I will gladly do that,

@@ -233,34 +246,64 @@ entities:
mapping:
- scale: 10
- entity: binary_sensor
name: Frost protection
class: cold
name: Protection
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

DP 110, called "protection switch" in the API seems to be a flag indicating if some kind of protection kicked in. I didn't see it live, it must happen if something goes wrong, like too hot water, pressure, etc.
In the tuya app there is a separate button to show the faults, might appear there.

DP 114, Frost protection is called "winter antifreeze". If the ambient temperature is low this is kicked in when the pump is not running. This is switched on/off often by the pump and it is indicated as "Antifreeze" in the Tuya app.

DP115 is also running periodically, while the pump is in operation, to defrost the outside unit.

type: boolean
name: sensor
- entity: binary_sensor
name: Defrosting
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same reason as above, happy to revert if there are real translations files.

category: diagnostic
dps:
- id: 122
type: integer
name: sensor
unit: Hz
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Both the Tuya app and the JSON query for DPS indicates Step. See here the exempt

                        {
                            "abilityId": 122,
                            "accessMode": "ro",
                            "code": "m_eev",
                            "description": "",
                            "name": "Main valve opening",
                            "typeSpec": {
                                "type": "value",
                                "max": 480,
                                "min": 0,
                                "scale": 0,
                                "step": 1,
                                "unit": "step"
                            }
                        },
                        {
                            "abilityId": 123,
                            "accessMode": "ro",
                            "code": "a_eev",
                            "description": "",
                            "name": "Auxiliary valve opening",
                            "typeSpec": {
                                "type": "value",
                                "max": 480,
                                "min": 0,
                                "scale": 0,
                                "step": 1,
                                "unit": "step"
                            }
                        },

Screenshot_20250115_175506_Tuya Smart

category: diagnostic
dps:
- id: 122
type: integer
name: sensor
unit: Hz
unit: "Step"
range:
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, I got that also from the JSON, see above.

# - dps_val: 1
# value: "1"

# Below items are reported by the device.
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some min/max values indeed might be linked, but they don't match very well, as there can be different max value for heating temperature depending on other configurations, like how many zones there are defined. The heat pump can deal with no zones, one zone or two zones and a different set of combination how the heating behaves per zone.
I was mostly referring that some of these cannot be modified remotely, you need to modify on the device itself, which makes it less useful for normal use case, but could be useful for advanced users to remotely see the configuration, especially that all this information is very much hidden in the official app as well behind Chinese names.

value: "Zone 1 & 2"
icon: "mdi:home"
# TODO: Find the meaning of the values and provide a user friend description
- entity: sensor
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is

                        {
                            "abilityId": 131,
                            "accessMode": "ro",
                            "code": "mode_valid",
                            "description": "",
                            "name": "valid mode",
                            "typeSpec": {
                                "type": "enum",
                                "range": [
                                    "0",
                                    "1",
                                    "2",
                                    "3",
                                    "4",
                                    "5",
                                    "6",
                                    "7"
                                ]
                            }
                        },

but couldn't correlate yet to any real functionality, hence the comment.

@amantia
Copy link
Author

amantia commented Jan 19, 2025

FYI, I am reworking based on the suggestion, just need more time ...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: 👀 In review
Development

Successfully merging this pull request may close these issues.

2 participants