search

rospogrigio / localtuya

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

Failed to add second device #185

Open FeikoJoosten opened 3 years ago

FeikoJoosten commented 3 years ago

Hi, I'm trying to add the 2nd lamp of the same model. This unfortunately fails. Here's the error from the logs

2020-11-23 18:56:08 DEBUG (MainThread) [custom_components.localtuya.pytuya] [801...421] Started heartbeat loop
2020-11-23 18:56:08 DEBUG (MainThread) [custom_components.localtuya.pytuya] [801...421] Sending command heartbeat (device type: type_0a)
2020-11-23 18:56:08 DEBUG (MainThread) [custom_components.localtuya.pytuya] [801...421] Send payload: b'{}'
2020-11-23 18:56:08 DEBUG (MainThread) [custom_components.localtuya.pytuya] [801...421] Waiting for sequence number -100
2020-11-23 18:56:08 DEBUG (MainThread) [custom_components.localtuya.pytuya] [801...421] Sending command status (device type: type_0a)
2020-11-23 18:56:08 DEBUG (MainThread) [custom_components.localtuya.pytuya] [801...421] Send payload: b'{"gwId":"80157022e09806020421","devId":"80157022e09806020421"}'
2020-11-23 18:56:08 DEBUG (MainThread) [custom_components.localtuya.pytuya] [801...421] Waiting for sequence number 1
2020-11-23 18:56:08 DEBUG (MainThread) [custom_components.localtuya.pytuya] [801...421] Dispatching message TuyaMessage(seqno=0, cmd=9, retcode=0, payload=b'', crc=2958142211)
2020-11-23 18:56:08 DEBUG (MainThread) [custom_components.localtuya.pytuya] [801...421] Got heartbeat response
2020-11-23 18:56:08 DEBUG (MainThread) [custom_components.localtuya.pytuya] [801...421] Decrypted payload: {}
2020-11-23 18:56:08 DEBUG (MainThread) [custom_components.localtuya.pytuya] [801...421] Dispatching message TuyaMessage(seqno=1, cmd=10, retcode=1, payload=b'\xd6\xc8\x97)?\xbb\xd1\xcbAz\xac\xfa\x12\x99\xd0\xe1\xb0\x96\xd2\xbe/P.\x7f\xdd\x19\x06\x07\x14\xc7\x17\x14', crc=1540829754)
2020-11-23 18:56:08 DEBUG (MainThread) [custom_components.localtuya.pytuya] [801...421] Dispatching sequence number 1
2020-11-23 18:56:08 DEBUG (MainThread) [custom_components.localtuya.pytuya] [801...421] Decrypted payload:
2020-11-23 18:56:08 ERROR (MainThread) [custom_components.localtuya.pytuya] [801...421] Failed to get status: Expecting value: line 1 column 1 (char 0)
Traceback (most recent call last):
File "/config/custom_components/localtuya/pytuya/__init__.py", line 499, in detect_available_dps
data = await self.status()
File "/config/custom_components/localtuya/pytuya/__init__.py", line 461, in status
status = await self.exchange(STATUS)
File "/config/custom_components/localtuya/pytuya/__init__.py", line 446, in exchange
payload = self._decode_payload(msg.payload)
File "/config/custom_components/localtuya/pytuya/__init__.py", line 548, in _decode_payload
return json.loads(payload)
File "/usr/local/lib/python3.8/json/__init__.py", line 357, in loads
return _default_decoder.decode(s)
File "/usr/local/lib/python3.8/json/decoder.py", line 337, in decode
obj, end = self.raw_decode(s, idx=_w(s, 0).end())
File "/usr/local/lib/python3.8/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)
2020-11-23 18:56:08 DEBUG (MainThread) [custom_components.localtuya.pytuya] [801...421] Closing connection
2020-11-23 18:56:08 DEBUG (MainThread) [custom_components.localtuya.pytuya] [801...421] Connection lost: None
2020-11-23 18:56:08 DEBUG (MainThread) [custom_components.localtuya.pytuya] [801...421] Closing connection

