Madimack Elite V3 Pool heatpump with updated dps mappings #1691
Conversation
Updated Madimack Elite V3 mappings
| @@ -0,0 +1,200 @@ | |||
| name: Madimack Elite V3 pool heatpump | |||
There was a problem hiding this comment.
Ideally this config should have a products section listing the id and branding part of the name, and this top level name should just be the generic part: "Pool heatpump".
There was a problem hiding this comment.
Yes, I can find the product ID through the tuya platform and change. However, I have noticed the product ID code found is identical to another device by the same manufacturer already in your system (madimack_eco_heatpump.yaml). Will using the same product ID code for a different unit be a problem?
There was a problem hiding this comment.
I imagine when I eventually use this, it will be capable of showing a list, the same as the dps matching that is currently used (and will continue to be used as a backup). But if the product ids are the same, maybe the config is also compatible (maybe only partially specified, as the knowledge of where to get good info from to make a complete config has evolved over time).
There was a problem hiding this comment.
I have added a product ID line and the specific name of the unit I am using to my fork. I'm also a github newbie so let me know if you cannot see this.
As mentioned before - there may be an issue in that the product ID appears to be duplicated with other completely separate products made by the same manufacturer
custom_components/tuya_local/devices/madimack_elite_v3_heatpump_updated.yaml
Outdated
Show resolved
Hide resolved
custom_components/tuya_local/devices/madimack_elite_v3_heatpump_updated.yaml
Outdated
Show resolved
Hide resolved
custom_components/tuya_local/devices/madimack_elite_v3_heatpump_updated.yaml
Show resolved
Hide resolved
| - id: 105 | ||
| name: preset_mode | ||
| type: string | ||
| translation_key: madimack_presets |
There was a problem hiding this comment.
I don't think device specific translation keys are the way to go. There are currently 627 configs which is a lot of individual icon customisation.
It is better to group into common functionality. Pool heatpumps fairly commonly support "quiet" "quick" and "smart" presets, though many of them annoyingly have separate presets for cooling and heating modes, and I think we can group these together for both translations and icons.
There was a problem hiding this comment.
Yep - I gave it a crack to see if it would work on my end and no go. I'll revert the changes
There was a problem hiding this comment.
Changes reverted. Apologies - being github newbie I suspect my code editing was causing trouble on the main repository - apologies if it was.
I have:
Reverted all changes in icons.json in my fork
Erased any reference to custom icons in the device file, and put the heatpump presets to generic translateable names.
Changed the name of the device to generic "Pool heatpump"
Added a product ID code, although I think it is duplicated
Added a Fault code DPS as a bitfield
Added, but then removed a secondary device to change temperature units in the tuya backend, after confirming changing the units did not change the functionality with HA. The end user could change the units on their machine and HA will translate.
|
Can you check the info you are using to make this config against the info here: #1431 It looks like the dps assignments are the same, but probably some need to be made optional, as they are not showing up on your unit. They may have taken the Madimack Eco firmware and disabled a few features without changing the product id, I guess, or they use the same Tuya module firmware, but it has some conditions to enable/disable features based on some input to the module. |
|
Hi yes - the DPS mappings do appear identical, even down to the product ID number. It's interesting that when I re-added the new unit, this particular device file was unable to match (I was presented only with "tuya_switch" as an option). Scanning through the DPS values for the Eco unit - the main difference is in the preset modes. The Eco unit appears to have a "silence," "perfect," "power," and "boost" presets. The unit I have (Elite V3) does not have a "boost" mode option, just the other presets. Without knowing how your DPS mapping algorithm works, I suspect this may have made the difference. The remaining DPS's are accurate - even the "power" field. On my unit however, the power field appears to be supplying garbage data that does not correspond to actual power outputs. I don't know if the Eco unit does this correctly. Happy to be guided by you on next steps. It sounds like the manufacturer is just cobbling things together. I'm happy to run a custom file in my own instance and not add to the integration repository. |
Hello, I've been using your custom integration for a while to interface with my pool heat pump. I have recently had the whole thing replaced due to an electrical failure under warranty.
The new heat pump is identically named, but the dps mappings have changed. The heatpump was not auto-recognized by the existing integration.
I have rewritten the device file with the newer correct mappings and have renamed the file so it does not conflict with the original file for the older version of the unit.
I have also renamed a few of the diagnostic entities to correspond with the original control app. I also attempted to change the preset modes on the heater to correspond with the naming in the control app. Whilst this works, I am unable to specify appropriate icons in the latest version of HA (I don't understand yet how translations and the icons.yaml file work). So, I have left them as in the original file.
The newer heat pump also has dps maps for power (kW) functionality. I tried mapping it as well, but the data from it is weird. I think it only measures power for the control board, and not the whole unit. This would have been useful if it was properly implemented.