ANKO Smart Fan with Wi-Fi (Kmart fan)

[wishie]

Device normal info

• Brand: ANKO
• Model: "Smart Fan with Wi-Fi" HEGSM40

I can't seem to see the entries you're asking for in the logs.

The fan can be turned on/off from HA without issue, but nothing else works (preset mode, fan speeds, oscillation etc)

[frenck]

Yesterday, Home Assistant 2022.2 was released. Could you try upgrading to that version and see if the issue has been resolved?

If not, Home Assistant 2022.2 contains a new diagnostic tool. There is now a "Download Diagnostics" button on each Tuya device on the device page. Clicking that button will download diagnostics information for that specific device. Drag the downloaded file into this issue. It will help with finding out what the problem is.

[wishie]

I will test now and get back to you shortly.

I will grab diagnostics also.

[wishie]

It still does not work as expected. Diagnostics file attached. Thanks

tuya-bb9196586cbfe48699edb39ab22969b5-Tatiana Fan-c63a2e837633c1816bfb9c0733292490.json.txt

[frenck]

The diagnostics look good, a nice entity seems to be created, that is populated with the presets, fan speeds and toggles.

Could you more extensively describe the issue you are experiencing? And maybe, there is something in the logs?

[wishie]

As mentioned in the original issue, oscillate does not work, nor does changing fan speeds or presets.

I will try to enable debug logging again, and capture some more info.

[wishie]

Fan speeds seem to work now, except the slider seems to allow values from 0 to 100 (the fan supports 1 to 8)

When sending some commands here is some of the output

2022-02-06 19:54:33 DEBUG (SyncWorker_3) [homeassistant.components.tuya] Sending commands for device 610233452462ab17bcfe: [{'code': <DPCode.SWITCH: 'switch'>, 'value': True}]
2022-02-06 19:54:34 DEBUG (Thread-12) [homeassistant.components.tuya] Received update for device 610233452462ab17bcfe: {'switch': True, 'mode': 'normal', 'fan_speed': '5', 'switch_horizontal': 'false', 'countdown': '0'}
2022-02-06 19:54:34 DEBUG (Thread-12) [homeassistant.components.tuya] Received update for device 610233452462ab17bcfe: {'switch': True, 'mode': 'normal', 'fan_speed': '5', 'switch_horizontal': 'false', 'countdown': '0'}
2022-02-06 19:54:41 DEBUG (SyncWorker_4) [homeassistant.components.tuya] Sending commands for device 610233452462ab17bcfe: [{'code': <DPCode.FAN_SPEED: 'fan_speed'>, 'value': '8'}]
2022-02-06 19:54:42 DEBUG (Thread-12) [homeassistant.components.tuya] Received update for device 610233452462ab17bcfe: {'switch': True, 'mode': 'normal', 'fan_speed': '8', 'switch_horizontal': 'false', 'countdown': '0'}
2022-02-06 19:54:46 DEBUG (SyncWorker_7) [homeassistant.components.tuya] Sending commands for device 610233452462ab17bcfe: [{'code': <DPCode.FAN_SPEED: 'fan_speed'>, 'value': '1'}]
2022-02-06 19:54:47 DEBUG (Thread-12) [homeassistant.components.tuya] Received update for device 610233452462ab17bcfe: {'switch': True, 'mode': 'normal', 'fan_speed': '1', 'switch_horizontal': 'false', 'countdown': '0'}
2022-02-06 19:54:51 DEBUG (SyncWorker_5) [homeassistant.components.tuya] Sending commands for device 610233452462ab17bcfe: [{'code': <DPCode.SWITCH_HORIZONTAL: 'switch_horizontal'>, 'value': False}]
2022-02-06 19:54:52 DEBUG (Thread-12) [homeassistant.components.tuya] Received update for device 610233452462ab17bcfe: {'switch': True, 'mode': 'normal', 'fan_speed': '1', 'switch_horizontal': 'false', 'countdown': '0'}
2022-02-06 19:54:57 DEBUG (SyncWorker_3) [homeassistant.components.tuya] Sending commands for device 610233452462ab17bcfe: [{'code': <DPCode.SWITCH_HORIZONTAL: 'switch_horizontal'>, 'value': True}]

