I have the same issue. it's recent because my older local tuya setup (with the most recent version) is supporting a light that I can't get loaded into a new instance of local tuya.

Same issue here, adding devices in a clean install

Logger: custom_components.localtuya.pytuya
Source: custom_components/localtuya/pytuya/__init__.py:259
Integration: LocalTuya integration ([documentation](https://github.com/rospogrigio/localtuya/), [issues](https://github.com/rospogrigio/localtuya/issues))
First occurred: 10:09:16 p. m. (2 occurrences)
Last logged: 10:12:10 p. m.

[bf9...7oy] Failed to get status:
Traceback (most recent call last):
  File "/usr/local/lib/python3.10/asyncio/locks.py", line 390, in acquire
    await fut
asyncio.exceptions.CancelledError

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/local/lib/python3.10/asyncio/tasks.py", line 456, in wait_for
    return fut.result()
asyncio.exceptions.CancelledError

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/config/custom_components/localtuya/pytuya/__init__.py", line 574, in detect_available_dps
    data = await self.status()
  File "/config/custom_components/localtuya/pytuya/__init__.py", line 507, in status
    status = await self.exchange(STATUS)
  File "/config/custom_components/localtuya/pytuya/__init__.py", line 486, in exchange
    msg = await self.dispatcher.wait_for(seqno)
  File "/config/custom_components/localtuya/pytuya/__init__.py", line 259, in wait_for
    await asyncio.wait_for(self.listeners[seqno].acquire(), timeout=timeout)
  File "/usr/local/lib/python3.10/asyncio/tasks.py", line 458, in wait_for
    raise exceptions.TimeoutError() from exc
asyncio.exceptions.TimeoutError

same error

Logger: custom_components.localtuya.pytuya
Source: custom_components/localtuya/pytuya/init.py:259
Integration: LocalTuya integration (documentation, issues)
First occurred: 2022. szeptember 22. 19:54:40 (6 occurrences)
Last logged: 07:37:42

[202...4dd] Failed to get status:
Traceback (most recent call last):
File "/usr/local/lib/python3.10/asyncio/locks.py", line 390, in acquire
await fut
asyncio.exceptions.CancelledError

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
File "/usr/local/lib/python3.10/asyncio/tasks.py", line 456, in wait_for
return fut.result()
asyncio.exceptions.CancelledError

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
File "/config/custom_components/localtuya/pytuya/init.py", line 574, in detect_available_dps
data = await self.status()
File "/config/custom_components/localtuya/pytuya/init.py", line 507, in status
status = await self.exchange(STATUS)
File "/config/custom_components/localtuya/pytuya/init.py", line 486, in exchange
msg = await self.dispatcher.wait_for(seqno)
File "/config/custom_components/localtuya/pytuya/init.py", line 259, in wait_for
await asyncio.wait_for(self.listeners[seqno].acquire(), timeout=timeout)
File "/usr/local/lib/python3.10/asyncio/tasks.py", line 458, in wait_for
raise exceptions.TimeoutError() from exc
asyncio.exceptions.TimeoutError

please fix this

Amendment:
Worked round by setting DPIDs. All good after that.

Original:
Precisely the same issue here. No issues previously - a fix would be great as just bought a load of new sockets, not foreseeing a problem.

Amendment: Worked round by setting DPIDs. All good after that.

How do you get that info and where to configure it?. I'm sorry I'm newby in this things
Thanks

Amendment: Worked round by setting DPIDs. All good after that.

How do you get that info and where to configure it?. I'm sorry I'm newby in this things Thanks

I managed to find the original instructions to get these into local tuya: https://community.home-assistant.io/t/tuya-local/237963/116 This contains the DPS information you need.

Go into local tuya, add a new device, fill in the name, and local key. In the second to last field, in manual DPS, enter a 1. Click submit and wait. When the box pops up, change it to light.

Now you have to fill in the DPS values. If you follow the DPS schema from the hyperlink above, the lights will work. I just did this for two separate lights and I have them in now.

@SergeantPup Thanks bro, but my device is a switch like this one I'll keep trying combinations

Then this should be even easier. Put in a manual dps of 1, submit, wait, select the platform as switch, make the ID 1, then fill in the rest. Do you need the tuya cross walk for DPSs? I found it in my searches yesterday and its how I found the settings for the lights

I think that device isn't compatible, I set the DPS as ID 1, and select switch but localtuya doesn't bring back the correct DPS state (I have all of them), I mean just show me "-1" value instead "0, 1, 2" as relay status and other values. The reason I think is not compatible is because the DPS names in my device doesn't match on any devices provided by local tuya

I ran into that a few times too. I think it has to do with removing the device and trying to readd it without a restart. I got that on both of my lights that I got working last night but every time I did a restart, I saw the actual DPS settings in local tuya and got them saved and working.

@SergeantPup when you say restart, do you mean restart all the home assistant instance?

Yes because if you just try to reload local tuya, it will tell you you need a restart to finish the application reload process. After I restarted, when I added the lights, it wash showing me the correct corresponding dps values for the devices.

Thanks bro @SergeantPup I'll try your advice

I ran into that a few times too. I think it has to do with removing the device and trying to readd it without a restart. I got that on both of my lights that I got working last night but every time I did a restart, I saw the actual DPS settings in local tuya and got them saved and working.

So to add the device do I have to delete it, reboot and try to add it again?

Have the same issue with this mini switch.

Tried:

1. Add device manually, enter all details + DPS with value 1. Result: it adds a switch but status is unavailable
2. Add device with DPS = 1, remove device, add this device again with DPS = 1. Result: same as before
3. Add device with DPS = 1, remove device, add this device again without DPS. Result: Connection to device succeeded but no datapoints found, please try again.

Does anyone have solution? Normal tuya integration is working fine

That's mine too, I've couldn't find a solution yet. I'm searching for it

@rospogrigio

I really don't know how to help guys, I'm sorry... Maybe this device is using a newer protocol like 3.4 instead of 3.3? It's hard to debug without owning the device. Did you try the tuyadebug script you find in the tools folder?

I really don't know how to help guys, I'm sorry... Maybe this device is using a newer protocol like 3.4 instead of 3.3? It's hard to debug without owning the device. Did you try the tuyadebug script you find in the tools folder?

Can you please give a step-by-step guide? Or a similar instruction. I've just started with tuya and have little expertise with it

is hard make local tuya for 3.4 protocol? @rospogrigio

Why the hell was this DP introduced. Everthing was ok until this.. Some devices can be added others no. Then the local tuya integration becomes unavailable. When I restart HA, the integration comes back but some devices are still in zombie mode... :(

I have found the problem for my devices; in practice, once installed it asks me to update it, if I don't do it it works otherwise there is no way to make it go! moreover I add it without adding any number.

I am also experiencing this issue with an Wifi LED Controller (Hama) is there any progress on this?

#595 #196 #194 #979 all seem to be related to this issue

My Error Log -

Logger: custom_components.localtuya.pytuya
Source: custom_components/localtuya/pytuya/init.py:259
Integration: LocalTuya (documentation, issues)
First occurred: 1:11:40 PM (8 occurrences)
Last logged: 1:35:29 PM

[d78...jry] Failed to get status:
Traceback (most recent call last):
File "/usr/local/lib/python3.10/asyncio/locks.py", line 390, in acquire
await fut
asyncio.exceptions.CancelledError

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
File "/usr/local/lib/python3.10/asyncio/tasks.py", line 456, in wait_for
return fut.result()
asyncio.exceptions.CancelledError

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
File "/config/custom_components/localtuya/pytuya/init.py", line 574, in detect_available_dps
data = await self.status()
File "/config/custom_components/localtuya/pytuya/init.py", line 507, in status
status = await self.exchange(STATUS)
File "/config/custom_components/localtuya/pytuya/init.py", line 486, in exchange
msg = await self.dispatcher.wait_for(seqno)
File "/config/custom_components/localtuya/pytuya/init.py", line 259, in wait_for
await asyncio.wait_for(self.listeners[seqno].acquire(), timeout=timeout)
File "/usr/local/lib/python3.10/asyncio/tasks.py", line 458, in wait_for
raise exceptions.TimeoutError() from exc
asyncio.exceptions.TimeoutError

Is there something we as users can do to help solve this issue?

@sibowler can you please try to provide some support? I suspect this is something that originated after we merged PR #956. Can you please check? Thank you

Hi all - if it's related to #956, can you try the fixes in PR #1022 to see if that changes anything?

In theory the changes introduced in #956 shouldn't impact the default detect_available_dps routine. What the change added was a retry with a RESET in between if no DPS were detected.

There seem to be a few different issues raised in this thread, so hard to know if they're all related. If i focus on just the folks who are having the error @milandzuris , @iosoft , @azsak79 , @kevvar - Do you find that these devices work fine on V4.0 of localtuya?

I have 3 pieces of LED controllers Mi Boxer FUT036W. All 3 were fine for a while, once 2 of 3 went offline, also lost WiFi, so I had to setup them again through Tuya Smart app. They did not work in HA after reconfiguration, so I deleted the non-working ones and keep trying to add them after each update.

When adding them I get the same error message "Connection to device succeeded but no datapoints found, please try again. Create a new issue and include debug logs if problem persists.".

At the moment everything is up-to-date, also tried with protocol 3.4 (but their version is 3.3).

I will try to debug this, I have to learn the how. All I see so far:

Anyway, there is another issue created with the same topic: #983

Update-1:

Noticed that all 3 is MiBoxer FUT036W, but product keys are the same for two which do not work according to the discovery logs:

• (1) working: yfhxw2yk6kyhs9rp

  • Wi-Fi module: v2.0.2
  • MCU module: v1.0.0

• (2) non-working: z5qoiz8vr18em3le

  • Wi-Fi module: v2.1.6
  • MCU module: v1.0.0
    No updates available for the devices.

Also log after trying to add new device:

After Enabling debug:

This error originated from a custom integration.

Logger: custom_components.localtuya.pytuya
Source: custom_components/localtuya/pytuya/__init__.py:450
Integration: LocalTuya (documentation, issues)
First occurred: 7:33:19 AM (1 occurrences)
Last logged: 7:33:19 AM

[bf7...tyj] Failed to get status:
Traceback (most recent call last):
  File "/usr/local/lib/python3.10/asyncio/locks.py", line 390, in acquire
    await fut
asyncio.exceptions.CancelledError

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/local/lib/python3.10/asyncio/tasks.py", line 456, in wait_for
    return fut.result()
asyncio.exceptions.CancelledError

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/config/custom_components/localtuya/pytuya/__init__.py", line 857, in detect_available_dps
    data = await self.status()
  File "/config/custom_components/localtuya/pytuya/__init__.py", line 789, in status
    status = await self.exchange(DP_QUERY)
  File "/config/custom_components/localtuya/pytuya/__init__.py", line 763, in exchange
    msg = await self.dispatcher.wait_for(seqno, payload.cmd)
  File "/config/custom_components/localtuya/pytuya/__init__.py", line 450, in wait_for
    await asyncio.wait_for(self.listeners[seqno].acquire(), timeout=timeout)
  File "/usr/local/lib/python3.10/asyncio/tasks.py", line 458, in wait_for
    raise exceptions.TimeoutError() from exc
asyncio.exceptions.TimeoutError

I tried again with adding DPS manually, first only with 20 as switch, then 20,22 as light, but does nto work. Entities are unavailable, so not "clickable".
Currently the my tuya smart account is unlinked with iot platform and I use mobile Tuya Smart app for managing the controllers.

I don't know if it helps, but I keep trying to control my LED controllers with Node-RED and Python locally.
In both cases the problem is that the LED controllers returns unexpected payload. Probably encoded, looks like encoded stuff.

I tried several libraries to try to communicate with my LED controllers, but no success. It seems it returns encoded payload, which cannot be handled by any libs I tried.

For example: this is returned by the example code with tuyaAPI (JS):

I also tried TuyaFace and localtuya (which uses pytuya), but no break through.

Any idea what else could I try?

(there is another thead on this issue for tuyapi: codetheweb/tuyapi#612)

Hello, I'am a newby. I testing load a tuya zigbee gateway device in local tuya. But I cannot success. I never find the itemize of gateway. Please help me.

#cannot find gateway in itemize

config_entry-localtuya-6457b81655481748478db10edf130758.json.txt

Try to set your Home Assistant network to static and fill your network configuration then save.
I fix this problem with that way...

Hey

Same issue here with

LSC Party Stringlight RGBIC+WW(15 Bulbs)

"Connection to device succeeded but no datapoints found, please try again. Create a new issue and include debug logs if problem persists."

what can i do ?

Hey guys. After I spent many hours to solve this problem a few days ago, I found that in my case it was quite simple:

The localkey attribute of just one of my Tuya devices is VARIABLE. Every time the power goes out the key changes and I need to discover it again and update the device in the LocalTuya extension.

It was allowed to put the previous localkey, there was no connection failure, it showed this message "Connection to device succeeded but no datapoints found, please try again" but in fact the value of the localkey was already different.

I hope this can help someone.

Hi All,

I'm having the weird issue that 1 of my in wall mini switches stopped working. All other 3 don't have any issues. I can control the switch via the SmartLife app.

I tried:

• Restart HA
• Update localtuya to latest version
• Changing from 3.4 tot 3.3 and 3.1
• Removing - adding (with 1 in DPS), it ads the switch as it should but it's unavailable immediately.
• Reconfigure the complete localtuya integration, all devices add seamlessly, except for the one that's not working

Any ideas?

Check the versions of firmware on your working & non-working devices.

I found when I set up a 2nd Home Assistant using LocalTuya, that when I tried to add my SmartPlugs to the 2nd LocalTuya, I kept getting "no datapoints found" and so couldn't add it. If I 'restart' the 1st HomeAssistant, then while it's starting up, I can then add my SmartPlugs to the 2nd Home Assistant LocalTuya integration.

However, on SmartPlugs with older firmware, they couldn't be functional in BOTH LocalTuya's - one is greyed-out & one works. Restart the HomeAssistant with the working SmartPlugs and suddenly the greyed-out SmartPlugs in the other HomeAssistant spring to life. But this only happens with SmartPlugs with older non-upgradable firmware.

Try using the 'official' Tuya integration rather than LocalTuya.

Check the versions of firmware on your working & non-working devices.

I found when I set up a 2nd Home Assistant using LocalTuya, that when I tried to add my SmartPlugs to the 2nd LocalTuya, I kept getting "no datapoints found" and so couldn't add it. If I 'restart' the 1st HomeAssistant, then while it's starting up, I can then add my SmartPlugs to the 2nd Home Assistant LocalTuya integration.

However, on SmartPlugs with older firmware, they couldn't be functional in BOTH LocalTuya's - one is greyed-out & one works. Restart the HomeAssistant with the working SmartPlugs and suddenly the greyed-out SmartPlugs in the other HomeAssistant spring to life. But this only happens with SmartPlugs with older non-upgradable firmware.

Try using the 'official' Tuya integration rather than LocalTuya.

• all versions are on 3.4
• it has been working for months, it only stopped working recently, however I don't know when as I don't use that switch very often.
• official tuya isn't an option as I try to rely on local connections only for my smarthome and that some of the tuya devices only work with localtuya.

I get that issue when blocking the device from the internet and trying to keep it only local and restarting it, is there no way to restart devices without internet connection when using localtuya?

Hi @Crapy - No in most instances you shouldn't need to have your devices connected to the internet to have them work. Often you need to specify the DPIDs for your device in "DPIDs to send in RESET command" parameter - this often helps tuya devices 'wake up'. But for some of my devices I have found a few additional steps necessary to allow them to work offline:

1. Make sure that they are issued with an external DNS server via DHCP (i.e. 8.8.8.8) and then make sure connections to that server are blocked.
2. Specify the relevant DPIDs in the RESET command - NOTE this is often not all the DPIDs, but usually the ones that don't come through unless connected to the internet. If you don't get this parameter right, the device will often stay in zombie mode. Also, this is often just DPIDs for sensors, not switches.
3. Specify a scan interval of 30 secs
4. Specify any remaining missing DPIDs as Manual ones - Some devices only return the DPID once it's been initialized.

The trick to telling whether a device can work offline/not connected to the internet, is by making it offline and then seeing if the Tuya app can connect/control it normally. I've got 1 device (a fan) that doesn't respond to the above technique, but even the Tuya app can't control it when offline.

Closing out of the Tuya app fixed this error for me. My light was not allowing 2 active connections at a time.

Chiming in with my 10cents.

Had a light that stopped responding to HA via LocalTuya. Removed, readding would fail. Novestella 1300Lumen RGB Lights. I haven't found ANY DPID info on these...

I finally got it added by (make sure it's removed from HA first) restart HA as restarting/reloading LocalTuya App doesn't resolve it, then add and it went through without errors.

I checked and confirmed through the Tuya app, the light in question and others are on the same version, and I can control it through Google and Tuya before I removed it from HA.

You won´t believe my solution.
After a lot of days losted and reading forums with "no datapoints found" problem, I have solve the problem only closing tuya and smartlife apps and after it adding normally to local tuya in HA

Lucky you :)

You won´t believe my solution. After a lot of days losted and reading forums with "no datapoints found" problem, I have solve the problem only closing tuya and smartlife apps and after it adding normally to local tuya in HA

Summary

During the last half year I read through your responses and tried some you wrote.
I can confirm that the local key changes time-to-time, probably after each blackouts. I have the 4th version/change, and I can add to HA without any problems. I always have to re-register to Tuya IoT Platform with an IoT Core trial subscription and read the local keys every time and update in HA.
(There is also a wierd thing that one of my controller has two presence on the network with two different device ids.)

Conclusion

So unfortunately this is the case for me. If it is broken, check local key on Tuya IoT dev platform again and update it. I hope there will be a solution for this in the future because I cannot use UPS for each controllers...

How to for new comers

1. You need to register on Tuya IoT platform

2. Link your mobile app to the platform

3. Link your devices: Cloud > Development > Devices > Link Tuya App Account

4. Note your device IDs after successful linking app and automatically the devices
   

5. Go to "Cloud > API Explorer > Device Control > Query Properties" and submit by the device IDs.
   

6. Note your local keys from the JSON result array. (result.local_key)
   Now you can add them to HA one-by-one.

Additionally you can also get your device DP values to help to set the values in HA:
"Cloud > API Explorer > Device Management > Query Device Details in Bulk".
It also returns a JSON object.

Hi there! I just stumbled across this issue and at least in my case it seemed to be a race condition / timing issue. I had a bunch of different socket switches from different brands, all with tuya cloud integration. Two of them initially threw that Connection to device succeeded but no datapoints found, please try again. error message over and over again. While debugging the situation and retrying the same add-process multiple times, it suddenly just worked without changing anything. So before diving too deep into a red herring debugging session: retry a few times...

If someone need Data Points for Setup here: https://github.com/DzurisHome/Tuya-Data-Points

Likewise, I have this issue with Lumary Smart Disk Light B1.

1. None of them are detected automatically by Local Tuya.
2. When trying to add a light manually, I get the dreaded error
   Connection to device succeeded but no datapoints found, please try again. Create a new issue and include debug logs if problem persists.
3. When trying to add a light manually with DP IDs (discovered by tinytuya, confirmed via Tuya IoT cloud), I can add the device, but its values are all detected as -1 and the device is not controllable.
   Fun fact: tinytuya detects all devices and correct DPS states!
4. This issue was raised on the HA forum here: https://community.home-assistant.io/t/need-help-configuring-lumary-lights-with-local-tuya/616003/6

Likewise, I have this issue with Lumary Smart Disk Light B1.

1. None of them are detected automatically by Local Tuya.

2. When trying to add a light manually, I get the dreaded error
   `Connection to device succeeded but no datapoints found, please try again. Create a new issue and include debug logs if problem persists.`

3. When trying to add a light manually with DP IDs (discovered by `tinytuya`, confirmed via Tuya IoT cloud), I can add the device, but its values are all detected as `-1` and the device is not controllable.
   Fun fact: `tinytuya` detects all devices and correct DPS states!

4. This issue was raised on the HA forum here: https://community.home-assistant.io/t/need-help-configuring-lumary-lights-with-local-tuya/616003/6

I've noticed one more thing, which I believe is is the crux of the problem: these lights are on Version 3.5.
I have lights of different type, Lumary Smart Ceiling Light A2, which are detected. And guess what? Those are on Version 3.3.

Update: I found a solution that worked for me.
Some gigachad @umu_ugg on HA forum created a fork of this repo that supports protocol version 3.5.
It installed seamlessly on top of the original and immediately auto-detected all of my devices.
Hope it helps some of y'all!

I'm a newbie on HA and Tuya devices but I got the same issue here.
Also tried the suggession of @grishagin but no luck I got the same issue same logs

`2024-01-01 23:20:19.873 ERROR (MainThread) [custom_components.localtuya.core.pytuya] [bf9...vvt] Failed to get status:
Traceback (most recent call last):
File "/usr/lib/python3.11/asyncio/tasks.py", line 490, in wait_for
return fut.result()
^^^^^^^^^^^^
File "/usr/lib/python3.11/asyncio/locks.py", line 387, in acquire
await fut
asyncio.exceptions.CancelledError

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
File "/root/.homeassistant/custom_components/localtuya/core/pytuya/init.py", line 1091, in detect_available_dps
data = await self.status(cid=cid)
^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/root/.homeassistant/custom_components/localtuya/core/pytuya/init.py", line 1010, in status
status: dict = await self.exchange(command=DP_QUERY, nodeID=cid)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/root/.homeassistant/custom_components/localtuya/core/pytuya/init.py", line 984, in exchange
msg = await self.dispatcher.wait_for(seqno, payload.cmd)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/root/.homeassistant/custom_components/localtuya/core/pytuya/init.py", line 607, in wait_for
await asyncio.wait_for(self.listeners[seqno].acquire(), timeout=timeout)
File "/usr/lib/python3.11/asyncio/tasks.py", line 492, in wait_for
raise exceptions.TimeoutError() from exc
TimeoutError`

My device I tried to connect is a RGB light bulb.

You can also determine your data points yourself and then add the device manually:

https://www.zigbee2mqtt.io/advanced/support-new-devices/03_find_tuya_data_points.html#_4-create-a-cloud-project

I think it has to do with removing the device and trying to readd it without a restart.

THIS! this was the fix for me! RESTART YOUR HA INSTANCE if you have recently removed a local tuya device and then tried to add it again

Check the versions of firmware on your working & non-working devices.

I found when I set up a 2nd Home Assistant using LocalTuya, that when I tried to add my SmartPlugs to the 2nd LocalTuya, I kept getting "no datapoints found" and so couldn't add it. If I 'restart' the 1st HomeAssistant, then while it's starting up, I can then add my SmartPlugs to the 2nd Home Assistant LocalTuya integration.

However, on SmartPlugs with older firmware, they couldn't be functional in BOTH LocalTuya's - one is greyed-out & one works. Restart the HomeAssistant with the working SmartPlugs and suddenly the greyed-out SmartPlugs in the other HomeAssistant spring to life. But this only happens with SmartPlugs with older non-upgradable firmware.

Try using the 'official' Tuya integration rather than LocalTuya.

Thanks for the tip.
I had the same problem, restarting the first home assistant instance and trying on the second instance of home assistant worked eventually. I was using 2 x hama wlan led ceiling lights.

Hi everyone,

I've the same message when I try to connect my LVWIT bulbs when I can connect without issue others devices (smart plugs, cats smart food feeders...).

When I've a look on the parameters returned by Tuya IoT Platform to find the local key, I can see that for the accepded devices, the local key is always alpanumerical when the rejected devices have a alphanumerical + special characteres keys.
Could the type of key the root cause of rejected devices; Have someone be able to register devices wheit non alphanumerical key ?

Device working without issue (I've anonymized some parameters with "X"):
{
"result": {
"active_time": 1670225425,
"bind_space_id": "48039705",
"category": "kg",
"create_time": 1670225425,
"custom_name": "bureau 1 (accessoires)",
"icon": "smart/icon/1511353484_0.png",
"id": "82134464c45bXXXXXXXX",
"ip": "XXX.XXX.XXX.XXX",
"is_online": true,
"lat": "XX.0700",
"local_key": "16e3cbb6b6078e4d",
"lon": "XX.0800",
"model": "科信嘉联KS-501",
"name": "KS-501 2",
"product_id": "zY4uzKMEXXXXXXXX",
"product_name": "KS-501",
"sub": false,
"time_zone": "+01:00",
"update_time": 1708879254,
"uuid": "82134464c45bXXXXXXXX*"
},
"success": true,
"t": 1708933067665,
"tid": "efe7edb5d47911eea4757adeXXXXXXXX"
}

My LVWIT bulb I cannot register:
{
"result": {
"active_time": 1684318185,
"bind_space_id": "48039705",
"category": "dj",
"create_time": 1684318185,
"custom_name": "LVWIT Smart Light basse",
"icon": "smart/icon/bay1581669037386oc3n/3f260aee68825ed0635a56b1ccecb1c5.png",
"id": "bfb27d476dadd0XXXXXXXX",
"ip": "XXX.XXX.XXX.XXX",
"is_online": true,
"lat": "XX.0661",
"local_key": "$pNkh>OuZg3v[+<}",
"lon": "XX.0773",
"model": "G45-2 WIFI DIM+CCT+RGB 5W E14 X-Y",
"name": "LVWIT Smart Light",
"product_id": "wwnbjdjbXXXXXXXX",
"product_name": "LVWIT Smart Light",
"sub": false,
"time_zone": "+02:00",
"update_time": 1708931199,
"uuid": "35c46d0dXXXXXXXX"
},
"success": true,
"t": 1708932670673,
"tid": "03475f87d47911eea4757adeXXXXXXXX"
}

What worked for me was factory resetting the device, setting it up again in the Smart Life (or the Tuya app), and then adding it to local tuya.

I factory reset it through the Tuya IoT Platform, not sure if that matters

I'm having the same issue with 1 of 4 of my Treatlife Fan control switches. I have to use the local tuya to control in home assistant as the standard tuya integration does not allow control of both the fan speed and the light / dimmer in the same device. It was working and then for some reason got the ? on the icon in my dashboard and the fix in the past was to remove the device and add it back in. In doing so, i now get this error:

Connection to device succeeded but no datapoints found, please try again. Create a new issue and include debug logs if problem persists.

For some reason it's trying to run on 3.4 version. I'm not sure why the integration asks me what version of the protocol to use as anytime i try to change it, it goes back to 3.4. The device works fine in the SmartLife app but I want it to work in home assistant like it used to along with the other 3 that i have setup and working. This post is from 2022 and it's not 2024 and i'm surprised this is still an issue.

I'm having the same issue with 1 of 4 of my Treatlife Fan control switches. I have to use the local tuya to control in home assistant as the standard tuya integration does not allow control of both the fan speed and the light / dimmer in the same device. It was working and then for some reason got the ? on the icon in my dashboard and the fix in the past was to remove the device and add it back in. In doing so, i now get this error:

Connection to device succeeded but no datapoints found, please try again. Create a new issue and include debug logs if problem persists.

For some reason it's trying to run on 3.4 version. I'm not sure why the integration asks me what version of the protocol to use as anytime i try to change it, it goes back to 3.4. The device works fine in the SmartLife app but I want it to work in home assistant like it used to along with the other 3 that i have setup and working. This post is from 2022 and it's not 2024 and i'm surprised this is still an issue.

Here's my experience/what I think is happening...

While adding a new device I had to disable my firewall rule that blocks my VLAN with all of my light switches from accessing the internet. It seems that any device that I setup 6 months - 1 year ago all of a sudden stopped working in Home Assistant. I needed to remove them from the Smart Life App, re-add it, and then go through the regular setup steps using the dev cloud (grabbing the new device id, local key, etc.)

I think either...

1. When a device is disconnected from the cloud for X amount of time, and then reconnects, it gives it new/updated "credentials".
2. They are intentionally updating device id and local key every so often so that you are encouraged to use their cloud services
3. All of the above

Hi @Crapy - No in most instances you shouldn't need to have your devices connected to the internet to have them work. Often you need to specify the DPIDs for your device in "DPIDs to send in RESET command" parameter - this often helps tuya devices 'wake up'. But for some of my devices I have found a few additional steps necessary to allow them to work offline:

1. Make sure that they are issued with an external DNS server via DHCP (i.e. 8.8.8.8) and then make sure connections to that server are blocked.
2. Specify the relevant DPIDs in the RESET command - NOTE this is often not all the DPIDs, but usually the ones that don't come through unless connected to the internet. If you don't get this parameter right, the device will often stay in zombie mode. Also, this is often just DPIDs for sensors, not switches.
3. Specify a scan interval of 30 secs
4. Specify any remaining missing DPIDs as Manual ones - Some devices only return the DPID once it's been initialized.

The trick to telling whether a device can work offline/not connected to the internet, is by making it offline and then seeing if the Tuya app can connect/control it normally. I've got 1 device (a fan) that doesn't respond to the above technique, but even the Tuya app can't control it when offline.

Yes #2 actually worked for me. My Cree 60W tuya lights will be in zombie mode (router wan block + adguarghome DNS block), only when is set the DPID in RESET to DPID 27 or DPID 26 (i havent tried others, these worked right away).

This is absolutely infuriating. I can't control the fan speed and light through the tuya integration and I can't keep this one switch paired with the localtuya integration. I just keeps dropping off randomly and won't pair again. Sometimes it will repair if I go for days without it integrated with home assistant.

It stays connected to the smart life app and just keeps working there.

When I try to add it to home assistant I keep getting this message:

Connection to device succeeded but no datapoints found, please try again. Create a new issue and include debug logs if problem persists.

I then went to iot.tuya.com and ran the Query Properties on the device ID and got the following response:

{
  "result": {
    "properties": [
      {
        "code": "switch_fan",
        "custom_name": "",
        "dp_id": 1,
        "time": 1713399786405,
        "value": false
      },
      {
        "code": "fan_speed_enum",
        "custom_name": "",
        "dp_id": 3,
        "time": 1713399786411,
        "value": "1"
      },
      {
        "code": "bright_value",
        "custom_name": "",
        "dp_id": 6,
        "time": 1713399786451,
        "value": 100
      },
      {
        "code": "light",
        "custom_name": "",
        "dp_id": 101,
        "time": 1713399786402,
        "value": false
      },
      {
        "code": "fan_countdown",
        "custom_name": "",
        "dp_id": 102,
        "time": 1711824956212,
        "value": 0
      },
      {
        "code": "light_count_down",
        "custom_name": "",
        "dp_id": 103,
        "time": 1711824956212,
        "value": 0
      },
      {
        "code": "lowest_brightness",
        "custom_name": "",
        "dp_id": 105,
        "time": 1713399786308,
        "value": 100
      },
      {
        "code": "light_mode1",
        "custom_name": "",
        "dp_id": 106,
        "time": 1713399786426,
        "value": "mode1"
      },
      {
        "code": "wake_up",
        "custom_name": "",
        "dp_id": 107,
        "time": 1713399786463,
        "value": "AAA="
      },
      {
        "code": "indicator",
        "custom_name": "",
        "dp_id": 108,
        "time": 1713399786438,
        "value": 1
      },
      {
        "code": "random_time",
        "custom_name": "",
        "dp_id": 109,
        "time": 1713399786643,
        "value": "BgAAAA=="
      }
    ]
  },
  "success": true,
  "t": 1713399973395,
  "tid": "4330ec23fd1a11eead6aba50e5db0ba5"
}

I know the fan switch is 1, the fan speed is 3, the light switch is 101 and the light brightness is 6. I put those into the Manual DPS to add (separated by commas ',') - used when detection is not working and that didn't help.

I don't know what DPIDs to send in RESET command are, but I tried 107. Then I tried 1,3,6,101,107 and neither one did anything. The device is just not responding. Then I remove the device from Smart Life app, and re-add it back to my account and everything is working fine in Smart Life, but still can't query or control via home assistant. What do I need to do to get this thing to stay connected to my home assistant instance? I'm about ready to throw all the tuya stuff in the trash.