Connection to device succeeded but no datapoints found, please try again.

[milandzuris]

The problem

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

This error originated from a custom integration.

Logger: custom_components.localtuya.pytuya
Source: custom_components/localtuya/pytuya/init.py:259
Integration: LocalTuya (documentation, issues)
First occurred: 21:58:29 (5 occurrences)
Last logged: 22:02:00

[bf4...igc] Failed to get status:
[bf5...nqh] 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

Environment

core 9.0.4
tuya newest

[SergeantPup]

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.

[kevvar]

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

[azsak79]

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

[milandzuris]

please fix this

[Odinlistening]

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.

[kevvar]

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

[SergeantPup]

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.

[kevvar]

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

[SergeantPup]

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

[kevvar]

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

[SergeantPup]

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.

[kevvar]

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

[SergeantPup]

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.

[kevvar]

Thanks bro @SergeantPup I'll try your advice

[matteoopc]

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?

[CyanoFresh]

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

[kevvar]

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

[milandzuris]

@rospogrigio

[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?

[CyanoFresh]

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

[milandzuris]

is hard make local tuya for 3.4 protocol? @rospogrigio

[redlingg]

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... :(

[matteoopc]

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.

[derkrasseleo]

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

[iosoft]

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

[derkrasseleo]

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

[rospogrigio]

@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

[sibowler]

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?

[pillemats]

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 ?

[wjr90]

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.

[kimme1024]

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?

[smithbill17]

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.

[kimme1024]

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.

[Crapy]

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?

[sibowler]

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.

[Justalurker1213]

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

[LigerXT5]

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.

[srtxema]

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

[koger23]

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.

[proligde]

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...

[milandzuris]

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

[grishagin]

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

[grishagin]

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.

[grishagin]

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!

[davidchezmoa]

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.

[DirkV71]

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

[lennon101]

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

[mastervol]

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.

[Zebulon25]

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"
}

[NAM1025]

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

[msrost]

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.

[NAM1025]

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

[zd3sf]

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).

[msrost]

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.

[dombrowa]

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.

Life saver! It took me days to find this post. I had two devices, both worked, one morning one dropped off. I restarted, reconfigured, deleted it from the app/cloud, tried what-ever, reinstalled HASS and now I ran tuya-cli wizard to find out that the device's localkey changed.
The message
"Error when adding in Local Tuya
Connection to device succeeded but no datapoints found, please try again. Create a new issue and include debug logs if problem persists.
"
apparently indicates that the device/endpoint is found (local tuya can find this IP and likely connect to ist servce) but not necessarily query the device because it needs a valid key to authenticate any request.
The error message is not clear IMHO.

[erdnuesse]

For me this message went away with different firmwares. I have 2 sets of 4 sockets; the first set wants 3.1, the other 3.3.
I've also realized that my connection is most stable when the init value is set with -1 and the scan interval of 10, because my setup is without cloud / internet connectivity and so the devices stay pretty much connected all the time.
Furthermore, when something breaks, for me, reconnecting with a fresh integration setup works better than trying to fix something that's broken. (be sure to have documented your IPs, IDs and keys!)
My VLAN Setup has the IOT in one subnet, pinholed through a fw-rule that allows my fixed IP-HASSIO to connect to the fixed IP addresses of the IOT devices.

[RetroDiesel]

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!

This fixed it for me. I'd just been trying to add a brand new light so when I saw it could be to do with a newer protocol version than LocalTuya was incapable of supporting I felt this was the reason. And it was. Installed the HACS integration, restarted HA and added the light with no issues.

[wosym]

Same issue here.

I have 4 devices that I was succesfully able to add and use in localTuya last year. They are 4 identical devices, bought at the same time. Same brand, same model. When I try to add them now, only one gets autodetected and works. another gets autodetected, but has the datapoints error. The two others are not autodetected and also get the datapoints error when manually added.

They respond to ping, so they're definitely there. I double checked their local keys through the Android Emulator trick, and they're still correct. So not sure what else could be going wrong...

I also tried deleting localtuya and starting from scratch: no luck.
I tried removing occurences of the respective deviceID's in the HA config files, still no luck.
I tried the fork of localtuya, same error.

No idea what else I can try here.

EDIT: a 5th device (different brand and model this time) appears to have the exact same issue. So for some reason, only 1 device works?

EDIT2: Now this is getting interesting... When I use the example script on the TinyTuya page, I can get data for a broken device, but not for the working device?! When using the scan command of that same tool, I also get a hit for the broken device, but not for the working one. Peculiar... very peculiar...