Open FeikoJoosten opened 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)?
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.
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?
@postlund Check your email š
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.
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.
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
I couldn't agree more with you, but tuya devices can be a bit "special". Do they have the same firmware version?
How can I see the firmware version? I don't have these lights connected to the Tuya/Smart Life app.
Regarding the Tuya error codes table. Would this be useful?
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
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.
I'll disconnect them both and add them to Smart Life to see what their firmware version is then.
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
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.
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.
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.
What if you unlink both of them and try to add the second one first?
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.
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.
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...
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.
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?
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
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.
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.
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 š
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
.,,
Yeah it's complaining that it cannot find the DEBUG command :/
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.
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...
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
`
Great! š I will have a look at it tonight!
@FeikoJoosten Can you send me the key you used here?
@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.
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!
Okay, so some more info on this. I think something might be stuck in cache or something. This just happened to me:
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.
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.
Hi, I'm trying to add the 2nd lamp of the same model. This unfortunately fails. Here's the error from the logs
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