Request to support W'uau pool heat pumps (Tuya based Wifi device)

[Soepgroenten]

This seems to be a new brand which is becoming more and more common.

Not much to tell about it, it's working with the rebranded tuya app of w'eau, and the Tuya app itself offcourse.

Below the manual with some parameters specified.

weau-horizontal-full-inverter-single-phase.pdf

I'm looking forward for this integration :-)

[make-all]

Sorry, but the manual is not sufficient to add support. Protocol level information is required, and this can only from from the Home Assistant log messages when you try to add it (unsuccessfully presumably), or by monitoring it using another tuya protocol tool like tuya-cli.

[Soepgroenten]

Sorry, but the manual is not sufficient to add support. Protocol level information is required, and this can only from from the Home Assistant log messages when you try to add it (unsuccessfully presumably), or by monitoring it using another tuya protocol tool like tuya-cli.

Thanks for looking into this, I've tried to gather the required information based on your message. I've had no success using Tuya-CLI, whilst I'm very familiar with scripts and modules like the tuya-cli I ended up with some rare issues (but that's off topic)

Out of the Home assistant logging I couldn't get any usefull logging info regarding logs of Tuya-Local, but I've found something that looks pretty usefull at the localtuya logs, please have a look at the attached "Weau_heat_pump_log_DueToLocalTuyaAddIn.txt" file:

Weau_heat_pump_log_DueToLocalTuyaAddIn.txt

I also digged somewhat in the Tuya API and also saw a vew promising results, please have a look a the attached files below.

Weau_heat_pump_DeviceSpecification_DueToTuyaApi.txt Weau_heat_pump_InstructionSetDueToTuyaApi.txt Weau_heat_pump_InstructionSetOfCategory_DueToTuyaApi.txt

Where the results in file: "Weau_heat_pump_DeviceSpecification_DueToTuyaApi.txt" looks very familiar with the looks in the Tuya app. See screenshot below for an impression of how the Tuya gui looks like (Android).

I hope this is something useful you can do your magic with

[make-all]

Thanks, those logs and cloud API docs are enough to figure out the fairly simple functionality this heatpump exposes.

[Soepgroenten]

Thanks, those logs and cloud API docs are enough to figure out the fairly simple functionality this heatpump exposes.

Good to hear the provided information is sufficient, and that the heat pump seems to be pretty easy to implement.

Great thanks in advance 👍

[make-all]

There is some inconsistency between the TuyaAPI docs and the logs, screenshots and manual.

In the two API docs for the device (the category doc obviously contains things not relevant for this device, so I am discarding that), they both say the valid modes are "cold" and "hot", mapping to "Eco Cool" and "Boost Heat" respectively.

But in the log, the mode is "auto", and in the screenshot, there are modes "Boost Heat", "Eco Cool", "Auto", and "Eco Heat" visible. And in the manual, it says the valid modes are "Boost Heat", "Eco Heat", "Cool" and "Auto".

So I think to get the values correct, I need you to collect the logs for each of the modes.

There is also some inconsistency in that the manual says that the App functions include Timer and also Error display. But there is only one left over DP (6), so only one of those functions is possible. For now, I'll leave it as an unknown attribute so it can be observed. But if you can figure out what it is, it may be able to provide additional useful functionality (particularly if it is error codes, as it can be useful to trigger automations such as sending alerts off those).

[fwelvering]

So i have this W'eau heatpump but when adding it to HA is try's to add an 'Simple switch' I added the W'eau filt to the devices folder in HA and restarted HA to be save.

Is there anything i should do to get it working?

[make-all]

The support was not yet in the released version, until the version released today.

[fwelvering]

So i updated the integration and re added the pump, it still recognizes it as an simple-switch.

Homeassistant log tells me: 2022-06-09 14:27:32 WARNING (MainThread) [custom_components.tuya_local.config_flow] Device matches simple_switch with quality of 11%. DPS: {'1': False, '2': 'eheat', '9': 15, '10': 260, '20': 0, '101': 0, '102': 40, '103': 15, '104': True, 'updated_at': 1654777649.0827112} 2022-06-09 14:27:32 WARNING (MainThread) [custom_components.tuya_local.config_flow] Report this to https://github.com/make-all/tuya-local/issues/

[make-all]

It seems there are different models of this brand using completely different protocols. Do you have the model number? And if you have access to iot.tuya.com (to get your local key perhaps, or to set up the cloud integration), then under Cloud / API Explorer / Device Control can you run the last Get Device Specification Attribute function with your data center and device id. This will help with the function and range of some of those values.