As you can see, when the command Is sent to turn on 'oscillate' (switch_horizontal) the device does not reply with an update.

[wishie]

Also, as far as the 'presets' are concerned, this device only supports 'nature' and 'sleep'. I also notice that once you set a preset, there is no way to disable a preset, but only change between them.

[frenck]

this device only supports 'nature' and 'sleep'

That is not what Tuya communicates to Home Assistant:

      "mode": {
        "type": "Enum",
        "value": {
          "range": [
            "nature",
            "sleep",
            "fresh",
            "smart",
            "strong",
            "closed"
          ]
        }
      },

If this is incorrect, you'd need to contact Tuya directly. Home Assistant will of course show the data provided by the Tuya API.

except the slider seems to allow values from 0 to 100 (the fan supports 1 to 8)

That is correct. Home Assistant works from 0-100% in fan speeds. This is translated back to Tuya fan speeds. Thus not an error, but working as intended.

As you can see, when the command Is sent to turn on 'oscillate' (switch_horizontal) the device does not reply with an update.

Hm... it does send the right command:

2022-02-06 19:54:57 DEBUG (SyncWorker_3) [homeassistant.components.tuya] Sending commands for device 610233452462ab17bcfe: [{'code': <DPCode.SWITCH_HORIZONTAL: 'switch_horizontal'>, 'value': True}]

Based on the logs and the diagnostics, the working is correct from the Home Assistant end. The values seems right and what comminicates is expected too. I would contact Tuya directly on this matter, as this might be an issue with this specific device and their cloud services.

[wishie]

I will confirm that the device works as intended using the Tuya app (its been a long time since Ive opened it)

[frenck]

I will confirm that the device works as intended using the Tuya app

That really doesn't tell anything. The Tuya app and the Tuya cloud API are not behaving the same. So, the app doesn't confirm anything.

[wishie]

But the app talks to the same API I would assume?

[frenck]

No, it doesn't.

[wishie]

I have opened a ticket with Tuya via their IoT platform, and will post the results here, once I have something.

[wishie]

I got the following reply so far:

"thank you for waiting 1：about Setting "Oscillate" on or off does not work this problem，We'll take care of it, it may take some time, be patient 2：about mode support，It's because the standard data point supports normal, nature, and sleep. Our test also supports these three. You can confirm it again. "

[wishie]

But in Home Assistant, there is no way to set mode to "Normal" and Home Assistant also shows other presets that are not supported. I have mentioned this to them.

[wishie]

The latest response is:

"because the standard data point supports normal, nature, and sleep,So on the app these three work fine，The standard instruction set has these values {"nature","sleep","fresh","smart","strong","closed"}, so your HA shows these six, but only sleep and nature are included in data point inside the value, so on HA you can only operate sleep and nature"

[wishie]

Ok, so the update I got from Tuya engineer is:

"thank you for waiting Hello, the Data Point defined by the manufacturer, I am sorry that we do not have a solution for you at present."

This sounds to me like they are blaming the manufacturer of the fan.. so I assume there is no workaround then?

[cathelest]

Iv also had issues with arlec fans where for whatever reason the manufacturor has differed from the standard tuya control sets and unfortunently there really needs to be a way to have custom control sets that we can just set ourselfs to add functionality,

The only workaround i have found is that you can setup scenes for the different commands in the tuya app, and sync those back to ha, this will atleast give u the functions but you wont get any of the device status feedback,

[wishie]

With Zigbee devices, there are 'quirks' for hardware.. I wonder if something like that exists for Tuya stuff

[wishie]

What I dont get is, Tuya is saying its a fault caused by the manufacturer incorrectly setting features/functions etc..