The error provided by the Integration field: Failed to authenticate with device. Verify that device id and local key are correct.. I can confirm the device id and local key are correct.

Steps tried

Additional notes I'm currently running a slightly modified HACS version, which is created by @ultratoto14 and can be viewed at PR-182

postlund commented 3 years ago

Just to confirm, this is set up via YAML and when you try via config flow you get the Failed to authenticate with device. Verify that device id and local key are correct. error during the initial step (after discovery)?

FeikoJoosten commented 3 years ago

I haven't setup anything through YAML, this is all through the config flow. Doing everything through config flow is also how I've setup the first device without any issues.

This is indeed after the discovery and happens when I click SUBMIT on this screen. image

postlund commented 3 years ago

Ah, right. Now I understand, good. Would be interesting to know if the decryption fails. Can you send the local key (via email) to me so I can try to manually decrypt the data?

FeikoJoosten commented 3 years ago

@postlund Check your email šŸ˜‰

postlund commented 3 years ago

I see now that the return code is 1, which indicates an error:

2020-11-23 18:56:08 DEBUG (MainThread) [custom_components.localtuya.pytuya] [801...421] Dispatching message TuyaMessage(seqno=1, cmd=10, retcode=1, payload=b'\xd6\xc8\x97)?\xbb\xd1\xcbAz\xac\xfa\x12\x99\xd0\xe1\xb0\x96\xd2\xbe/P.\x7f\xdd\x19\x06\x07\x14\xc7\x17\x14', crc=1540829754)

As I don't have any table over the error codes, I can't know for sure what it means. But a guess based on quick googling would be "invalid data format". Don't know how to fix that, but it would be interesting to try it as a "type d" device. Maybe you can open custom_components/localtuya/pytuya/__init__.py, scroll down to a line looking like this:

self.dev_type = "type_0a"

It's in an __init__ function. Change the "a" at the end to a "d" instead and try again. Please include debug log as well.

FeikoJoosten commented 3 years ago

Rebooting HA now. But I'd like to point out that the other lamp I've already added is the exact same model/branch as the 2nd device that I'm currently adding. So it would seem rather weird that I'd have to change the code.

FeikoJoosten commented 3 years ago

Error received when trying with the proposed change.

Edit: correct error. Sorry, bad copy paste.

2020-11-23 19:51:53 DEBUG (MainThread) [custom_components.localtuya.pytuya] [801...421] Started heartbeat loop
2020-11-23 19:51:53 DEBUG (MainThread) [custom_components.localtuya.pytuya] [801...421] Sending command heartbeat (device type: type_0d)
2020-11-23 19:51:53 DEBUG (MainThread) [custom_components.localtuya.pytuya] [801...421] Send payload: b'{}'
2020-11-23 19:51:53 DEBUG (MainThread) [custom_components.localtuya.pytuya] [801...421] Waiting for sequence number -100
2020-11-23 19:51:53 DEBUG (MainThread) [custom_components.localtuya.pytuya] [801...421] Connection lost: [Errno 104] Connection reset by peer
2020-11-23 19:51:53 DEBUG (MainThread) [custom_components.localtuya.pytuya] [801...421] Closing connection
2020-11-23 19:51:53 DEBUG (MainThread) [custom_components.localtuya.pytuya] [801...421] Wait was aborted for seqno -100
2020-11-23 19:51:53 DEBUG (MainThread) [custom_components.localtuya.pytuya] [801...421] Sending command status (device type: type_0d)
2020-11-23 19:51:53 DEBUG (MainThread) [custom_components.localtuya.pytuya] [801...421] Send payload: b'{"devId":"80157022e09806020421","uid":"80157022e09806020421","t":"1606161113","dps":{"1":null,"2":null,"3":null,"4":null,"5":null,"6":null,"7":null,"8":null,"9":null,"10":null}}'
2020-11-23 19:51:53 ERROR (MainThread) [custom_components.localtuya.pytuya] [801...421] Failed to get status: 'NoneType' object has no attribute 'write'
Traceback (most recent call last):
File "/config/custom_components/localtuya/pytuya/__init__.py", line 499, in detect_available_dps
data = await self.status()
File "/config/custom_components/localtuya/pytuya/__init__.py", line 461, in status
status = await self.exchange(STATUS)
File "/config/custom_components/localtuya/pytuya/__init__.py", line 439, in exchange
self.transport.write(payload)
AttributeError: 'NoneType' object has no attribute 'write'
2020-11-23 19:51:53 DEBUG (MainThread) [custom_components.localtuya.pytuya] [801...421] Closing connection
postlund commented 3 years ago

