-
Notifications
You must be signed in to change notification settings - Fork 620
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
base: main
Are you sure you want to change the base?
Conversation
amantia
commented
Jan 15, 2025
- added rest of DPS
- commented some actions
- added comments about problems
I own an Axen/Dotels 10KW split pump where I wrote a configuration just before the Axen configuration was added. 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. |
- entity: water_heater | ||
name: Water heater |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- entity: water_heater | ||
name: Water heater | ||
dps: | ||
- id: 1 | ||
type: boolean | ||
name: operation_mode |
There was a problem hiding this comment.
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).
There was a problem hiding this comment.
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"
}
}
}
}
There was a problem hiding this comment.
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. |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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. |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this 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 |
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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"
}
},
category: diagnostic | ||
dps: | ||
- id: 122 | ||
type: integer | ||
name: sensor | ||
unit: Hz | ||
unit: "Step" | ||
range: |
There was a problem hiding this comment.
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. |
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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.
FYI, I am reworking based on the suggestion, just need more time ... |
- added rest of DPS - commented some actions - added comments about problems