But that does not explain how the device works perfectly within the Tuya app..

[wishie]

Ok, this is response from Tuya is interesting:

"The value of the device function point is taken from the app, but you call the value of the standard instruction set through the api. The two value channels are different，the Data Point defined by the manufacturer"

So does that mean that HA is calling a 'standard instruction set' through the API, but the Smart Life app somehow knows better, and only shows certain functions?

[wishie]

@frenck "The value of the device function point is taken from the app, but you call the value of the standard instruction set through the api. The two value channels are different，the Data Point defined by the manufacturer"

Does this mean that HA calls a 'generic' device via the API, and the Tuya app does something different? Is this something that can be fixed on the HA side?

[wishie]

There is even more odd behaviour.. setting to speed slider in HA to around "35" sets the fan itself to "9".. you mentioned how its mapped, but the odd thing is, if using the fans controls itself, the speed settings only go from 1 to 8. 9 is not possible when using the fan itself. The Tuya app also only allows 1 through 8.

[frenck]

Is this something that can be fixed on the HA side?

As already said above, the Tuya API provides us what to show. We don't make that up or use a default or anything like that.

See my comment from 8 days ago here: https://github.com/tuya/tuya-home-assistant/issues/766#issuecomment-1030802805

[wishie]

So since Tuya developers are saying "its provided by the manufacturer" and HA can only use what the API provides, this device is basically unusable/unsupported and there is no way around this?

[frenck]

I'm sorry, but as said multiple time, according to the API these are the capabilities reported by the Tuya API. We have to assume that that is the source of truth.

[deepcoder]

I am seeing that there is more than one ground truth when it comes to both the possible values for a data point and what what data points are available. I have seen this difference for several TUYA based devices.

For example below, for a Sunbeam Heated Mattress pad. I retrieve the data points and each data points range of values two ways (but both use the TUYA developer database I believe), first using the tinytuya python module, and second going directly to the TUYA developer web site and entering the device id directly.

In this example both ways of retrieving the possible range for the count down timer, data point 26, named 'countdown_set_1' show a set of possible values to be six values, 1 to 6 hours, however the TUYA iOS app shows many more possible values for this dp, as is shown in picture below. And they work. I can also set these additional values programmatically to the device and they work as well.

I have yet to discover how to get to the data base that the TUYA iOS app uses.

What I am currently doing is maintaining my own 'extended' JSON structure for each device that I am controlling with my python module using local tuya apis. As I discover additional dp's and ranges for dp's, I update my local 'extended' set of functions.

 {'code': 'countdown_set_1', 'dp_id': 26, 'type': 'Enum', 'values': '{"range":["1h","2h","3h","4h","5h","6h"]}'}

--- query using the tinytuya python module:

Device List: [{'name': 'Sunbeam Bedding', 'id': 'bbb', 'key': 'aaa'}]
DPS IDs of device:
 {'result': {'category': 'dr', 
 'functions': [
 {'code': 'switch_1', 'dp_id': 14, 'type': 'Boolean', 'values': '{}'}, 
 {'code': 'level_1', 'dp_id': 20, 'type': 'Enum', 'values': '{"range":["level_1","level_2","level_3","level_4","level_5","level_6","level_7","level_8","level_9","level_10"]}'}, 
 {'code': 'preheat_1', 'dp_id': 24, 'type': 'Boolean', 'values': '{}'}, 
 {'code': 'countdown_set_1', 'dp_id': 26, 'type': 'Enum', 'values': '{"range":["1h","2h","3h","4h","5h","6h"]}'}], 

 'status': [
 {'code': 'switch_1', 'dp_id': 14, 'type': 'Boolean', 'values': '{}'}, 
 {'code': 'level_1', 'dp_id': 20, 'type': 'Enum', 'values': '{"range":["level_1","level_2","level_3","level_4","level_5","level_6","level_7","level_8","level_9","level_10"]}'}, 
 {'code': 'preheat_1', 'dp_id': 24, 'type': 'Boolean', 'values': '{}'}, 
 {'code': 'countdown_set_1', 'dp_id': 26, 'type': 'Enum', 'values': '{"range":["1h","2h","3h","4h","5h","6h"]}'}, 
 {'code': 'countdown_left_1', 'dp_id': 28, 'type': 'Integer', 'values': '{"unit":"sec","min":0,"max":86400,"scale":0,"step":1}'}]}, 

 'success': True, 't': 1643146695560}