I couldn't agree more with you, but tuya devices can be a bit "special". Do they have the same firmware version?

FeikoJoosten commented 3 years ago

How can I see the firmware version? I don't have these lights connected to the Tuya/Smart Life app.

FeikoJoosten commented 3 years ago

Regarding the Tuya error codes table. Would this be useful?

FeikoJoosten commented 3 years ago

Just updated to the latest master version and tried again. Got this error this time.

2020-11-23 20:17:54 DEBUG (MainThread) [custom_components.localtuya.pytuya] [801...421] Started heartbeat loop
2020-11-23 20:17:54 DEBUG (MainThread) [custom_components.localtuya.pytuya] [801...421] Sending command heartbeat (device type: type_0a)
2020-11-23 20:17:54 DEBUG (MainThread) [custom_components.localtuya.pytuya] [801...421] Send payload: b'{}'
2020-11-23 20:17:54 DEBUG (MainThread) [custom_components.localtuya.pytuya] [801...421] Waiting for sequence number -100
2020-11-23 20:17:54 DEBUG (MainThread) [custom_components.localtuya.pytuya] [801...421] Sending command status (device type: type_0a)
2020-11-23 20:17:54 DEBUG (MainThread) [custom_components.localtuya.pytuya] [801...421] Send payload: b'{"gwId":"80157022e09806020421","devId":"80157022e09806020421"}'
2020-11-23 20:17:54 DEBUG (MainThread) [custom_components.localtuya.pytuya] [801...421] Waiting for sequence number 1
2020-11-23 20:17:54 DEBUG (MainThread) [custom_components.localtuya.pytuya] [801...421] Dispatching message TuyaMessage(seqno=0, cmd=9, retcode=0, payload=b'', crc=2958142211)
2020-11-23 20:17:54 DEBUG (MainThread) [custom_components.localtuya.pytuya] [801...421] Got heartbeat response
2020-11-23 20:17:54 DEBUG (MainThread) [custom_components.localtuya.pytuya] [801...421] Decrypted payload: {}
2020-11-23 20:17:54 DEBUG (MainThread) [custom_components.localtuya.pytuya] [801...421] Dispatching message TuyaMessage(seqno=1, cmd=10, retcode=1, payload=b'\xd6\xc8\x97)?\xbb\xd1\xcbAz\xac\xfa\x12\x99\xd0\xe1\xb0\x96\xd2\xbe/P.\x7f\xdd\x19\x06\x07\x14\xc7\x17\x14', crc=1540829754)
2020-11-23 20:17:54 DEBUG (MainThread) [custom_components.localtuya.pytuya] [801...421] Dispatching sequence number 1
2020-11-23 20:17:54 DEBUG (MainThread) [custom_components.localtuya.pytuya] [801...421] Decrypted payload:
2020-11-23 20:17:54 ERROR (MainThread) [custom_components.localtuya.pytuya] [801...421] Failed to get status: Expecting value: line 1 column 1 (char 0)
Traceback (most recent call last):
File "/config/custom_components/localtuya/pytuya/__init__.py", line 499, in detect_available_dps
data = await self.status()
File "/config/custom_components/localtuya/pytuya/__init__.py", line 461, in status
status = await self.exchange(STATUS)
File "/config/custom_components/localtuya/pytuya/__init__.py", line 446, in exchange
payload = self._decode_payload(msg.payload)
File "/config/custom_components/localtuya/pytuya/__init__.py", line 548, in _decode_payload
return json.loads(payload)
File "/usr/local/lib/python3.8/json/__init__.py", line 357, in loads
return _default_decoder.decode(s)
File "/usr/local/lib/python3.8/json/decoder.py", line 337, in decode
obj, end = self.raw_decode(s, idx=_w(s, 0).end())
File "/usr/local/lib/python3.8/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)
2020-11-23 20:17:54 DEBUG (MainThread) [custom_components.localtuya.pytuya] [801...421] Closing connection
2020-11-23 20:17:54 DEBUG (MainThread) [custom_components.localtuya.pytuya] [801...421] Connection lost: None
2020-11-23 20:17:54 DEBUG (MainThread) [custom_components.localtuya.pytuya] [801...421] Closing connection
postlund commented 3 years ago