[fwelvering]

Hi,

The output from the Get Device Specification: { "result": { "category": "rs", "functions": [{ "code": "switch", "type": "Boolean", "values": "{}" }, { "code": "mode", "type": "Enum", "values": "{\"range\":[\"auto\"]}" }, { "code": "temp_set", "type": "Integer", "values": "{\"unit\":\"℃\",\"min\":-500,\"max\":1000,\"scale\":0,\"step\":1}" }], "status": [{ "code": "switch", "type": "Boolean", "values": "{}" }, { "code": "mode", "type": "Enum", "values": "{\"range\":[\"auto\"]}" }, { "code": "temp_set", "type": "Integer", "values": "{\"unit\":\"℃\",\"min\":-500,\"max\":1000,\"scale\":0,\"step\":1}" }, { "code": "temp_current", "type": "Integer", "values": "{\"unit\":\"℃\",\"min\":-1000,\"max\":1000,\"scale\":1,\"step\":1}" }, { "code": "fault", "type": "bitmap", "values": "{\"label\":[\"sys_high_fault\",\"sys_low_fault\",\"flow_fault\",\"power_fault\",\"cooling_fault\",\"heating_fault\",\"temp_dif_fault\",\"in_temp_fault\",\"eff_temp_fault\",\"coil_temp_fault\",\"ret_temp_fault\",\"news_fault\",\"amb_temp_fault\",\"lack_water\",\"serious_fault\",\"sensor_fault\",\"motor_fault\"],\"maxlen\":16}" }] }, "success": true, "t": 1654852071365, "tid": "ce28efa6e89c11ec87342aa367714e21" } And from device details (for model and product no) { "result": { "active_time": 1653652854, "biz_type": 0, "category": "rs", "create_time": 1652620325, "icon": "smart/icon/ay1513418289516FAXSV/df2cf842ab71c359308c3814492d5ee9.png", "id": "70631187e868e7d4ebde", "ip": "<redacted>", "lat": "<redacted>", "local_key": "<redacted>", "lon": "<redacted>", "model": "RCDF211344", "name": "Weau pool heat pump", "online": false, "owner_id": "<redacted>", "product_id": "zqwet1zcvj2wcxzw", "product_name": "Weau pool heat pump", "status": [{ "code": "switch", "value": false }, { "code": "mode", "value": "eheat" }, { "code": "temp_set", "value": 15 }, { "code": "temp_current", "value": 259 }, { "code": "fault", "value": 0 }], "sub": false, "time_zone": "+01:00", "uid": "<redacted>", "update_time": 1653652859, "uuid": "<redacted>" }, "success": true, "t": 1654852209433, "tid": "20759836e89d11ecaeb54a08c3e1e6f8" }

[Soepgroenten]

Unfortunately due to work I had no time to perform anything...(stil very busy) but below the the respons ot the "Get device specification attributes" query:

{ "result": { "category": "ktkzq", "functions": [ { "code": "switch", "type": "Boolean", "values": "{}" }, { "code": "temp_set", "type": "Integer", "values": "{"unit":"℃","min":7,"max":60,"scale":0,"step":1}" }, { "code": "mode", "type": "Enum", "values": "{"range":["hot","cold"]}" } ], "status": [ { "code": "switch", "type": "Boolean", "values": "{}" }, { "code": "temp_set", "type": "Integer", "values": "{"unit":"℃","min":7,"max":60,"scale":0,"step":1}" }, { "code": "temp_current", "type": "Integer", "values": "{"unit":"℃","min":-300,"max":1500,"scale":1,"step":1}" }, { "code": "mode", "type": "Enum", "values": "{"range":["hot","cold"]}" } ] }, "success": true, "t": 1654852847759, "tid": "9ce865afe89e11ec87342aa367714e21" }

I think this is usefull info to be able to compare my results with the results of fwelvering

[make-all]

Unfortunately the API Explorer has a lot of similarly named functions which return subtly different results. The one I was after was the last one listed under the second last category (Device Control). That is the only one that ties in to the local dp_ids.

[fwelvering]

Any eta on the next release?

[Soepgroenten]

I've tested with the current update..to me the integration is a bit of a succes. Unfortunately the device becomes unavailable over time:

I Noticed that it only happens when I'm actually looking at the Entity in my dashboard