Received Payload: {'dps': {'13': 0, '14': True, '20': 'level_10', '24': True, '26': '10h', '28': 35040, '102': 840, '103': '45_Minutes_Before'}}

---- from Tuya developer web site

{
  "result": {
    "category": "dr",
    "functions": [
      {
        "code": "switch_1",
        "desc": "{}",
        "name": "开关1",
        "type": "Boolean",
        "values": "{}"
      },
      {
        "code": "level_1",
        "desc": "{\"range\":[\"level_1\",\"level_2\",\"level_3\",\"level_4\",\"level_5\",\"level_6\",\"level_7\",\"level_8\",\"level_9\",\"level_10\"]}",
        "name": "档位1",
        "type": "Enum",
        "values": "{\"range\":[\"level_1\",\"level_2\",\"level_3\",\"level_4\",\"level_5\",\"level_6\",\"level_7\",\"level_8\",\"level_9\",\"level_10\"]}"
      },
      {
        "code": "preheat_1",
        "desc": "{}",
        "name": "预热1",
        "type": "Boolean",
        "values": "{}"
      },
      {
        "code": "countdown_set_1",
        "desc": "{\"range\":[\"1h\",\"2h\",\"3h\",\"4h\",\"5h\",\"6h\"]}",
        "name": "倒计时1",
        "type": "Enum",
        "values": "{\"range\":[\"1h\",\"2h\",\"3h\",\"4h\",\"5h\",\"6h\"]}"
      }
    ],
    "status": [
      {
        "code": "switch_1",
        "name": "开关1",
        "type": "Boolean",
        "values": "{}"
      },
      {
        "code": "level_1",
        "name": "档位1",
        "type": "Enum",
        "values": "{\"range\":[\"level_1\",\"level_2\",\"level_3\",\"level_4\",\"level_5\",\"level_6\",\"level_7\",\"level_8\",\"level_9\",\"level_10\"]}"
      },
      {
        "code": "preheat_1",
        "name": "预热1",
        "type": "Boolean",
        "values": "{}"
      },
      {
        "code": "countdown_set_1",
        "name": "倒计时1",
        "type": "Enum",
        "values": "{\"range\":[\"1h\",\"2h\",\"3h\",\"4h\",\"5h\",\"6h\"]}"
      },
      {
        "code": "countdown_left_1",
        "name": "倒计时剩余时间1",
        "type": "Integer",
        "values": "{\"unit\":\"sec\",\"min\":0,\"max\":86400,\"scale\":0,\"step\":1}"
      }
    ]
  },
  "success": true,
  "t": 1644840838727
}

[frenck]

For example below, for a Sunbeam Heated Mattress pad

That is not related to this issue?

Anyways, we use the official Python module in Home Assistant made by Tuya. You are still mixing up sources.

[deepcoder]

I was trying to point out that the TUYA 'api' seems to have two flavors at least, I thought that was the original crux of the question and also as you pointed out:

'If this is incorrect, you'd need to contact Tuya directly. Home Assistant will of course show the data provided by the Tuya API.'

Which 'API'?

As pointed out, TUYA device can show one functionality at the TUYA developer web site and another via their TUYA mobile app.

From what I am seeing, the lack of consistency in programatic functionality of devices base in this TUYA family is a really challenge.. The TUYA world is far behind the programmatic apis of families like zigbee and zwave.

[frenck]

I was trying to point out that the TUYA 'api' seems to have two flavors at least

