Failed to call service

[etamtlosz]

Finally I managed to get my uuid and local key, using HttpCanary (Packet Capture is not working anymore), added my heater (GPCV330) to my HA config. The heater shows up, but I have issues toggling on/off. At first I need to switch between Operation/Preset modes, until it turns ON. After that, no matter what temp I set, the Currently value stays at 30C although the Comfort temp is set lower. When I try to set the temp, I'm getting the error: Failed to call service climate/set_temperature. 25 is not in list

According to my Goldair app, there's no firmware upgrade available. I'm running WiFi Module: 2.2.6 and MCU Module 1.0.0

tuya-cli with protocol-version 3.2 returns:

  devId: '16750538cc50e3xxxx',
  dps: {
    '1': true,
    '2': true,
    '3': 30,
    '4': 25,
    '5': 0,
    '6': 0,
    '7': 'Low'
  }
}

[etamtlosz]

As an update, Log Viewer shows this error:

Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 550, in _update_entity_states
    await asyncio.gather(*tasks)
  File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 284, in async_update_ha_state
    self._async_write_ha_state()
  File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 314, in _async_write_ha_state
    attr = self.capability_attributes
  File "/usr/src/homeassistant/homeassistant/components/climate/__init__.py", line 181, in capability_attributes
    self.hass, self.min_temp, self.temperature_unit, self.precision
  File "/config/custom_components/goldair_climate/heater/climate.py", line 126, in min_temp
    if self.preset_mode and self.preset_mode != STATE_ANTI_FREEZE:
  File "/config/custom_components/goldair_climate/heater/climate.py", line 195, in preset_mode
    return GoldairTuyaDevice.get_key_for_value(PRESET_MODE_TO_DPS_MODE, dps_mode)
  File "/config/custom_components/goldair_climate/__init__.py", line 250, in get_key_for_value
    return keys[values.index(value)]
ValueError: 22 is not in list

[make-all]

Based on the DPS reported, this is a completely different device than the GPPH series heaters. It looks almost similar to the Kogan heater I have, but with rearranged DPS indexes. In fact I did a web search and cosmetically the heater looks identical to the Kogan heater, so its like they took the same predesigned product from China and someone with OCD rearranged the DPS indexes to group the booleans, ints and text attributes together.

If you turn the heater on, does dps 1 switch to true, or dps 2?

Does it have just LOW and HIGH modes, or are there more?

Is the temperature range 15-35 like the Kogan (and Tuya cloud integration), or 5-35 like the GPPH?

Does it have a timer function? Both the Kogan and GPPH heaters seem to use a boolean and an int for this, so that would explain the second false and one of the 0 values. I guess the other int is a fault code, which the Kogan is missing, but GPPH has.

Is there a child lock and/or ability to turn off the light (maybe if there is no timer, otherwise it does not look like there are enough DPS attributes exposed).

If it has a timer, which of the 0 values changes when you set it? On Kogan it is dps[8] and the GPPH dps[102], so neither gives a clue as to this one.

[etamtlosz]

Sorry, you got me lost with the DPS values. How can I find these out?

Here are the other answers: It has two modes, high/low Temp range is 15-35 It has a timer function, goes from 00 to 24h. There is a child lock, but didn't find an option to turn the display off.

[make-all]

You wrote

tuya-cli with protocol-version 3.2 returns:

devId: '16750538cc50e3xxxx', dps: { '1': true, '2': true, '3': 30, '4': 25, '5': 0, '6': 0, '7': 'Low' } }

If you change some settings using the buttons on the heater while monitoring with tuya_cli, you should see those values change.  The main one is whether Power on/off is the expected '1' (same as the GPPH series, and same as most Tuya based switches, lights etc).   Secondary is to set the timer and see whether '5' or '6' changes, as that will allow us to guess that the other one is probably a fault code, as most Goldair devices seem to have a fault code and you have one additional setting beyond what the Kogan heater has (that does not have a fault code).

On my Kogan heater Power is '7', and the timer off/on toggle is '6', so if they just shifted those together, you may have ended up with power on '2' instead of '1'.  Once we can figure out which is power, it should be fairly easy to add support for this heater, as the target and current temperatures and preset mode are fairly obvious, and none of the other devices internal timers are supported so we will skip that.

[etamtlosz]

Sorry, my head was somewhere else ;)

1 - power - true for on, false for off 2 - child lock 3 - set temp 4 - measured temp 5 - is timer in minutes 6 - can't figure it out what it is 7 - high/low

[make-all]

Interesting that you mention it has a child lock. When I go back to my Kogan manual, it also mentions a child lock, and the official app also seems to have it. I'd previously assumed based on my investigations into the Goldair GPPH720 I have that the timer used an integer for the minute countdown, and a boolean to indicate whether to switch on or off at the end of the countdown. But it seems that second boolean might be for the child lock rather than the timer.

[make-all]

Does 6 change with the timer setting (maybe if you set it to more than one hour)? Or just stays at 0?
If it stays at 0, it is most likely a fault code. Unlike the dehumidifier where you can remove the tank to trigger it, I don't think there is any safe and easy way to trigger a fault on a heater.

[etamtlosz]

