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

juan11perez commented 1 year ago

The problem

Environment

Localtuya version: 4.1
Last working localtuya version (if known and relevant):
Home Assistant Core version: 2022.11.5
[] Are you using the Home Assistant Tuya Cloud component ?
[] Are you using the Tuya App in parallel ?

` 2022-11-26 18:27:55.826 DEBUG (MainThread) [custom_components.localtuya.discovery] Listening to broadcasts on UDP port 6666 and 6667 2022-11-26 18:27:57.654 INFO (MainThread) [custom_components.localtuya] Cloud API connection succeeded. 2022-11-26 18:29:57.320 DEBUG (MainThread) [custom_components.localtuya.pytuya] [bf5...ybq] Sending command status (device type: type_0a) 2022-11-26 18:29:57.320 DEBUG (MainThread) [custom_components.localtuya.pytuya] [bf5...ybq] Send payload: b'{"gwId":"bf56484dcc48c22693eybq","devId":"bf56484dcc48c22693eybq"}' 2022-11-26 18:29:57.321 DEBUG (MainThread) [custom_components.localtuya.pytuya] [bf5...ybq] Waiting for sequence number 0 2022-11-26 18:29:57.328 DEBUG (MainThread) [custom_components.localtuya.pytuya] [bf5...ybq] Connection lost: None 2022-11-26 18:30:02.321 ERROR (MainThread) [custom_components.localtuya.pytuya] [bf5...ybq] 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 2022-11-26 18:30:02.325 DEBUG (MainThread) [custom_components.localtuya.config_flow] Initial state update failed, trying reset command 2022-11-26 18:30:02.325 DEBUG (MainThread) [custom_components.localtuya.config_flow] No DPS able to be detected 2022-11-26 18:30:02.325 DEBUG (MainThread) [custom_components.localtuya.config_flow] Detected DPS: {} 2022-11-26 18:30:02.325 DEBUG (MainThread) [custom_components.localtuya.pytuya] [bf5...ybq] Closing connection`

pickonedev commented 1 year ago

I had 10 devices working in localtuya, I made a firmware update to all the devices, then all 10 devices stopped working.. I have deleted/wiped all the devices from Tuya app, I add them back again (local key was changed), still nothing... When I try to add a device, I get the same error as your title.

PS: when I try to add a device, the protocol version it is not detected anymore. PS2: I tried to add other devices, not from those 10 which have a new firmware and I still get the same error...

This is what I see in the logs


