rospogrigio / localtuya

local handling for Tuya devices
GNU General Public License v3.0
3k stars 565 forks source link

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

Open milandzuris opened 2 years ago

milandzuris commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

please fix this

Odinlistening commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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

SergeantPup commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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

SergeantPup commented 2 years ago

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 commented 2 years ago

Thanks bro @SergeantPup I'll try your advice

matteoopc commented 2 years ago

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 commented 2 years ago

Have the same issue with this mini switch. image 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 commented 2 years ago

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

milandzuris commented 2 years ago

@rospogrigio

rospogrigio commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

is hard make local tuya for 3.4 protocol? @rospogrigio

redlingg commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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

rospogrigio commented 2 years ago

@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 commented 2 years ago

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?

CyanoFresh commented 2 years ago

localtuya 4.0.0:

This error originated from a custom integration.

Logger: custom_components.localtuya.pytuya
Source: custom_components/localtuya/pytuya/__init__.py:247
Integration: LocalTuya (documentation, issues)
First occurred: 12:49:44 (1 occurrences)
Last logged: 12:49:44

[bf5...sng] 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 539, in detect_available_dps
    data = await self.status()
  File "/config/custom_components/localtuya/pytuya/__init__.py", line 481, in status
    status = await self.exchange(STATUS)
  File "/config/custom_components/localtuya/pytuya/__init__.py", line 460, in exchange
    msg = await self.dispatcher.wait_for(seqno)
  File "/config/custom_components/localtuya/pytuya/__init__.py", line 247, 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
This error originated from a custom integration.

Logger: custom_components.localtuya.config_flow
Source: custom_components/localtuya/pytuya/__init__.py:247
Integration: LocalTuya (documentation, issues)
First occurred: 12:49:44 (1 occurrences)
Last logged: 12:49:44

Unexpected exception
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/config_flow.py", line 533, in async_step_configure_device
    self.dps_strings = await validate_input(self.hass, user_input)
  File "/config/custom_components/localtuya/config_flow.py", line 242, in validate_input
    detected_dps = await interface.detect_available_dps()
  File "/config/custom_components/localtuya/pytuya/__init__.py", line 539, in detect_available_dps
    data = await self.status()
  File "/config/custom_components/localtuya/pytuya/__init__.py", line 481, in status
    status = await self.exchange(STATUS)
  File "/config/custom_components/localtuya/pytuya/__init__.py", line 460, in exchange
    msg = await self.dispatcher.wait_for(seqno)
  File "/config/custom_components/localtuya/pytuya/__init__.py", line 247, 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
sibowler commented 2 years ago

Thanks @CyanoFresh - That would suggest it isn't related to the changes that were introduced in #956 (v4.1.0)... Did it work previously or have you always had this error with this device? If we can work out which version it last worked with that will help identify the issue.

CyanoFresh commented 2 years ago

Thanks @CyanoFresh - That would suggest it isn't related to the changes that were introduced in #956 (v4.1.0)... Did it work previously or have you always had this error with this device? If we can work out which version it last worked with that will help identify the issue.

Just arrived 1 switch for tests, I hoped it would work with localtuya, but it wasn't from the beginning. Also I tried tuya scan resulting 0 devices detected (I wanted to check the tuya version, is there other method?)

iosoft commented 2 years ago

My problem is solved after I switch to Tuya integration (non-local) This means, the issue is with Local Tuya plugin/code.

CyanoFresh commented 2 years ago

yep, non-local integration is working fine

derkrasseleo commented 2 years ago

same here, but this is not a fix because that's what's local tuya supposed to do: avoid the cloud

donburch888 commented 2 years ago

A couple of weeks ago I removed 3 of my 5 Arlec energy monitoring smart power sockets because I had gone over my Wifi AP's Station List limit. This dramatically reduced number of errors in the log, and allowed HA to run stable. In the meantime I have done all upgrades to HA as they became available; and the other 2 power sockets are continuing to work correctly. Including the update to LocalTuya 4.1.0

My new Wifi Access Point has arrived, and so I am trying to re-add my other wi-fi devices.
Adding devices in LocalTuya gives the error. I have tried manually adding the DP_ids as suggested above, but that seems to work only for a simple switch device.

This error originated from a custom integration.

Logger: custom_components.localtuya.common Source: custom_components/localtuya/pytuya/init.py:623 Integration: LocalTuya (documentation, issues) First occurred: 6:28:55 PM (187 occurrences) Last logged: 6:36:18 PM