Reloading Tuya Local doesnt solve the issue. To solve this I have to restart HomeAssistant.

What could this be? And how can I help solving this?

[make-all]

Thanks for confirming. I think the device becoming unavailable is a common issue with Tuya devices - make sure nobody uses the Tuya app, as that can block other local connections to your device. Otherwise, I do see messages like this in the log regularly myself, but they don"t really affect the UI, so I think it is just an occasional poll being missed.

[fwelvering]

After installing the latest release mine is still recognised as an simple switch. Do you need any extra information to hopefully fix the issue?

[make-all]

Yes, this issue is still open with the Device Variant tag to reflect that the information you gave in an earlier comment is a variation of the original that will require a new config to handle.

[Soepgroenten]

I've tested somewhat further and I discovered that when the heatpump went unavailable..it immediately becomes available after pushing any setting to it (changing temp, turning off, changing heat/cooling mode). In the end I have some feeling that the TuyaLocal setup isn't the issue. I believe it's coming from the tuya based device. However this issue is generating huge gaps into my temperature history tracking, and I cannot put the device to an automation as I cannot rely on it. I'm goin to set the temperature every hour by automation trying to keep the device alive in Tuya Local/Homeassistant. and I'm goin to test the same theory also in my automations (putting the temp change to 28° just before reading out the device).

I'll report back if this workaround does the job, but of course it'll be better if we can rely on the device itself :-)

Another thing to notice: The heatpump has actually 2 heating modes. an Eco heat and a Boost heat. When setting the heat mode with tuya local it's setting the Boost heat mode which is less energy efficient. Not a big deal as I can set the eco mode on the device or via the tuya app itself, but it would be nice if tuya local supports it.

@make-all You're doing a great job with Tuya Local I really like the approach of how it's working, it's really well thought out. And of course your support deserves a lot of credits 👍

Edit: Unfotunately, the idea of changing temp to it's current value won't work due to missing option to set it by automation. I can only set the HVAC values (have a look at the screenshot below):

Of course I can set the heating mode to keep the device available, but then I lose the Eco heat mode which consumes much more power.

[make-all]

I think the device becoming unavailable may be due to the extra undocumented modes it supports. The documentation you provided specified the valid modes as "hot" and "cold", but the current data you provided had a value of "auto", so I added that also. Now (and from the screenshot) you are saying there are also Eco heat and Eco cool modes. fwelvering's current data is showing "eheat", so maybe the eco modes are "eheat" and "ecool"? Can you confirm? I think you will get errors from Home Assistant about invalid HVAC modes, since I just pass through unmapped values, but hopefully the error message will have the actual value in it. Otherwise you may need to enable debug logging for the integration temporarily to find what values are being set.

[make-all]

I need confirmation of the modes supported to complete this support.

[Soepgroenten]

I'm sorry for my late reply. Below the status of each Mode: Eco Heat Boost Heat Eco Cool Auto

There's also a "waterflow protection" attribute but that one seems to be unfindable in iot.tuya I've tought it was the switch parameter in the responses above but that one doesnt change when the waterflow protection is active.