How can I see the firmware version? I don't have these lights connected to the Tuya/Smart Life app.

Don't think it's possible without using an app. I'm non the same boat as you.

FeikoJoosten commented 3 years ago

I'll disconnect them both and add them to Smart Life to see what their firmware version is then.

FeikoJoosten commented 3 years ago

Took me a while to get it to work, but here you go.

Device that connects: Main Module: V2.3.0 MCU Module: V2.3.0

Device that doesn't connect: Main Module: V2.3.0 MCU Module: V2.3.0

postlund commented 3 years ago

I just tried to fetch status from one of my plugs, first testing with the correct key to see that it worked (which it did) and then change to an incorrect key. Guess what? Same error as you. So I believe the key is wrong somehow.

The message looked like this:

DEBUG:main:[045...22c] Dispatching message TuyaMessage(seqno=1, cmd=10, retcode=1, payload=b'OT?Zd\r\xf5\xc9.o\xf0\xf2\xc6\xfc;7\xca\xb1\xca{<o\xf9\xe81{\xca\xd8ZH\x1d\xe9', crc=315478498)

When I decoded the payload with correct key, I got data format error. So the million dollar question is what's wrong as it's quite obvious that you had the correct key (based on the email you sent). Because the output above was using the same local key as the one you sent me, right? Since you get a new one every time you provision it again.

FeikoJoosten commented 3 years ago

What I've currently done is unlink the original app I created in Tuya Development environment. I added a new app and trying to set those up now. I've just relinked them using tuya-cli and I'm currently waiting on HA to restart so I can setup the local tuya integration.

The reason I'm doing this is because I was suddenly unable to link the initial device as well... Hoping this is going to resolve the issue.

FeikoJoosten commented 3 years ago

Okay, setting up the app in Tuya Development environment did solve the issue where I couldn't link lamp 1 any more. But lamp 2 is still a PITA.

postlund commented 3 years ago

What if you unlink both of them and try to add the second one first?

FeikoJoosten commented 3 years ago