[bfc...9ka] Connect to 192.168.1.106 failed [bf1...q1i] Connect to 192.168.1.109 failed Traceback (most recent call last): File "/config/custom_components/localtuya/common.py", line 216, in _make_connection await self._interface.reset(self._default_reset_dpids) File "/config/custom_components/localtuya/pytuya/init.py", line 521, in reset return await self.exchange(RESET, dpIds) File "/config/custom_components/localtuya/pytuya/init.py", line 492, in exchange payload = self._decode_payload(msg.payload) File "/config/custom_components/localtuya/pytuya/init.py", line 623, in _decode_payload return json.loads(payload) File "/usr/local/lib/python3.10/json/init.py", line 346, in loads return _default_decoder.decode(s) File "/usr/local/lib/python3.10/json/decoder.py", line 337, in decode obj, end = self.raw_decode(s, idx=_w(s, 0).end()) File "/usr/local/lib/python3.10/json/decoder.py", line 355, in raw_decode raise JSONDecodeError("Expecting value", s, err.value) from None json.decoder.

JSONDecodeError: Expecting value: line 1 column 1 (char 0)

187 errors in less than 10 minutes seems excessive, even for 2 devices.

there was also:

This error originated from a custom integration.

Logger: homeassistant Source: custom_components/localtuya/pytuya/init.py:623 Integration: LocalTuya (documentation, issues) First occurred: 6:38:03 PM (1 occurrences) Last logged: 6:38:03 PM

Error doing job: Fatal error: protocol.data_received() call failed. Traceback (most recent call last): File "/usr/local/lib/python3.10/asyncio/selector_events.py", line 868, in _read_readydata_received self._protocol.data_received(data) File "/config/custom_components/localtuya/pytuya/init.py", line 437, in data_received self.dispatcher.add_data(data) File "/config/custom_components/localtuya/pytuya/init.py", line 298, in add_data self._dispatch(TuyaMessage(seqno, cmd, retcode, payload, crc)) File "/config/custom_components/localtuya/pytuya/init.py", line 328, in _dispatch self.listener(msg) File "/config/custom_components/localtuya/pytuya/init.py", line 394, in _status_update decoded_message = self._decode_payload(msg.payload) File "/config/custom_components/localtuya/pytuya/init.py", line 623, in _decode_payload return json.loads(payload) File "/usr/local/lib/python3.10/json/init__.py", line 346, in loads return _default_decoder.decode(s) File "/usr/local/lib/python3.10/json/decoder.py", line 337, in decode obj, end = self.raw_decode(s, idx=_w(s, 0).end()) File "/usr/local/lib/python3.10/json/decoder.py", line 355, in raw_decode raise JSONDecodeError("Expecting value", s, err.value) from None json.decoder.JSONDecodeError: Expecting value: line 1 column 1 (char 0)

Diagnostics is:

{
  "home_assistant": {
    "installation_type": "Home Assistant OS",
    "version": "2022.10.3",
    "dev": false,
    "hassio": true,
    "virtualenv": false,
    "python_version": "3.10.5",
    "docker": true,
    "arch": "aarch64",
    "timezone": "Australia/Sydney",
    "os_name": "Linux",
    "os_version": "5.15.61-v8",
    "supervisor": "2022.10.0",
    "host_os": "Home Assistant OS 9.0",
    "docker_version": "20.10.17",
    "chassis": "embedded",
    "run_as_root": true
  },
  "custom_components": {
    "asusrouter": {
      "version": "0.8.2",
      "requirements": [
        "asusrouter==0.9.2"
      ]
    },
    "localtuya": {
      "version": "4.1.0",
      "requirements": []
    },
    "hacs": {
      "version": "1.28.0",
      "requirements": [
        "aiogithubapi>=22.2.4"
      ]
    },
    "nodered": {
      "version": "1.1.2",
      "requirements": []
    },
    "bureau_of_meteorology": {
      "version": "1.1.18",
      "requirements": [
        "iso8601"
      ]
    }
sibowler commented 2 years ago

Hi @donburch888 - I think the reset functionality is causing you issues. This behavior has been changed in a bugfix which is undergoing testing at the moment.

donburch888 commented 2 years ago

Restored back to my last Full backup on 2022-09-15. All devices restored to working state, but I note that LocalTuya still says it is v4.1.0

rospogrigio commented 2 years ago

The bugfix has been released yesterday (4.1.1), can you please test it @donburch888 ?

re-id commented 2 years ago

The bugfix has been released yesterday (4.1.1), can you please test it @donburch888 ?

No. Relay offline

donburch888 commented 2 years ago

I have updated my HA system and now up-to-date including LocalTuya 4.1.1. All my connected devices continued working.

(1) I have deleted one of my power sockets, rebooted and added the device back successfully. All the DP_ids are showing correctly. :+1:

(2) I am still getting an error repeated each minute from trying to connect to a device which is disabled and offline.

This error originated from a custom integration.

Logger: custom_components.localtuya.common
Source: custom_components/localtuya/pytuya/__init__.py:704
Integration: LocalTuya (documentation, issues)
First occurred: 12:34:10 PM (5 occurrences)
Last logged: 12:37:57 PM

[bfe...ndf] Connect to 192.168.1.105 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/custom_components/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.1.105', 6668)
stamandr commented 1 year ago

Dec 2,2022... Still not fixed

wissamnad commented 1 year ago

Same issue, 3CH WIFI-switch module only working using Official Tuya Integration and giving the error "Connection to device succeeded but no datapoints found, please try again." when using local Tuya. The switch DPs from the IoT are 1,2 and 3 and if configured in Local Tuya, device is created but entities are "Unavailable" !

I have the same type of device 3CH WIFI-switch module with Main Module/MCU Module V1.1.6 and it works totally fine using Local Tuya. The other ones I bought and presenting this issue are with V1.2.1

smithbill17 commented 1 year ago

I'm now getting this same issue.

I bought 4 identical SmartPlugs. I added them one after the other to my existing LocalTuya setup, and when I got to the 4th plug, I started getting this error.

If I enter '1' into the Manual DPS, it allows me to add the plug okay, but it is 'unavailable'. I can make it become available by using the SmartLife app to switch the plug on or off (which works fine), but after 30 seconds or so, the plug in HomeAssistant goes unavailable again. Doesn't matter if the switch state was on or off, it goes unavailable after a few seconds.

I tried deleting the device & re-adding it (with Manual DPS set as 1 & with device type switch), but I just get the same happening.

Is there a solution? What is DPS anyway?

smithbill17 commented 1 year ago

So I downloaded the LocalTuya integration diagnostics and took a look through (most of it didn't mean much to me).

For the SmartPlugs I added which worked fine (Plug-HBN4), I notice it has automatic DPS values of 1 & 9.

So I thought I would try re-adding my failed SmartPlug (Plug-HBN3) and entered manual DPS values of "1,9". At first I thought this had solved the issue, but I hadn't, the SmartPlug still goes unavailable.

When I redownloaded the LocalTuya diagnostics (pasted below), I can see it has my manually entered DPS as "1,9" but it looks like it's not actually configured the failed SmartPlug (Plug-HBN3) with these values as the 'dps_strings' are different. Is this relevant to this issue?

(Note: I deleted the localkey & device IDs for security reasons in the below extract)

        "friendly_name": "Plug-HBN4",
        "local_key": "8c9...5ce",
        "host": "192.168.68.164",
        "device_id": "",
        "protocol_version": "3.3",
        "model": "Smart Plug",
        "dps_strings": [
          "1 (value: True)",
          "9 (value: 0)"
        ],
        "entities": [
          {
            "id": 1,
            "friendly_name": "Plug-HBN4",
            "restore_on_reconnect": false,
            "is_passive_entity": false,
            "current": 1,
            "current_consumption": 1,
            "voltage": 1,
            "platform": "switch"
          }
        ],
        "product_key": ""
      },

      "": {
        "friendly_name": "Plug-HBN3",
        "host": "192.168.68.163",
        "local_key": "3f1...ee3",
        "protocol_version": "3.3",
        "manual_dps_strings": "1,9",
        "entities": [
          {
            "friendly_name": "Plug-HBN3",
            "current": 1,
            "current_consumption": 1,
            "voltage": 1,
            "restore_on_reconnect": false,
            "is_passive_entity": false,
            "id": 1,
            "platform": "switch"
          }
        ],
        "model": "Smart Plug",
        "device_id": "",
        "dps_strings": [
          "1 (value: -1)"
        ],
        "product_key": ""
      }
    },
smithbill17 commented 1 year ago

There doesn't seem to be any progress on this issue for 1+ years & GitHub says "no one assigned" - how do we get someone who maintains the LocalTuya integration to take a look?

@rospogrigio

bored-mind commented 1 year ago

same issue here. if it matters my devices are on different ip range than homeassistant. the devices are on 192.168.86.xxx and homeassistant is on 192.168.1.13

the logs are these:

Logger: custom_components.localtuya.pytuya Source: custom_components/localtuya/pytuya/init.py:259 Integration: LocalTuya (documentation, issues) First occurred: 22:56:40 (6 occurrences) Last logged: 23:30:45

[bf1...b97] Failed to get status: [bfb...yfd] Failed to get status: [081...d9a] Failed to get status: [081...d4e] Failed to get status: [081...d75] 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

valentin1009 commented 1 year ago

Follow these instructions to get de DPS of your device, then type these on "Manual DPS field". Don't forget to separate values by commas if you have multiple switches on same device.

kevvar commented 1 year ago

Hi friends local tuya add support for 3.4 protocol https://github.com/rospogrigio/localtuya/issues/1041#issuecomment-1375495357

wissamnad commented 1 year ago

Confirmed, working now!

balbulator commented 1 year ago

Constantly going offline/online, full error log

`Logger: custom_components.localtuya.common Source: custom_components/localtuya/pytuya/init.py:450 Integration: LocalTuya integration (documentation, issues) First occurred: 00:58:22 (1 occurrences) Last logged: 00:58:22

[638...ad0] Failed to set DP 2 to True 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/common.py", line 322, in set_dp await self._interface.set_dp(state, dp_index) File "/config/custom_components/localtuya/pytuya/init.py", line 836, in set_dp return await self.exchange(CONTROL, {str(dp_index): value}) 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 `