Below also the latest output of the device specification attributes (with all dp_id's): { "result": { "category": "ktkzq", "functions": [ { "code": "switch", "dp_id": 1, "type": "Boolean", "values": "{}" }, { "code": "temp_set", "dp_id": 2, "type": "Integer", "values": "{"unit":"℃","min":7,"max":60,"scale":0,"step":1}" }, { "code": "mode", "dp_id": 4, "type": "Enum", "values": "{"range":["hot","cold"]}" } ], "status": [ { "code": "switch", "dp_id": 1, "type": "Boolean", "values": "{}" }, { "code": "temp_set", "dp_id": 2, "type": "Integer", "values": "{"unit":"℃","min":7,"max":60,"scale":0,"step":1}" }, { "code": "temp_current", "dp_id": 3, "type": "Integer", "values": "{"unit":"℃","min":-300,"max":1500,"scale":1,"step":1}" }, { "code": "mode", "dp_id": 4, "type": "Enum", "values": "{"range":["hot","cold"]}" } ] }, "success": true, "t": 1657259048137, "tid": "fc22c9d8fe8011ec8201daf929f70cab" }

In the end I must say, the device works well now for a while already...Only the eco heat and waterflow protection is missing.

The device also didnt stopped reporting anymore for some reason...so it's reliable now and I can depend on it.

[make-all]

Waterflow protection is usually a bit on a more general integer fault code dps. It will be one of the as yet unidentified integer dps I think.

It is there as "flow_fault" in the docs that fwelvering got from the Tuya Portal, which as it is the third listed I think it will be the 3rd bit (4):

{ "code": "fault", "type": "bitmap", "values": "{\"label\":[\"sys_high_fault\",\"sys_low_fault\",\"flow_fault\",\"power_fault\",\"cooling_fault\",\"heating_fault\",\"temp_dif_fault\",\"in_temp_fault\",\"eff_temp_fault\",\"coil_temp_fault\",\"ret_temp_fault\",\"news_fault\",\"amb_temp_fault\",\"lack_water\",\"serious_fault\",\"sensor_fault\",\"motor_fault\"],\"maxlen\":16}

[Soepgroenten]

integer fault code

I See, fwelvering got these info from the Get Device Specification query, but mine doesn't state anything like flow_fault or anything that looks like it. probably they do it by magic with my heat pump 😁

Just like the Eco mode.

If the Eco heat mode and waterflow switch aren't possible with Tuya Local then so be it 😉 I'm already glad it works like the way it does now and it's running smoothly for weeks now so we can Mark this one as completed.

[make-all]

eco should work, I think, it is just the documentation that is lacking. I suspect from the initial information provided that dps 6 will be the fault and maybe the same values as fwelvering's variant (for which I still need the dp ids to make a config).

[Soepgroenten]

Unfortunately I already posted all available DP_id's...there's no othere page than the "Get Device Specification Attribute" under "Device Control".

it states the following:

Get Device Specification Attribute

{ "result": { "category": "ktkzq", "functions": [ { "code": "switch", "dp_id": 1, "type": "Boolean", "values": "{}" }, { "code": "temp_set", "dp_id": 2, "type": "Integer", "values": "{"unit":"℃","min":7,"max":60,"scale":0,"step":1}" }, { "code": "mode", "dp_id": 4, "type": "Enum", "values": "{"range":["hot","cold"]}" } ], "status": [ { "code": "switch", "dp_id": 1, "type": "Boolean", "values": "{}" }, { "code": "temp_set", "dp_id": 2, "type": "Integer", "values": "{"unit":"℃","min":7,"max":60,"scale":0,"step":1}" }, { "code": "temp_current", "dp_id": 3, "type": "Integer", "values": "{"unit":"℃","min":-300,"max":1500,"scale":1,"step":1}" }, { "code": "mode", "dp_id": 4, "type": "Enum", "values": "{"range":["hot","cold"]}" } ] }, "success": true, "t": 1657267812014, "tid": "63cf5a25fe9511ec887d9287a6a8350d" }

But I do not think this will help you/us further, any clues where to look for more DP_id's? Tried practically every query available in iot.tuya. Also tried debugging but that doesnt show the dp id's either.

[make-all]

The original capture of local data had the following:

({'1': False, '2': 33, '3': 195, '4': 'auto', '6': 0}

So '6' is the only candidate, I think it is a safe assumption that that is how the water flow fault is being communicated back to the app. I will make a general "fault" sensor that signals any non-zero value, and also leave the original fault code as an attribute on the climate entity so the information is available in case anyone wants to confirm the meanings of specific values.

[Soepgroenten]

The original capture of local data had the following:

({'1': False, '2': 33, '3': 195, '4': 'auto', '6': 0}

So '6' is the only candidate, I think it is a safe assumption that that is how the water flow fault is being communicated back to the app. I will make a general "fault" sensor that signals any non-zero value, and also leave the original fault code as an attribute on the climate entity so the information is available in case anyone wants to confirm the meanings of specific values.

Sounds like a good plan, let me know when the update is available...then I'll test it.

[make-all]

Eco mode and fault binary sensor have been added to the original config in 0.18.0.

The second variant is still pending more information on the available modes, as the device log does not seem to match the documentation, and it also does not match any of the modes available in the original version.

[fwelvering]

Is there anything you need from me to add the device variant?

[make-all]

Unfortunately the API Explorer has a lot of similarly named functions which return subtly different results. The one I was after was the last one listed under the second last category (Device Control). That is the only one that ties in to the local dp_ids.

Also, the valid modes are listed in the previous API Explorer result as ["auto"], while the current value is "eheat". I'm afraid you're going to have to do some experimentation to find what the full list of actual actual valid modes is, since the API Explorer is not telling the whole story.