Please add support of heater Wetair WCH-750 AL WIFI

[Vikedlol]

Name: Wetair WCH-750 AL WIFI

HA warning: Device matches simple_switch with quality of 12%. DPS: {'1': False, '2': 17, '4': 'mod_free', '11': 'heating', '19': '0h', '20': 0, '21': 0, '101': 'level1', 'updated_at': 1632857027.131441}

Now it works just like a switch, but I would like to ask you add an ability to set target temp (dps = 2), and current hvac mode (off, idle, heat) if it possible.

I can provide examples of heater statuses in different modes, if it required

[make-all]

Hi, if you can figure out what the "mod_free", "level1" and "heating" values are, and if they can be set by the user, what the possible values are, that would be ideal.

In HA "heating" is used to indicate back what the heater is doing, but is not directly set by the user. The fact that you include "idle", suggests the same - so the dps 1 would be the user control, (HEAT, OFF), and dps 11 is the heater reporting back whether it is "heating" or "idle" if the user has set it to HEAT, or "off" if the user set it to "OFF".

level1 could be the heating level (or fan, if the heater has a fan), in which case I'll need to know how many levels there are, and whether this is something that can be set, or its just something the heater reports back after automatically adjusting its level.

mod_free, I'm totally unsure about.

0h looks like a timer, which we don't really support, so it will just be reported as an attribute with no abililty to set it from HA. The other two 0 values, could be also related to the timer (some devices have a minute or second countdown in addition to the 0h for setting the timer), error codes, or something else. I don't see a current temperature reading, which is unusual for a heater., as it must have a sensor for the set temperature to work, I guess one of the 0 values might be a current temperature reading that only comes on when the heater is switched on?

[Vikedlol]

Looks like, that this heater does not report current temp at all.
It will be great to support of enable/disable, set target temp (supported interval 10-35), current hvac status (off, idle, heating).
Set mode (auto, turbo, anti-frost) is not so important, but would be great to have.

Disabled heater:
Payload: {'1': False, '2': 20, '4': 'mod_free', '11': 'heating', '19': '0h', '20': 0, '21': 0, '101': 'level1'}

Enabled, but idle heating:
Payload: {'1': True}
Payload: {'11': 'warm'}

Set temp to 21:
Payload: {'2': 21}

Enabled, started to heat:
Payload: {'11': 'heating'}

Enabled, reached target temp, going to idle
Payload: {'11': 'warm'}

Turbo mode:
Payload: {'4': 'mod_max12h'}

Disable turbo, return to default mode:
Payload: {'4': 'mod_free'}

Control screen brightness: (0 - disabled screen, 3 - most bright)
Payload: {'101': 'level0'}
Payload: {'101': 'level3'}
Payload: {'101': 'level2'}
Payload: {'101': 'level1'}

Timer:
Payload: {'19': '1h'}
Payload: {'19': '2h'}
Payload: {'19': '3h'} (increasing timer to 3 hours)
Payload: {'20': 180}
Payload: {'20': 179} (in 1 min)
Payload: {'20': 178} (in 2 mins)

Anti-frost:
Payload: {'2': 7}
Payload: {'4': 'mod_antiforst'} (looks like a typo in firmware :-))

DPS 21 is unknown for me, cant found any combination to change it

Thank you in advance!
I tried to modify your integration locally, but my Python skills not so good to make it nice and pretty. :-)

[make-all]

I think the only Python changes required are to implement brightness settings for the light entity (current devices only have on..off switch, so that is all that is implemented so far).

The climate device should be implementable with just a new yaml configuration file in custom_components/tuya_local/devices/
For release, there will also be unit tests in python, but they are not strictly required to make the device work..

[Vikedlol]

Thank you!

Looks like that climate features are working, except light integration.

Logger: homeassistant.components.light
Source: custom_components/tuya_local/generic/light.py:89
Integration: Освещение (documentation, issues)
First occurred: 13:33:24 (2 occurrences)
Last logged: 13:33:24

Error adding entities for domain light with platform tuya_local
Error while setting up tuya_local platform for light
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 382, in async_add_entities
    await asyncio.gather(*tasks)
  File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 587, in _async_add_entity
    await entity.add_to_platform_finish()
  File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 698, in add_to_platform_finish
    self.async_write_ha_state()
  File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 464, in async_write_ha_state
    self._async_write_ha_state()
  File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 498, in _async_write_ha_state
    state = self._stringify_state()
  File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 470, in _stringify_state
    state = self.state
  File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 882, in state
    return STATE_ON if self.is_on else STATE_OFF
  File "/config/custom_components/tuya_local/generic/light.py", line 89, in is_on
    return self._brightness_dps.get_value(self._device) > 0
TypeError: '>' not supported between instances of 'NoneType' and 'int'

Anyway, it's great!

[Vikedlol]

The only minor thing: the allowed temp range should be 10-35, not 5-35.
Setting up target temp from 5-10 range enabling the away mode, and changing the temp to another value throws errors until the away mode will be disabled manually.

[make-all]

I think I have fixed the two issues highlighted in the release 0.11.0

[Vikedlol]

Did some tests on the release 0.11.0.

Climate entity works correctly now, the only thing that I found - climate entity is "unavailable" after component start until I send any command to it (on or off). After that, everything works fine.

Light entity: on/off commands are work, but there are some brightness issues. Default light card do not allow to change brightness, if I will call the turn_on service with brightness param - sometimes it will change it correctly, sometimes - no effect at all.
I did not found any specific steps to reproduce it.

Light entity:

supported_color_modes:
  - onoff
color_mode: brightness
brightness: 255
friendly_name: my_heater
supported_features: 0

[make-all]

Since there are only three levels, but Home Assistant uses 255, there are a lot of brightness values that will result in the same brightness. If you are using a slider, it may be generating commands too quickly for the device to keep up, so it drops some.
It may be more reliable to add three buttons for the brightness levels 85, 170 and 255.

[make-all]

I noticed that supported_color_modes is not matching color_mode above, which may be the cause of the intermittent working, and certainly the missing UI functionality. This should be fixed in main.