-
Notifications
You must be signed in to change notification settings - Fork 592
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. |
- added rest of DPS - commented some actions - added comments about problems
@@ -14,6 +14,7 @@ entities: | |||
name: switch | |||
- entity: binary_sensor | |||
class: problem | |||
name: Errors |
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.
Not needed. The class name is translated. An explicit name will not be.
type: boolean | ||
name: hvac_action |
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.
Why is it necessary to remove the hvac_action and current_temperature? These are both quite useful info to have.
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.
117 tells the state of the option for the 4 way valve .
{
"abilityId": 117,
"accessMode": "ro",
"code": "valve",
"description": "",
"name": "Four-way valve status",
"typeSpec": {
"type": "bool"
}
},
I don't see how this is related to the climate entity. It is something that gets turned on/off while the pump is running, if you have it installed. I don't even have it.
- 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.
- 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).
- entity: sensor | ||
name: Inlet temperature | ||
class: temperature | ||
category: diagnostic |
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.
Why are these diagnostic markers removed? All the various temperature sensors are not the primary thing you want to be interacting with for this 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.
I don't really mind and was not really aware what should go under diagnostics and what is under sensors. My reasoning was to have those fields that give variable data throughout the functioning, like temperature values as not part of diagnostic as the user could use them for automations.
mapping: | ||
- dps_val: false | ||
value: "off" | ||
- dps_val: true | ||
constraint: work_mode | ||
conditions: | ||
- dps_val: cool | ||
value: air_cooling | ||
value: Cooling |
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 I set this up ready for translations, but did not provide the translations. It would be better to finish the translations rather than change the 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.
Sure, I would gladly do that way.
# - 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.
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.
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.
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.