I'm ahead of you there as that was my initial thought as well. Wasn't able to link the second lamp (which scared me as I figured the first one wouldn't link anymore either). But the first one did properly link hehe.

FeikoJoosten commented 3 years ago

Gonna try something else. I'll add the device to the Smart Life app. I'll then use the tuya-cli wizard to retrieve the key icm with the Smart Life app. And I'll try and add that device through the LocalTuya integration.

postlund commented 3 years ago

Ahum, question is what we do now. Since these devices are supposed to be identical, it's strange that they don't work in the same way. Can you query datapoints correctly with tuya-cli btw? Assuming you manage to link the light again...

postlund commented 3 years ago

Gonna try something else. I'll add the device to the Smart Life app. I'll then use the tuya-cli wizard to retrieve the key icm with the Smart Life app. And I'll try and add that device through the LocalTuya integration.

Yes, that is one idea as well.

FeikoJoosten commented 3 years ago

Yes, that is one idea as well.

Failed as well, got this error:

2020-11-23 21:36:36 DEBUG (MainThread) [custom_components.localtuya.pytuya] [801...421] Started heartbeat loop
2020-11-23 21:36:36 DEBUG (MainThread) [custom_components.localtuya.pytuya] [801...421] Sending command heartbeat (device type: type_0a)
2020-11-23 21:36:36 DEBUG (MainThread) [custom_components.localtuya.pytuya] [801...421] Send payload: b'{}'
2020-11-23 21:36:36 DEBUG (MainThread) [custom_components.localtuya.pytuya] [801...421] Waiting for sequence number -100
2020-11-23 21:36:36 DEBUG (MainThread) [custom_components.localtuya.pytuya] [801...421] Connection lost: [Errno 104] Connection reset by peer
2020-11-23 21:36:36 DEBUG (MainThread) [custom_components.localtuya.pytuya] [801...421] Closing connection
2020-11-23 21:36:36 DEBUG (MainThread) [custom_components.localtuya.pytuya] [801...421] Wait was aborted for seqno -100
2020-11-23 21:36:36 DEBUG (MainThread) [custom_components.localtuya.pytuya] [801...421] Sending command status (device type: type_0a)
2020-11-23 21:36:36 DEBUG (MainThread) [custom_components.localtuya.pytuya] [801...421] Send payload: b'{"gwId":"80157022e09806020421","devId":"80157022e09806020421"}'
2020-11-23 21:36:36 ERROR (MainThread) [custom_components.localtuya.pytuya] [801...421] Failed to get status: 'NoneType' object has no attribute 'write'
Traceback (most recent call last):
File "/config/custom_components/localtuya/pytuya/__init__.py", line 499, in detect_available_dps
data = await self.status()
File "/config/custom_components/localtuya/pytuya/__init__.py", line 461, in status
status = await self.exchange(STATUS)
File "/config/custom_components/localtuya/pytuya/__init__.py", line 439, in exchange
self.transport.write(payload)
AttributeError: 'NoneType' object has no attribute 'write'
2020-11-23 21:36:36 DEBUG (MainThread) [custom_components.localtuya.pytuya] [801...421] Closing connection
2020-11-23 21:36:36 ERROR (MainThread) [custom_components.localtuya.config_flow] Unexpected exception
Traceback (most recent call last):
File "/config/custom_components/localtuya/config_flow.py", line 260, in async_step_basic_info
self.dps_strings = await validate_input(self.hass, user_input)
File "/config/custom_components/localtuya/config_flow.py", line 173, in validate_input
detected_dps = await interface.detect_available_dps()
File "/config/custom_components/localtuya/pytuya/__init__.py", line 499, in detect_available_dps
data = await self.status()
File "/config/custom_components/localtuya/pytuya/__init__.py", line 461, in status
status = await self.exchange(STATUS)
File "/config/custom_components/localtuya/pytuya/__init__.py", line 439, in exchange
self.transport.write(payload)
AttributeError: 'NoneType' object has no attribute 'write'

Can you query datapoints correctly with tuya-cli btw

Is this just the tuya-cli get command?

FeikoJoosten commented 3 years ago

I've just used this command tuya-cli get --id IDIDIDIDIDID --key KEYKEYKEY --ip 192.168.0.129 --protocol-version 3.3 -a (obv with right id/key)

And properly retrieved all DPs

postlund commented 3 years ago

You get connection reset though (someone is using the device), make sure you kill the app.

Yeah, tuya-cli get, passing id, key and so on. You can use -a to get all datapoints.

postlund commented 3 years ago

I've just used this command tuya-cli get --id IDIDIDIDIDID --key KEYKEYKEY --ip 192.168.0.129 --protocol-version 3.3 -a (obv with right id/key)

And properly retrieved all DPs

That is great news! It means that we are doing something bad. Maybe you can figure out how to enable debugging somehow, so we can start to compare what we are doing.

FeikoJoosten commented 3 years ago

make sure you kill the app.

Yep, great catch! I've successfully linked my device now!

I tried figuring out how to enable debugging, but I'm not sure I'm capable of doing so... Cannot seem to get the DEBUG="*" to function šŸ˜ž

postlund commented 3 years ago

Hmm, that's strange. This seems to work for me:

$ DEBUG="*" tuya-cli get -a --id xxx --key yyy --protocol-version 3.3
  TuyAPI Finding missing IP undefined or ID yyy +0ms
  TuyAPI Received UDP message. +2s
.,,
FeikoJoosten commented 3 years ago

Yeah it's complaining that it cannot find the DEBUG command :/

postlund commented 3 years ago

It should lot evaluate that as a command. Try setting it as an environment variable before running the command instead:

export DEBUG=*

It will depend on your shel what to use, so you might have to look that up.

FeikoJoosten commented 3 years ago

Somehow there seems to be no debug.exe located in my system32 folder. Trying to figure out where I can get that without having to install VM...

FeikoJoosten commented 3 years ago

Okay nvm. I was being stupid šŸ˜‚ Here you go:


C:\Users\Feiko>tuya-cli get --id 80157022e09806020421 --key KEYKEYKEY --ip 192.168.0.129 --protocol-version 3.3 -a
  TuyAPI IP and ID are already both resolved. +0ms
  TuyAPI Connecting to 192.168.0.129... +1ms
  TuyAPI Socket connected. +53ms
  TuyAPI GET Payload: +1ms
  TuyAPI {
  TuyAPI   gwId: '80157022e09806020421',
  TuyAPI   devId: '80157022e09806020421',
  TuyAPI   t: '1606220268',
  TuyAPI   dps: {},
  TuyAPI   uid: '80157022e09806020421'
  TuyAPI } +0ms
  TuyAPI GET Payload: +3ms
  TuyAPI {
  TuyAPI   gwId: '80157022e09806020421',
  TuyAPI   devId: '80157022e09806020421',
  TuyAPI   t: '1606220268',
  TuyAPI   dps: {},
  TuyAPI   uid: '80157022e09806020421'
  TuyAPI } +1ms
  TuyAPI Received data: 000055aa000000010000000a0000011c00000000f5e91478cb25580c2432303cc63029a09f6a1136af869b99a7dc70e6893af60d0b0e5cfbeec04e1666c5a04cb72db7f8718a12a679798447564d66504f0ac26f317e17f818e88cc11e2bcfd5ec228da49f00833ddb98486d80c2f0c17f21a4d7e7aacc7c9a5c93c0b0641572469f77a90686ec5576bed706f83aeea6da2b73aa06aa1382604b389e3ea018ca86698cc129a81498312c4ff56ace32f8e57fdada2f0a313673592dd0e8f7a79109764ddb9111e262ed5338ab2acd86092d81e5636af3ff98cf2fe7f688af6e0f0db1c6059a11a32fa32ff39dd1a79fc40fb617cc1fcdafac6ad9ba1efb16fba4ee14f21ba2a2b4046bce54206e7b5d89ab747a2cab22221efa4a495d69f477694e42fbade86055cc0000aa55 +15ms
  TuyAPI Parsed: +1ms
  TuyAPI {
  TuyAPI   payload: {
  TuyAPI     devId: '80157022e09806020421',
  TuyAPI     dps: {
  TuyAPI       '1': false,
  TuyAPI       '2': 'white',
  TuyAPI       '3': 47,
  TuyAPI       '4': 0,
  TuyAPI       '5': 'ff00000000ffff',
  TuyAPI       '6': 'bd76000168ffff',
  TuyAPI       '7': 'ffff500100ff00',
  TuyAPI       '8': 'ffff8003ff000000ff000000ff000000000000000000',
  TuyAPI       '9': 'ffff5001ff0000',
  TuyAPI       '10': 'ffff0505ff000000ff00ffff00ff00ff0000ff000000'
  TuyAPI     }
  TuyAPI   },
  TuyAPI   leftover: false,
  TuyAPI   commandByte: 10,
  TuyAPI   sequenceN: 1
  TuyAPI } +0ms
  TuyAPI Received data: 000055aa000000020000000a0000011c00000000f5e91478cb25580c2432303cc63029a09f6a1136af869b99a7dc70e6893af60d0b0e5cfbeec04e1666c5a04cb72db7f8718a12a679798447564d66504f0ac26f317e17f818e88cc11e2bcfd5ec228da49f00833ddb98486d80c2f0c17f21a4d7e7aacc7c9a5c93c0b0641572469f77a90686ec5576bed706f83aeea6da2b73aa06aa1382604b389e3ea018ca86698cc129a81498312c4ff56ace32f8e57fdada2f0a313673592dd0e8f7a79109764ddb9111e262ed5338ab2acd86092d81e5636af3ff98cf2fe7f688af6e0f0db1c6059a11a32fa32ff39dd1a79fc40fb617cc1fcdafac6ad9ba1efb16fba4ee14f21ba2a2b4046bce54206e7b5d89ab747a2cab22221efa4a495d69f477694e42fbad6d35aa5d0000aa55 +14ms
  TuyAPI Parsed: +1ms
  TuyAPI {
  TuyAPI   payload: {
  TuyAPI     devId: '80157022e09806020421',
  TuyAPI     dps: {
  TuyAPI       '1': false,
  TuyAPI       '2': 'white',
  TuyAPI       '3': 47,
  TuyAPI       '4': 0,
  TuyAPI       '5': 'ff00000000ffff',
  TuyAPI       '6': 'bd76000168ffff',
  TuyAPI       '7': 'ffff500100ff00',
  TuyAPI       '8': 'ffff8003ff000000ff000000ff000000000000000000',
  TuyAPI       '9': 'ffff5001ff0000',
  TuyAPI       '10': 'ffff0505ff000000ff00ffff00ff00ff0000ff000000'
  TuyAPI     }
  TuyAPI   },
  TuyAPI   leftover: false,
  TuyAPI   commandByte: 10,
  TuyAPI   sequenceN: 2
  TuyAPI } +0ms
  TuyAPI Disconnect +2ms
{
  devId: '80157022e09806020421',
  dps: {
    '1': false,
    '2': 'white',
    '3': 47,
    '4': 0,
    '5': 'ff00000000ffff',
    '6': 'bd76000168ffff',
    '7': 'ffff500100ff00',
    '8': 'ffff8003ff000000ff000000ff000000000000000000',
    '9': 'ffff5001ff0000',
    '10': 'ffff0505ff000000ff00ffff00ff00ff0000ff000000'
  }
}
  TuyAPI Socket closed: 192.168.0.129 +1ms
`
postlund commented 3 years ago

Great! šŸ˜‰ I will have a look at it tonight!

postlund commented 3 years ago

@FeikoJoosten Can you send me the key you used here?

postlund commented 3 years ago

@FeikoJoosten One thing I noted is that tuya-cli includes uid in the status message, which we don't. Now sure the importance of that, but I created a branch where I added that. Would be great if you could try. It's this one:

https://github.com/rospogrigio/localtuya/tree/detect_dps_fix

Also, one strange thing is that tuya-cli doesn't log the outgoing messages (bytes). If the change I made doesn't work, we will need to add a log point for that so I can see what's actually being sent as that is what is important.

FeikoJoosten commented 3 years ago

I've sent you the ID/key combination through email!

I can probably test later this week to see if the branch fixes the issue. Thanks for looking into it!

FeikoJoosten commented 3 years ago

Okay, so some more info on this. I think something might be stuck in cache or something. This just happened to me:

  1. A new smart socket arrived so I wanted to link it.
  2. Linked it using Tuya-cli
  3. Was setting it up using the configuration interface.
  4. When having to define the properties, I wanted to check the values using https://iot.tuya.com/cloud/appinfo
  5. I noticed the region was set to US instead of EU so I unlinked and relinked the device.
  6. Restart home assistant
  7. Continued with the setup of LocalTuya
  8. The configuration is complaining that the id + local key combination is invalid. Even though the first time I did manage to get past this window.

I think that it might've stored the 'old' local key somewhere and it might be trying to use that instead of the 'new' local key.

dhomoney commented 3 years ago

Has there been any fix? I have a bunch of Tuya stuff, a mixture of bulbs and switches. I have added all of them except one of the bulbs and I am getting the exact same error about the id + local key being invalid.