There's no way to set it the minute, only the hours. Is the same in the app and on the heater. I had a hope that it could be the timer in minutes until the set off time. I've set it to 5 hrs, hoping that dps 5 will stay at 300 (minutes) and 6 will start counting up. But nope, 5 is counting down, 6 still has the value of 0.

    '5': 297,
    '6': 0,

[make-all]

There are basically two ways to add support

1) As a separate device (gpcv_heater) - quick and easy, but maybe too messy for @nikrolls to accept as a pull request 2) By adding some auto-detection into the heater component. I am not sure if this can be done early enough for the capabilities to be set appropriately, and how to prevent the user from configuring a light entity since this heater doesn't support it. So this will be more complex, but is probably tidier.

I've gone with approach 1 for quick and easy kogan heater support in my own forked repository, but my eventual aim is to move everything into configuration files, which will probably mean some incompatible configuration changes along the way.

[nicole-ashley]

Thanks everyone for the research you've done so far!

I've already implemented auto-detection in master so we could build off that. It kicks in early enough that we can use completely different device classes to handle different devices (including different capabilities).

I'm happy to take a stab at supporting your device once I get this release out (I'm pretty close, maybe a week away). Otherwise we could chat here to figure out a strategy so you could get started on a PR yourself.

[etamtlosz]

No rush, I can use it manually or via the app until the next release. I've tried the beta as well, but it was buggy, the operation drop down was empty.

[make-all]

If you're happy with a separate device, then it should be fairly similar to the kogan_heater support in make-all/tuya-local, with some dps adjustments and child lock added back in.

[etamtlosz]

tuya-local is kind of a no go, tried installing it via HACS and it hangs forever while adding it as an integration. Sometimes it gives me this almost blank form.

[make-all]

There is an issue with HACS handling of symlinks. You'll see the same if you install the 0.1.0 beta releases from nikrolls/homeassistant-goldair-climate

If you log in using ssh and manually run the following commands, then it should act more properly:

cd config/custom_components/tuya_local
rm .translations translations/en.json
ln -s translations .translations
cd translations
ln -s ../strings.json en.json
ha core restart

But there are other issues, which is why I initially branched off from 0.0.8 for the above push. But I am not sure a branch is usable via HACS.

[etamtlosz]

@make-all I've tried your commit and so far everything looks good. Thanks

[nicole-ashley]

@make-all's PR has now been merged and released as 0.1.1b0. @etamtlosz, would you mind upgrading to this in HACS and testing it for a few days? I'll also run it locally to regression test against the devices I have. Then I can move to public release.

If you can't see the update, you'll just need to show beta updates in HACS: go to the Goldair component, click the three dots, and select "Show beta":

[etamtlosz]

Cool, I've installed the beta. I'm going to keep an eye on it, and I'll report back if I notice something wrong. Thanks

[nicole-ashley]

Thanks!

[swratten]

Hi Guys, Sorry for jacking your thread.

I got this device yesterday, have tried using HTTP Canary to MITM but all apps fail to discover the heater until I disable HTTP Canary and then I can register fine (I also have the same issue if I connect to my wireguard VPN while at home not sure why) Will try to see if I can get the Tuya Smart Link method to work instead.

Anyway I did manage to get the DPS schema from HTTP Canary after registering the device (I get the "No Lan connection or device is occupied" message in the Android app when using HTTP canary or VPN) So it seems like TCP / UDP doesnt want to work when using any of those.

DPS Schema

```json [ { "mode": "rw", "code": "Switch", "name": "开关", "property": { "type": "bool" }, "id": 1, "type": "obj", "desc": "" }, { "mode": "rw", "code": "Lock", "name": "童锁", "property": { "type": "bool" }, "id": 2, "type": "obj", "desc": "" }, { "mode": "rw", "code": "Temp_set", "name": "温度", "property": { "unit": "℃", "min": 5, "max": 40, "scale": 0, "step": 1, "type": "value" }, "id": 3, "type": "obj", "desc": "" }, { "mode": "ro", "code": "Temp_current", "name": "当前温度", "property": { "unit": "℃", "min": 0, "max": 100, "scale": 0, "step": 1, "type": "value" }, "id": 4, "type": "obj", "desc": "" }, { "mode": "rw", "code": "Timer", "name": "倒计时", "property": { "unit": "min", "min": 0, "max": 1440, "scale": 0, "step": 60, "type": "value" }, "id": 5, "type": "obj", "desc": "" }, { "mode": "ro", "code": "FAULT", "scope": "fault", "name": "故障告警", "property": { "label": [ "Fault_1", "Fault_2" ], "type": "bitmap", "maxlen": 2 }, "id": 6, "type": "obj", "desc": "" }, { "mode": "rw", "code": "Mode", "name": "工作档位", "property": { "range": [ "High", "Low" ], "type": "enum" }, "id": 7, "type": "obj", "desc": "" } ] ```

[icepicknz]

I just tried to add this with HACS, but there is nothing to add, is this manual only now? Secondly the two heaters I want to control I added to Tuya account (rather than Goldair app). Does this integration only work if my HA is on the same LAN as my heater as mine isn't.

I can see the heaters in my HA at the moment, but as op described cant control them as low/high on/off isn't available.

I can change the temp at the moment and see data logging.

Just wondering before I go down a rabbit hole of manually configuring if the IP is used for local comms and I wont be able to do it that way