Source: custom_components/localtuya/pytuya/__init__.py:259
Integration: LocalTuya ([documentation](https://github.com/rospogrigio/localtuya/), [issues](https://github.com/rospogrigio/localtuya/issues))
First occurred: 17:44:09 (2 occurrences)
Last logged: 17:45:09

    [bf6...llh] Failed to get status:
    [bfb...3oc] 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```

juan11perez commented 1 year ago

A litttle more information. Watching this video i found out the DPID for my light. I added the numbers in the "manual dps" section and the config flow completed adding the entity. But the entity does nothing. Toggling the switch has no effect

pickonedev commented 1 year ago

@rospogrigio Any advice/workaround, please?

plandregan commented 1 year ago

I have the same with some DIN Rail switches. Was fine till TUYA updated the firmware to 1.0.9.

If I try and remove the device, by editing and unticking the tick at the bottom, so to remove it. It gives an unknown error DPs of a working one at 1.0.6 and non working at 1.0.9 are the same. In these logs Cooker works, ASHP was updated and no longer works They are both pingable on the network, both have port 6668 open Both work in the Tuya Smart App

home-assistant.log config_entry-localtuya-727b7c4d7c99c7f50fad85f17eb9c262.json.txt

pickonedev commented 1 year ago

I have the same with some DIN Rail switches. Was fine till TUYA updated the firmware to 1.0.9.

If I try and remove the device, by editing and unticking the tick at the bottom, so to remove it. It gives an unknown error DPs of a working one at 1.0.6 and non working at 1.0.9 are the same. In these logs Cooker works, ASHP was updated and no longer works They are both pingable on the network, both have port 6668 open Both work in the Tuya Smart App

home-assistant.log config_entry-localtuya-727b7c4d7c99c7f50fad85f17eb9c262.json.txt

I think we have the same devices... I done the same thing, after firmware update, I got problems. Now I regret the fact that I did not bought the ewelink version :-(

jlmpenedo commented 1 year ago

I have the same issue with a fairy led light

Este erro originou-se de uma integração personalizada.

Logger: custom_components.localtuya.common Source: custom_components/localtuya/pytuya/init.py:704 Integration: LocalTuya (documentation, issues) First occurred: 21:16:18 (11 occurrences) Last logged: 21:24:12

[eb6...hyp] Connect to 192.168.68.158 failed Traceback (most recent call last): File "/config/custom_components/localtuya/common.py", line 186, in _make_connection self._interface = await pytuya.connect( File "/config/customcomponents/localtuya/pytuya/init.py", line 704, in connect , protocol = await loop.create_connection( File "/usr/local/lib/python3.10/asyncio/base_events.py", line 1064, in create_connection raise exceptions[0] File "/usr/local/lib/python3.10/asyncio/base_events.py", line 1049, in create_connection sock = await self._connect_sock( File "/usr/local/lib/python3.10/asyncio/base_events.py", line 960, in _connect_sock await self.sock_connect(sock, address) File "/usr/local/lib/python3.10/asyncio/selector_events.py", line 500, in sock_connect return await fut File "/usr/local/lib/python3.10/asyncio/selector_events.py", line 535, in _sock_connect_cb raise OSError(err, f'Connect call failed {address}') OSError: [Errno 113] Connect call failed ('192.168.68.158', 6668)

MindFreeze commented 1 year ago

I have the same DIN rail switch. Checked the DPs from tuya cloud console and they seem to have shifted by 1 but even adding them manually doesn't help. Localtuya can't get any values from the device. Looks like we are on protocol 3.4 now and it isn't supported yet

MindFreeze commented 1 year ago

@pickonedev @plandregan After switching to a fork as explained here my switch works with the new DPs. Here are my DPs:

{
          "current": 18,
          "current_consumption": 19,
          "voltage": 20,
          "id": 1,
          "platform": "switch"
}

pickonedev commented 1 year ago

Niceee... I will try it right now. Thanks!

Edit: I get this error when I try to add a device...


Source: custom_components/localtuya/config_flow.py:246
Integration: LocalTuya ([documentation](https://github.com/rospogrigio/localtuya/), [issues](https://github.com/rospogrigio/localtuya/issues))
First occurred: 12:25:32 (1 occurrences)
Last logged: 12:25:32
Unexpected exception

Traceback (most recent call last):
  File "/config/custom_components/localtuya/config_flow.py", line 591, in async_step_configure_device
    self.dps_strings = await validate_input(self.hass, user_input)
  File "/config/custom_components/localtuya/config_flow.py", line 246, in validate_input
    module = import_module('custom_components.localtuya.tinytuya.tinytuya')
  File "/usr/local/lib/python3.10/importlib/__init__.py", line 126, in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
  File "<frozen importlib._bootstrap>", line 1050, in _gcd_import
  File "<frozen importlib._bootstrap>", line 1027, in _find_and_load
  File "<frozen importlib._bootstrap>", line 1004, in _find_and_load_unlocked
ModuleNotFoundError: No module named 'custom_components.localtuya.tinytuya.tinytuya'```

MindFreeze commented 1 year ago

I had to restart a few times. Once after overwriting the custom_component. Then maybe a second time. Then after adding/editing the switch. Haven't checked the log but after a few restarts, it works with the custom DPs. Even another different switch that I added a long time ago but didn't work, started working with this version without changing the config for it.

pickonedev commented 1 year ago

I needed to copy all the original tinytuya folder into the localtuya, now all good

plandregan commented 1 year ago

I have totally removed LocalTuya. Then try to reinstall 4.1.1 from scratch.

Now just get an error for invalid handler specified. Any ideas?

Removed LocalTuya from integrations. Then removed from HACS. Re downloaded. Rebooted HA Tried to add integration and get this error

On Wed, 30 Nov 2022, 11:49 pickonedev, @.***> wrote:

I needed to copy all the original tinytuya folder into the localtuya, now all good

— Reply to this email directly, view it on GitHub https://github.com/rospogrigio/localtuya/issues/1145#issuecomment-1332028854, or unsubscribe https://github.com/notifications/unsubscribe-auth/A2FHAFU7AFN3PFMRJF6KLLDWK45MRANCNFSM6AAAAAASMBCNXM . You are receiving this because you were mentioned.Message ID: @.***>

rospogrigio commented 1 year ago

Try to remove the localtuya config block from .storage/core.config_entries (make sure you keep a backup of that file because if you break the structure HA won't start any more).

plandregan commented 1 year ago

Worked.

Back up and running. Also now added the Porotocol 3.4 addon.

Till a genuine one is incorporated into your official branch.

On Wed, 30 Nov 2022, 12:46 rospogrigio, @.***> wrote:

Try to remove the localtuya config block from .storage/core.config_entries (make sure you keep a backup of that file because if you break the structure HA won't start any more).

— Reply to this email directly, view it on GitHub https://github.com/rospogrigio/localtuya/issues/1145#issuecomment-1332090870, or unsubscribe https://github.com/notifications/unsubscribe-auth/A2FHAFTXPUEQ7RIGSSHJHBDWK5EBRANCNFSM6AAAAAASMBCNXM . You are receiving this because you were mentioned.Message ID: @.***>

pickonedev commented 1 year ago

@plandregan , @MindFreeze , As you both have the same devices as me, have you ever encountered this problem? Maybe you have a solution as well? One of my devices it is not showing any value, it is connecting to the wifi, I can configure the device into HomeAssistant, but even in Tuya App, it is showing me 0 value for all the details. The switch it is working, but I get no value... At least, the "Voltage" should have something because the device it is working, it have electricity... See screenshot

plandregan commented 1 year ago

No. Mine even the updated ones work in Tuya. Always have.

Is your Tuya App upto date? Or is it the Smartlife one?

On Thu, 1 Dec 2022, 17:55 pickonedev, @.***> wrote:

@plandregan https://github.com/plandregan , @MindFreeze https://github.com/MindFreeze , As you both have the same devices as me, have you ever cnountered this problem? Maybe you have a solution as well? One of my devices it is not showing any value, it is connecting to the wifi, I can configure the device into HomeAssistant, but even in Tuya App, it is showing me 0 value for all the details. Like in the screenshot

[image: image] https://user-images.githubusercontent.com/34201387/205125511-d7b09662-3e7b-4bbd-acfd-5235484b21e2.png

— Reply to this email directly, view it on GitHub https://github.com/rospogrigio/localtuya/issues/1145#issuecomment-1334139150, or unsubscribe https://github.com/notifications/unsubscribe-auth/A2FHAFR6CYTBUH5MYUA6YJTWLDQ7ZANCNFSM6AAAAAASMBCNXM . You are receiving this because you were mentioned.Message ID: @.***>

JGrantman commented 1 year ago

Could there be an issue with the Tuya IoT platform? I logged into my Cloud Project and keep getting "server busy" pop-up when attempting to view devices then go to Link Tuya App Account and "Modify". I have 12 Energy Monitor plugs working OK but adding another it does not find DPS... even though exact same model as 2 others already working.

Was able to add device and manually specify DPS but no data pulled from devices (showing unavailable). Checking log started seeing errors about unknow DP1 for couple devices... a few Home Assistant restarts later and all 13 devices show up unavailable. Also growing number of timeout errors in log for same unavailable devices.

(The devices still work fine in Tuya Smart app - switch control and power monitor. Have tried Home Assistant with Tuya Smart running on phone and with Phone powered off so no chance of Tuya Smart in background.

What is really strange is I have 2 different cloud projects - 1 only tied to SmartLife app and 1 tied only to Tuya Smart app. SmartLife linked project - no issues (on Tuya IoT site). Tuya Smart linked project throwing pop-up "server busy" error on IoT site and localtuya lost all devices now all showing as unavailable.

I thought about testing more but not willing to screw with Smart Life linked project that is working fine on IoT site and in Home Assistant as I have almost 50 devices and it is WAY too tedious to re-setup.

I did open ticket with Tuya with full detail specific to the IoT site error... and hoping if it's fixed it will ultimately fix localtuya in Home Assistant.

I will provide update if Tuya answers ticket and solves error on IoT site -- and whether it in turn solves timeouts and unavalable devices with localtuya.

Grantman

zkvvoob commented 1 year ago

Just to chime in - I had two Meka Ambient lights working perfectly fine with localTuya up until 15 minutes ago. Then I had the stupid idea of opening the Smart Life app in order to change the colours/effects (which I've been unable to do through HA). A firmware updated began and before I could react, it had installed - Main Module/MCU 2.0.19 and now localTuya won't even find one of the lamps (the one that got the update - I'm not updating the other one!).

plandregan commented 1 year ago

There is a workaround to install a fork over the top of the main Local Tuya. Then remove the device and re add as protocol 3.4

On Sat, 3 Dec 2022, 16:26 zkvvoob, @.***> wrote:

Just to chime in - I had two Meka Ambient lights working perfectly fine with localTuya up until 15 minutes ago. Then I had the stupid idea of opening the Smart Life app in order to change the colours/effects (which I've been unable to do through HA). A firmware updated began and before I could react, it had installed - Main Module/MCU 2.0.19 and now localTuya won't even find one of the lamps (the one that got the update - I'm not updating the other one!).

— Reply to this email directly, view it on GitHub https://github.com/rospogrigio/localtuya/issues/1145#issuecomment-1336193104, or unsubscribe https://github.com/notifications/unsubscribe-auth/A2FHAFXKHQIFBNO6HZOPXQDWLNYENANCNFSM6AAAAAASMBCNXM . You are receiving this because you were mentioned.Message ID: @.***>

zkvvoob commented 1 year ago

There is a workaround to install a fork over the top of the main Local Tuya.

Could you point me to some instructions on how to do that, please?

plandregan commented 1 year ago

https://github.com/rospogrigio/localtuya/issues/1065#issuecomment-1304829471

Need SSH Addon to copy the files and run the clone command in this thread

On Sat, 3 Dec 2022, 16:54 zkvvoob, @.***> wrote:

There is a workaround to install a fork over the top of the main Local Tuya.

Could you point me to some instructions on how to do that, please?

— Reply to this email directly, view it on GitHub https://github.com/rospogrigio/localtuya/issues/1145#issuecomment-1336197370, or unsubscribe https://github.com/notifications/unsubscribe-auth/A2FHAFXAP3WPCL62G45SXCLWLN3LDANCNFSM6AAAAAASMBCNXM . You are receiving this because you were mentioned.Message ID: @.***>

Morpheus2018 commented 1 year ago

#1065 (comment) Need SSH Addon to copy the files and run the clone command in this thread

Error bug is not fixed @https://github.com/rospogrigio/localtuya/issues/1161#issuecomment-1352904205

rospogrigio commented 1 year ago

I have now published a PR that provides support for 3.4: #1222 . Can you test it and provide feedback? Thank you, enjoy.

MindFreeze commented 1 year ago

@pickonedev @plandregan the din rail switch mostly works with #1222 but it only updates the state frequently when I have the device open on the Tuya app. Otherwise it updates every few minutes at most. This wasn't the case with the tinytuya fork.

MindFreeze commented 1 year ago

after examining the logs with the tinytuya fork, it seems that it errors on every update and has to reconnect to the device. Coupled with the fact that the code in #1222 updates properly when first connecting and on full reload of localtuya, it seems the switch reports the real power value once when you connect to it and then it doesn't update it. The tuya app also somehow triggers updates but a few mins after I close the app, the device goes "asleep" again. Maybe there is a command to switch it into "live mode".

MindFreeze commented 1 year ago

Since 3.4 is now supported, should this issue be closed?

@pickonedev @plandregan After some debugging I found a way to wake up the din rail switch so it reports proper values. Long story short is that when you set DP66 to "online" it wakes up for a couple of mins. So I have an automation that does this:

service: localtuya.set_dp
data:
  device_id: ...
  dp: 66
  value: online

when the values haven't changed for more than a minute. Now it reports properly according to scan_interval.

pickonedev commented 1 year ago

For me it is working good now, I had a problem in my electrical panel which was interrupting the devices

plandregan commented 1 year ago

Since 3.4 is now supported, should this issue be closed?

@pickonedev @plandregan After some debugging I found a way to wake up the din rail switch so it reports proper values. Long story short is that when you set DP66 to "online" it wakes up for a couple of mins. So I have an automation that does this:
service: localtuya.set_dp
data:
  device_id: ...
  dp: 66
  value: online
when the values haven't changed for more than a minute. Now it reports properly according to scan_interval.

I too have seen my 3.4 device go to sleep, 3.3 doesnt. Exact same device. A reload of LocalTuya gets the data in. The previous way to merge TinyTuya was working perfectly. Took the leap and reloaded this new version. Since then the data is less granular, despite a 30s refresh. After a day or so the 3.4DIN Rail device goes to sleep. @MindFreeze How often do you call this service? Can you copy over your automation? to set this DP??

MindFreeze commented 1 year ago

@plandregan I have a template sensor that exposes the consumption attribute as sensor.grid_power and automate based on that

alias: Wake up Grid sensor
description: prevent din rail switch from sleeping
trigger:
  - platform: time_pattern
    hours: /1 # every hour for redundancy
  - platform: state
    entity_id:
      - sensor.grid_power
    for:
      hours: 0
      minutes: 1 # no change for 1 min
      seconds: 0
condition: []
action:
  - service: localtuya.set_dp
    data:
      device_id: ...
      dp: 66
      value: online
mode: single

plandregan commented 1 year ago

It fails as the device ID is offline. I need to reload the Integration and it comes immediately back online. Only happening with the 3.4 device. all the 3.3 devices are fine. Seems once the 3.4 device goes to sleep, it goes offline and cant be woken up again. Only reloading the LocalTuya brings it back, so the device is clearly not offline

MindFreeze commented 1 year ago

Maybe your DP is different. See if you have a DP with value "online" when adding the device. If reload works then it is not really offline. The tinytuya fork worked because it errored on every request and reconnected.

plandregan commented 1 year ago

Just had a look at the edit option, where you see 18, 19, 20 for power and voltage etc. In the list there isn't a DP 66, max is 42, and none say online

Strangely its offline again for LocalTuya, yet is online with the Cloud Tuya integration. ie switch greyed out on Local, available on cloud. So is a local Tuya issue with this and 3.4. The 3.3 identical switch is perfectly fine.

Any logs I can upload to assist?

plandregan commented 1 year ago

I found some one else with similar, and they did this to reload it

alias: Reload ASHP description: When ASHP Switch becomes unavailable - Reload it. Will see if once the switch goes unavailable, this will kick it back.

trigger:

platform: state entity_id:
- switch.localtuya_ashp to: unavailable condition: [] action:
service: homeassistant.reload_config_entry data: {} target: entity_id: switch.localtuya_ashp mode: single

Update. A few hours later, this automation had triggered 4 hours ago. The ASHP power reading is still there. So this has clearly reloaded just the entity that dissapeared. One for anyone else who has a disappearing entity that comes back on reload.

dombrowa commented 1 month ago

Another cause can be that the device's key in the cloud changed (this happened to one of my devices) "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.

rospogrigio / localtuya

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

The problem

Environment