Yes, that was already established earlier in this thread: https://github.com/tuya/tuya-home-assistant/issues/766#issuecomment-1030841871

Which 'API'?

The only one available. https://developer.tuya.com/en/docs/iot/introduction-to-tuya-iot-platform?id=Ka6vijvqb3uhn

As pointed out, TUYA device can show one functionality at the TUYA developer web site and another via their TUYA mobile app.

Yes.

From what I am seeing, the lack of consistency in programatic functionality of devices base in this TUYA family is a really challenge.. The TUYA world is far behind the programmatic apis of families like zigbee and zwave.

Yes, even that was already pointed out before. We are running in circles now.

[deepcoder]

I disagree with your statement : 'The only one available.' If that is the case, where is the Tuya iOS app getting its information? Which is sometimes different that the information that is returned by the API that you point out.

Can you acknowledge this point, or explain to me why this is not the case?

If you have some connections with the Tuya folks, I think it would be a useful to ask them why there can be a least two different 'views' of the capabilities of Tuya devices.

Yes, I think a number of folks are 'circles' because of these issues.

When folks buy a Tuya product and see a set of functionality via their mobile app and then they try to operate the device via the developer API you point out and find a different set of functionality, that is going to be frustrating.

As I follow the various Tuya projects, the inconsistency and lack of documentation of device function is a recurring theme.

[frenck]

If that is the case, where is the Tuya iOS app getting its information?

That API is not available to Home Assistant. So, not something we care about 🤷

Can you acknowledge this point, or explain to me why this is not the case?

I cannot, as this is the issue tracker for the Home Assistant integration. We are limited to what is made available by Tuya. All the rest of your questioning around Tuya's policies and APIs is completely out of scope for Home Assistant, not a concern and not something we can work with.

As I follow the various Tuya projects, the inconsistency and lack of documentation of device function is a recurring theme.

I agree, but that is not a concern or responsibility for the Home Assistant integration. So you are barking against the wrong tree here.

[wishie]

I get that the problem mentioned might be outside the scope of Home Assistant, but surely the HA devs have some channel of communication with the Tuya devs.

Having things this broken can't be seen as a good thing by HA or Tuya.

Without trying to sound rude, the way it stands is:

HA says its Tuya's problem. Tuya says its the device manufacturers problem. But at the end of the day, its the end users who end up with the problem of their equipment not working.

What I am trying to do here (and im sure the other commenters are) is open a dialog between all involved parties to get this problem sorted out. As of now, we know of a couple of mentioned devices that do not work as expected, and this number will very likely grow, as more devices are made in the future.

[frenck]

@wishie You are barking against the wrong tree, as I stated before. Home Assistant is a consumer as well, we cannot make data up.

The new diagnostics download in Home Assistant was added to be able to address and pinpoint issues by showing exactly what informations was received from the Tuya API. We can't change that.

That is pretty much the end answer. I agree it is frustrating, but I do not own a magic wand.

Therefore, this you are trying to make a point in the wrong place and wasting your energy

[wishie]

@frenck Please dont think I'm attacking you, or Home Assistant in any way. I have an open ticket with Tuya and I am trying to work out a way that the involved parties can come up with a solution to a problem.

[frenck]

@wishie I am not seeing it as an attack, but we are sitting here with our hands tied too 🤷

[wishie]

Do you want me to post any updates here from the Tuya devs?

They have just said the following:

thank you for waiting,After some processing，At present, there are two values ​​can be seen on HA, namely sleep and nature, because the standard data point supports normal, nature, and sleep, the standard instruction set used to be {"nature","sleep","fresh"," smart","strong","closed"}, only sleep and nature are in standard data point，You can refer to the attached screenshot

[wishie]

They have indeed made a change so that only 'nature' and 'sleep' presets are listed/available for this device.. so it seems they can override what the manufacturer specifies. They also made 'oscillate' work, although it's a bit buggy currently.. but it seems we are getting somewhere, slowly.