Closed btoo closed 4 years ago
Hmm, it's possible that your api-key/secret
parameters could be wrong.
Otherwise, you can try starting the tool with DEBUG=* tuya-cli ...
prepended to produce some more debugable output.
Hello,
I am having the same issue. Here is the command I am running:
DEBUG=* tuya-cli link --api-key retr********** --api-secret c78****** --schema cjmhomebridge --ssid 'Island Court' --password *****
This is what I am getting from the debug output:
⠴ Registering devices(s)... @tuyapi/link:wizard Token: { region: 'AZ', secret: 'zjg2', token: 'jnugDJmX' } +0ms @tuyapi/link:manual Sending SmartLink initialization packets +0ms @tuyapi/link:wizard Polling cloud for details on token... +5ms ⠏ Registering devices(s)... @tuyapi/link:wizard 0 devices returned by API. +357ms ⠸ Registering devices(s)... @tuyapi/link:wizard 0 devices returned by API. +335ms ⠧ Registering devices(s)... @tuyapi/link:wizard 0 devices returned by API. +355ms ⠹ Registering devices(s)... @tuyapi/link:wizard 0 devices returned by API. +369ms ⠇ Registering devices(s)... @tuyapi/link:wizard 0 devices returned by API. +493ms ⠋ Registering devices(s)... @tuyapi/link:manual Sending SmartLink data packets +2s ⠹ Registering devices(s)... @tuyapi/link:wizard 0 devices returned by API. +347ms ⠧ Registering devices(s)... @tuyapi/link:wizard 0 devices returned by API. +370ms ⠙ Registering devices(s)... @tuyapi/link:wizard 0 devices returned by API. +338ms ⠦ Registering devices(s)... @tuyapi/link:wizard 0 devices returned by API. +414ms ⠋ Registering devices(s)... @tuyapi/link:wizard 0 devices returned by API. +351ms ⠴ Registering devices(s)... @tuyapi/link:wizard 0 devices returned by API. +410ms ⠙ Registering devices(s)... @tuyapi/link:wizard 0 devices returned by API. +475ms ⠧ Registering devices(s)... @tuyapi/link:wizard 0 devices returned by API. +477ms ⠋ Registering devices(s)... @tuyapi/link:manual Finished sending packets. +3s ⠹ Registering devices(s)... @tuyapi/link:wizard 0 devices returned by API. +395ms ⠦ Registering devices(s)... @tuyapi/link:wizard 0 devices returned by API. +356ms ⠋ Registering devices(s)... @tuyapi/link:wizard 0 devices returned by API. +345ms ⠼ Registering devices(s)... @tuyapi/link:wizard 0 devices returned by API. +332ms ⠋ Registering devices(s)... @tuyapi/link:wizard 0 devices returned by API. +459ms ⠴ Registering devices(s)... @tuyapi/link:wizard 0 devices returned by API. +447ms ⠋ Registering devices(s)... @tuyapi/link:wizard 0 devices returned by API. +398ms ⠴ Registering devices(s)... @tuyapi/link:wizard 0 devices returned by API. +429ms ⠏ Registering devices(s)... @tuyapi/link:wizard 0 devices returned by API. +328ms ⠸ Registering devices(s)... @tuyapi/link:wizard 0 devices returned by API. +337ms ⠏ Registering devices(s)... @tuyapi/link:wizard 0 devices returned by API. +553ms ⠼ Registering devices(s)... @tuyapi/link:wizard 0 devices returned by API. +349ms ⠋ Registering devices(s)... @tuyapi/link:wizard 0 devices returned by API. +565ms ⠼ Registering devices(s)... @tuyapi/link:wizard 0 devices returned by API. +351ms ⠙ Registering devices(s)... @tuyapi/link:wizard 0 devices returned by API. +567ms ⠧ Registering devices(s)... @tuyapi/link:wizard 0 devices returned by API. +484ms ⠙ Registering devices(s)... @tuyapi/link:wizard 0 devices returned by API. +349ms ⠦ Registering devices(s)... @tuyapi/link:wizard 0 devices returned by API. +390ms ⠋ Registering devices(s)... @tuyapi/link:wizard 0 devices returned by API. +349ms ⠼ Registering devices(s)... @tuyapi/link:wizard 0 devices returned by API. +328ms ⠇ Registering devices(s)... @tuyapi/link:wizard 0 devices returned by API. +336ms ⠸ Registering devices(s)... @tuyapi/link:wizard 0 devices returned by API. +431ms ⠧ Registering devices(s)... @tuyapi/link:wizard 0 devices returned by API. +320ms ⠹ Registering devices(s)... @tuyapi/link:wizard 0 devices returned by API. +454ms ⠇ Registering devices(s)... @tuyapi/link:wizard 0 devices returned by API. +449ms ⠼ Registering devices(s)... @tuyapi/link:wizard 0 devices returned by API. +503ms ⠇ Registering devices(s)... @tuyapi/link:wizard 0 devices returned by API. +350ms ⠸ Registering devices(s)... @tuyapi/link:wizard 0 devices returned by API. +454ms ⠇ Registering devices(s)... @tuyapi/link:wizard 0 devices returned by API. +428ms ⠹ Registering devices(s)... @tuyapi/link:wizard 0 devices returned by API. +327ms ⠦ Registering devices(s)... @tuyapi/link:wizard 0 devices returned by API. +319ms ⠋ Registering devices(s)... @tuyapi/link:wizard 0 devices returned by API. +331ms ⠼ Registering devices(s)... @tuyapi/link:wizard 0 devices returned by API. +326ms ⠋ Registering devices(s)... @tuyapi/link:wizard 0 devices returned by API. +459ms ⠴ Registering devices(s)... @tuyapi/link:wizard 0 devices returned by API. +441ms ⠙ Registering devices(s)... @tuyapi/link:wizard 0 devices returned by API. +472ms ⠦ Registering devices(s)... @tuyapi/link:wizard 0 devices returned by API. +420ms ⠙ Registering devices(s)... @tuyapi/link:wizard 0 devices returned by API. +449ms ⠧ Registering devices(s)... @tuyapi/link:wizard 0 devices returned by API. +484ms ⠸ Registering devices(s)... @tuyapi/link:wizard 0 devices returned by API. +440ms ⠧ Registering devices(s)... @tuyapi/link:wizard 0 devices returned by API. +324ms ⠙ Registering devices(s)... @tuyapi/link:wizard 0 devices returned by API. +324ms ⠦ Registering devices(s)... @tuyapi/link:wizard 0 devices returned by API. +450ms ⠙ Registering devices(s)... @tuyapi/link:wizard 0 devices returned by API. +429ms ⠴ Registering devices(s)... @tuyapi/link:wizard 0 devices returned by API. +340ms ⠙ Registering devices(s)... @tuyapi/link:wizard 0 devices returned by API. +506ms ⠧ Registering devices(s)... @tuyapi/link:wizard 0 devices returned by API. +447ms ⠙ Registering devices(s)... @tuyapi/link:wizard 0 devices returned by API. +336ms ⠦ Registering devices(s)... @tuyapi/link:wizard 0 devices returned by API. +439ms ⠙ Registering devices(s)... @tuyapi/link:wizard 0 devices returned by API. +417ms ⠧ Registering devices(s)... @tuyapi/link:wizard 0 devices returned by API. +443ms ⠙ Registering devices(s)... @tuyapi/link:wizard 0 devices returned by API. +378ms ⠴ Registering devices(s)... @tuyapi/link:wizard 0 devices returned by API. +327ms ⠙ Registering devices(s)... @tuyapi/link:wizard 0 devices returned by API. +461ms ⠦ Registering devices(s)... @tuyapi/link:wizard 0 devices returned by API. +428ms ⠋ Registering devices(s)... @tuyapi/link:wizard 0 devices returned by API. +344ms ⠴ Registering devices(s)... @tuyapi/link:wizard 0 devices returned by API. +432ms ⠏ Registering devices(s)... @tuyapi/link:wizard 0 devices returned by API. +323ms ⠴ Registering devices(s)... @tuyapi/link:wizard 0 devices returned by API. +482ms ⠏ Registering devices(s)... @tuyapi/link:wizard 0 devices returned by API. +326ms ⠼ Registering devices(s)... @tuyapi/link:wizard 0 devices returned by API. +433ms ⠇ Registering devices(s)... @tuyapi/link:wizard 0 devices returned by API. +328ms ⠹ Registering devices(s)... @tuyapi/link:wizard 0 devices returned by API. +335ms ⠸ Registering devices(s)... @tuyapi/link:wizard 0 devices returned by API. +906ms ⠹ Registering devices(s)... @tuyapi/link:wizard 0 devices returned by API. +711ms ⠇ Registering devices(s)... @tuyapi/link:wizard 0 devices returned by API. +494ms ⠦ Registering devices(s)... @tuyapi/link:wizard 0 devices returned by API. +716ms ⠧ Registering devices(s)... @tuyapi/link:wizard 0 devices returned by API. +853ms ⠼ Registering devices(s)... @tuyapi/link:wizard 0 devices returned by API. +623ms ⠇ Registering devices(s)... @tuyapi/link:wizard 0 devices returned by API. +334ms ⠹ Registering devices(s)... @tuyapi/link:wizard 0 devices returned by API. +351ms ⠇ Registering devices(s)... @tuyapi/link:wizard 0 devices returned by API. +439ms ⠹ Registering devices(s)... @tuyapi/link:wizard 0 devices returned by API. +353ms ⠧ Registering devices(s)... @tuyapi/link:wizard 0 devices returned by API. +430ms ⠹ Registering devices(s)... @tuyapi/link:wizard 0 devices returned by API. +380ms ⠴ Registering devices(s)... @tuyapi/link:wizard 0 devices returned by API. +322ms ⠙ Registering devices(s)... @tuyapi/link:wizard 0 devices returned by API. +424ms ⠦ Registering devices(s)... @tuyapi/link:wizard 0 devices returned by API. +443ms ⠋ Registering devices(s)... @tuyapi/link:wizard 0 devices returned by API. +345ms ⠴ Registering devices(s)... @tuyapi/link:wizard 0 devices returned by API. +467ms ⠙ Registering devices(s)... @tuyapi/link:wizard 0 devices returned by API. +459ms ⠴ Registering devices(s)... @tuyapi/link:wizard 0 devices returned by API. +350ms ⠏ Registering devices(s)... @tuyapi/link:wizard 0 devices returned by API. +329ms ⠴ Registering devices(s)... @tuyapi/link:wizard 0 devices returned by API. +444ms ⠏ Registering devices(s)... @tuyapi/link:wizard 0 devices returned by API. +353ms ⠼ Registering devices(s)... @tuyapi/link:wizard 0 devices returned by API. +451ms ⠋ Registering devices(s)... @tuyapi/link:wizard 0 devices returned by API. +430ms ⠴ Registering devices(s)... @tuyapi/link:wizard 0 devices returned by API. +428ms ⠏ Registering devices(s)... @tuyapi/link:wizard 0 devices returned by API. +329ms ⠸ Registering devices(s)... @tuyapi/link:wizard 0 devices returned by API. +345ms ⠇ Registering devices(s)... @tuyapi/link:wizard 0 devices returned by API. +424ms ⠼ Registering devices(s)... @tuyapi/link:wizard 0 devices returned by API. +461ms ⠏ Registering devices(s)... @tuyapi/link:wizard 0 devices returned by API. +455ms ⠴ Registering devices(s)... @tuyapi/link:wizard 0 devices returned by API. +450ms ⠏ Registering devices(s)... @tuyapi/link:wizard 0 devices returned by API. +367ms ⠴ Registering devices(s)... @tuyapi/link:wizard 0 devices returned by API. +453ms ⠋ Registering devices(s)... @tuyapi/link:wizard 0 devices returned by API. +442ms ⠴ Registering devices(s)... @tuyapi/link:wizard 0 devices returned by API. +428ms ⠏ Registering devices(s)... @tuyapi/link:wizard 0 devices returned by API. +361ms ⠴ Registering devices(s)... @tuyapi/link:wizard 0 devices returned by API. +463ms ⠏ Registering devices(s)... @tuyapi/link:wizard 0 devices returned by API. +341ms ⠴ Registering devices(s)... @tuyapi/link:wizard 0 devices returned by API. +450ms ⠋ Registering devices(s)... @tuyapi/link:wizard 0 devices returned by API. +438ms ⠼ Registering devices(s)... @tuyapi/link:wizard 0 devices returned by API. +326ms ⠇ Registering devices(s)... @tuyapi/link:wizard 0 devices returned by API. +339ms ⠸ Registering devices(s)... @tuyapi/link:wizard 0 devices returned by API. +484ms ⠏ Registering devices(s)... @tuyapi/link:wizard 0 devices returned by API. +429ms ⠸ Registering devices(s)... @tuyapi/link:wizard 0 devices returned by API. +333ms ⠇ Registering devices(s)... @tuyapi/link:wizard 0 devices returned by API. +432ms ⠸ Registering devices(s)... @tuyapi/link:wizard 0 devices returned by API. +459ms ⠧ Registering devices(s)... @tuyapi/link:wizard 0 devices returned by API. +330ms ⠹ Registering devices(s)... @tuyapi/link:wizard 0 devices returned by API. +412ms ⠧ Registering devices(s)... @tuyapi/link:wizard 0 devices returned by API. +413ms ⠹ Registering devices(s)... @tuyapi/link:wizard 0 devices returned by API. +430ms ⠇ Registering devices(s)... @tuyapi/link:wizard 0 devices returned by API. +462ms ⠸ Registering devices(s)... @tuyapi/link:wizard 0 devices returned by API. +440ms ⠏ Registering devices(s)... @tuyapi/link:wizard 0 devices returned by API. +507ms ⠸ Registering devices(s)... @tuyapi/link:wizard 0 devices returned by API. +325ms ⠇ Registering devices(s)... @tuyapi/link:wizard 0 devices returned by API. +455ms ⠹ Registering devices(s)... @tuyapi/link:wizard 0 devices returned by API. +334ms ⠇ Registering devices(s)... @tuyapi/link:wizard 0 devices returned by API. +454ms ⠸ Registering devices(s)... @tuyapi/link:wizard 0 devices returned by API. +409ms ⠏ Registering devices(s)... @tuyapi/link:wizard 0 devices returned by API. +488ms ⠸ Registering devices(s)... @tuyapi/link:wizard 0 devices returned by API. +372ms ⠇ Registering devices(s)... @tuyapi/link:wizard 0 devices returned by API. +430ms ⠼ Registering devices(s)... @tuyapi/link:wizard 0 devices returned by API. +433ms ⠇ Registering devices(s)... @tuyapi/link:wizard 0 devices returned by API. +330ms ⠹ Registering devices(s)... @tuyapi/link:wizard 0 devices returned by API. +341ms ⠦ Registering devices(s)... @tuyapi/link:wizard 0 devices returned by API. +329ms ⠋ Registering devices(s)... @tuyapi/link:wizard 0 devices returned by API. +350ms ⠼ Registering devices(s)... @tuyapi/link:wizard 0 devices returned by API. +316ms ⠙ Registering devices(s)... @tuyapi/link:wizard 0 devices returned by API. +578ms ✖ Device(s) failed to be registered! Error: Timed out waiting for devices to connect. at TuyaLinkWizard.linkDevice (/usr/local/lib/node_modules/@tuyapi/cli/node_modules/@tuyapi/link/index.js:117:17) at runMicrotasks (<anonymous>) at processTicksAndRejections (internal/process/task_queues.js:93:5) at async link (/usr/local/lib/node_modules/@tuyapi/cli/lib/link.js:45:19)
I am also having this issue. Here is my info:
Mac OS 10.14.5 Node v13.8.0 (installed with Homebrew) npm 6.13.7
DEBUG=* tuya-cli link --api-key --api-secret --schema --ssid --password ***** ⠸ Registering devices(s)... @tuyapi/link:wizard Token: { region: 'AZ', secret: '1IvR', token: 'gMhLWObW' } +0ms @tuyapi/link:manual Sending SmartLink initialization packets +0ms @tuyapi/link:wizard Polling cloud for details on token... +5ms ⠇ Registering devices(s)... @tuyapi/link:wizard 0 devices returned by API. +343ms ⠙ Registering devices(s)... @tuyapi/link:wizard 0 devices returned by API. +261ms ⠴ Registering devices(s)... @tuyapi/link:wizard 0 devices returned by API. +340ms ⠏ Registering devices(s)... @tuyapi/link:wizard 0 devices returned by API. +342ms ⠸ Registering devices(s)... @tuyapi/link:wizard 0 devices returned by API. +344ms ⠧ Registering devices(s)... @tuyapi/link:wizard 0 devices returned by API. +266ms ⠏ Registering devices(s)... @tuyapi/link:manual Sending SmartLink data packets +2s ⠙ Registering devices(s)... @tuyapi/link:wizard 0 devices returned by API. +346ms ⠴ Registering devices(s)... @tuyapi/link:wizard 0 devices returned by API. +326ms ⠏ Registering devices(s)... @tuyapi/link:wizard 0 devices returned by API. +323ms ⠸ Registering devices(s)... @tuyapi/link:wizard 0 devices returned by API. +337ms ⠦ Registering devices(s)... @tuyapi/link:wizard 0 devices returned by API. +258ms ⠋ Registering devices(s)... @tuyapi/link:wizard 0 devices returned by API. +332ms ⠴ Registering devices(s)... @tuyapi/link:wizard 0 devices returned by API. +351ms ⠏ Registering devices(s)... @tuyapi/link:wizard 0 devices returned by API. +330ms ⠸ Registering devices(s)... @tuyapi/link:wizard 0 devices returned by API. +352ms ⠧ Registering devices(s)... @tuyapi/link:wizard 0 devices returned by API. +351ms ⠋ Registering devices(s)... @tuyapi/link:manual Finished sending packets. +3s @tuyapi/link:wizard 0 devices returned by API. +250ms ⠼ Registering devices(s)... @tuyapi/link:wizard 0 devices returned by API. +336ms
[...... the line above repeats many times with varying timings......]
⠧ Registering devices(s)... @tuyapi/link:wizard 0 devices returned by API. +337ms
✖ Device(s) failed to be registered!
Error: Timed out waiting for devices to connect.
at TuyaLinkWizard.linkDevice (/usr/local/lib/node_modules/@tuyapi/cli/node_modules/@tuyapi/link/index.js:117:17)
at runMicrotasks (
i get pretty much the same thing as @chadjmorgan and @Andreiovitch
@codetheweb i'm able to see that access_token
, refresh_token
, and expire_time
are properly populated - does this mean that my api-key/secret are correct?
@btoo Yes.
Besides the proper API keys, the other main requirement is being connected to an AP that will re-broadcast packets on 2.4Ghz. Networking is not my expertise, so I don't know if most APs will forward broadcast packets to 2.4Ghz if your device that's sending them is connected to its 5Ghz band.
All that to say that I'd recommend either temporarily turning off the 5Ghz band of your AP or standing up a temporary AP that only does 2.4Ghz.
@btoo when you hear it click on and off, I believe that's the device rebooting. If nothings happens after that, it means the device received the broadcasted packets successfully but either did not connect to WiFi or errored out accessing Tuya's cloud API.
There is one other possibility: Tuya's API has extremely poor documentation and it is not clear if requests have to be modified depending on what country you're in (they provide several different endpoints depending on your region for latency reasons). If the above doesn't work and you live outside the US @btoo, it'd be great if you could get a Wireshark capture to confirm whether or not the device connects to WiFi. If it does, then the problem lies with the cloud.
@Andreiovitch I'm having the exact issue :'( Please let me know if you find some sort of answer. I've been struggling all day with this.
I also got exactly the same issue. The second setup method does not work either.
Just figured out I was using 5Ghz instead of 2.4Ghz. Turned the 5Ghz off and tried again, unfortunately it still does not work. Still getting timeout error.
Just figured out I was using 5Ghz instead of 2.4Ghz. Turned the 5Ghz off and tried again, unfortunately it still does not work. Still getting timeout error.
Yeah that was the first thing I checked.
I have spaces in my WIFI-name. Might that be a problem? Do I maybe need to write "wifi_name" instead of "wifi name"? Also I am outside of the US, do I have to change anything?
I have spaces in my WIFI-name. Might that be a problem? Do I maybe need to write "wifi_name" instead of "wifi name"? Also I am outside of the US, do I have to change anything?
You could wrap your wifi-name in quotes. I too am outside of the US.
I hope someone figures this out soon....
Just to be sure I am using the right key and secret-key: those values are the AccessID and AccessKey you get after register for the Cloud API service on tuya.com, right?
I hope someone figures this out soon....
Just to be sure I am using the right key and secret-key: those values are the AccessID and AccessKey you get after register for the Cloud API service on tuya.com, right?
Correct. tuya-cli would throw an error very quickly if any of those credentials were incorrect.
I have the same problem as decribed above.
I have the same problem as decribed above, running from a Raspberry 3B with ONLY the WiFi enabled for the test.
Can connect devices in Tuya-app
Credentials are OK
Connected to a network only on 2.4Ghz
Device registration times out
I'm located in The Netherlands
Looking at Wireshark on a laptop I can see ARP broadcasts from the Raspberry, and a lot of UDP packets from it's IP address to IP Broadcast (255.255.255.255) from port 63145 to port 30011, with an occasional 'ADwin Config' (2-3 per second) packet thrown in.
BTW, I also sniffed at my DNS server, and can see that the app on my iPhone asks for a1.tuyaeu.com. (As opposed to tuya-cli, which asks for openapi.tuyaus.com)
dig openapi.tuyaeu.com returns: ; <<>> DiG 9.12.2-P1 <<>> openapi.tuyaeu.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43933 ;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1452 ;; QUESTION SECTION: ;openapi.tuyaeu.com. IN A
;; ANSWER SECTION: openapi.tuyaeu.com. 60 IN CNAME eu-out-nginx-cluster-elb-861b5115d9cb7a90.elb.eu-central-1.amazonaws.com. eu-out-nginx-cluster-elb-861b5115d9cb7a90.elb.eu-central-1.amazonaws.com. 60 IN A 52.57.138.40 eu-out-nginx-cluster-elb-861b5115d9cb7a90.elb.eu-central-1.amazonaws.com. 60 IN A 18.185.162.232 eu-out-nginx-cluster-elb-861b5115d9cb7a90.elb.eu-central-1.amazonaws.com. 60 IN A 35.157.237.14
;; Query time: 35 msec ;; SERVER: 1.1.1.1#53(1.1.1.1) ;; WHEN: Thu Feb 13 14:47:50 CET 2020 ;; MSG SIZE rcvd: 178
So it might very well be a regional thing...
From App:
# tcpdump -i em1 -pnv "host 10.0.0.156 or host 10.0.0.235" | grep tuya
tcpdump: listening on em1, link-type EN10MB (Ethernet), capture size 262144 bytes
10.0.0.235.61657 > 10.0.0.254.53: 53011+ A? a1.tuyaeu.com. (31)
10.0.0.254.53 > 10.0.0.235.61657: 53011 3/0/0 a1.tuyaeu.com. A 52.59.123.70, a1.tuyaeu.com. A 3.124.238.154, a1.tuyaeu.com. A 52.58.109.29 (79)
10.0.0.156.49153 > 10.0.0.254.53: 23230+ A? a3.tuyaeu.com. (31)
10.0.0.254.53 > 10.0.0.156.49153: 23230 3/0/0 a3.tuyaeu.com. A 18.195.249.137, a3.tuyaeu.com. A 3.121.131.36, a3.tuyaeu.com. A 18.185.182.159 (79)
10.0.0.156.49153 > 10.0.0.254.53: 56299+ A? m2.tuyaeu.com. (31)
10.0.0.254.53 > 10.0.0.156.49153: 56299 3/0/0 m2.tuyaeu.com. A 52.57.38.165, m2.tuyaeu.com. A 18.185.218.106, m2.tuyaeu.com. A 3.121.210.75 (79)
28621 packets captured
115616 packets received by filter
0 packets dropped by kernel
From Tuya-cli I never see the device come on to the network, and it keeps flashing, so there's something there as well...
With the goal of getting the device id and key, I was able to use Charles Proxy with the Smart Life app on my phone to get what I believe to be my deviceId
(and a host of other things which I'm not sure I need to be concerned about), but i still can't for the life of me find the key
.
I couldn't get it to fully work the Tuya app, but I did nevertheless see they were using the same host, a1.tuyaus.com, as expected
Only after changing the URL to tuyaeu and the src port to 51167, can I get the device to go on to the WiFi for a short period of time... There's still something missing though in the setup process, because it never shows up on the API, and it doesn't seem to do anything after it's initial ARP...
What I do notice is that when I use the APP, the device first asks the DNS server for a3.tuyaeu.com and then m2.tuyaeu.com, and when I use tuya-cli, it asks for a3.tuyaus.com, and never gets beyond that.
So it appears the domains it asks for are somewhere encoded in the data it receives from either APP or tuya-cli, and I have not yet been able to find where that happens in tuya-cli!!!
@codetheweb do you have any insight in where these parameters (a3.tuya.com and m2.tuya.com) are hidden?
Did you change the region in smart config?
I've been sick the last few days, which is why I haven't been responding.
I pushed an update to @tuyapi/cli that now allows you to pass in a region and timezone. Please upgrade and run tuya-cli link --help
for options.
@FearNaBoinne a3.tuyaus.com
isn't 'hardcoded' anywhere in tuya-cli. The actual domain we use is openapi.tuya[region].com
.
Hope you’re feeling better now!
The domain a3.tuyaus.com is requested by the Tuya bulb when using tuya-cli, but when us8ng the Tuya app it requests a3.tuyaeu.com... So that should be based on something it gets from the app or Tuya-cli. I will test the new version shortly, when I get back upstairs where my test kit is...
Both a3.tuyaus.com and openapi.tuyaus.com resolve to the same IPs, so it could just be that whatever tool you're using to sniff the traffic doesn't show all reverse IP lookup results, only the first one. 🤷♂
It's the actual DNS requests I see coming by from the bulb... I am updating tuya-cli now and will let you know after my test!
So I added '-t Europe/Amsterdam -r eu' to the link command I used before, but it still didn't find the bulb.
Here's an excerpt from a tcpdump at my firewall, which also acts as DNS and DHCP server.
10.0.0.156 is the Tuya Bulb 10.0.0.220 is the RasPi running tuya-cli
20:30:50.080141 IP (tos 0x0, ttl 64, id 42366, offset 0, flags [DF], proto UDP (17), length 64)
10.0.0.220.58609 > 10.0.0.254.53: 19205+ A? openapi.tuyaeu.com. (36)
20:30:50.080167 IP (tos 0x0, ttl 64, id 42367, offset 0, flags [DF], proto UDP (17), length 64)
10.0.0.220.58609 > 10.0.0.254.53: 20485+ AAAA? openapi.tuyaeu.com. (36)
...
20:30:50.479598 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.0.0.156 tell 10.0.0.156, length 46
20:30:50.479621 IP (tos 0x0, ttl 64, id 64302, offset 0, flags [none], proto ICMP (1), length 48)
10.0.0.254 > 10.0.0.156: ICMP echo request, id 20533, seq 0, length 28
20:30:50.487538 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.0.0.254 tell 10.0.0.156, length 46
20:30:50.487557 ARP, Ethernet (len 6), IPv4 (len 4), Reply 10.0.0.254 is-at 00:50:56:a2:2a:1e, length 28
20:30:50.496617 IP (tos 0x0, ttl 255, id 64302, offset 0, flags [none], proto ICMP (1), length 48)
10.0.0.156 > 10.0.0.254: ICMP echo reply, id 20533, seq 0, length 28
20:30:50.977548 IP (tos 0x0, ttl 64, id 57057, offset 0, flags [none], proto UDP (17), length 195)
10.0.0.254.53 > 10.0.0.220.58609: 19205 4/0/0 openapi.tuyaeu.com. CNAME eu-out-nginx-cluster-elb-861b5115d9cb7a90.elb.eu-central-1.amazonaws.com., eu-out-nginx-cluster-elb-861b5115d9cb7a90.elb.eu-central-1.amazonaws.com. A 18.185.162.232, eu-out-nginx-cluster-elb-861b5115d9cb7a90.elb.eu-central-1.amazonaws.com. A 35.157.237.14, eu-out-nginx-cluster-elb-861b5115d9cb7a90.elb.eu-central-1.amazonaws.com. A 52.57.138.40 (167)
20:30:50.977623 IP (tos 0x0, ttl 64, id 62218, offset 0, flags [none], proto UDP (17), length 229)
10.0.0.254.53 > 10.0.0.220.58609: 20485 1/1/0 openapi.tuyaeu.com. CNAME eu-out-nginx-cluster-elb-861b5115d9cb7a90.elb.eu-central-1.amazonaws.com. (201)
...
20:30:51.120578 IP (tos 0x0, ttl 255, id 2, offset 0, flags [none], proto UDP (17), length 59)
10.0.0.156.49153 > 10.0.0.254.53: 22383+ A? a3.tuyaus.com. (31)
...
20:30:51.180691 IP (tos 0x0, ttl 64, id 62815, offset 0, flags [none], proto UDP (17), length 107)
10.0.0.254.53 > 10.0.0.156.49153: 22383 3/0/0 a3.tuyaus.com. A 54.187.112.38, a3.tuyaus.com. A 34.218.147.23, a3.tuyaus.com. A 54.69.37.156 (79)
20:30:51.193902 IP (tos 0x0, ttl 255, id 3, offset 0, flags [none], proto TCP (6), length 44)
10.0.0.156.69 > 54.187.112.38.443: Flags [S], cksum 0x15ee (correct), seq 6509, win 4380, options [mss 1460], length 0
...
20:30:51.358450 IP (tos 0x0, ttl 225, id 0, offset 0, flags [DF], proto TCP (6), length 44)
54.187.112.38.443 > 10.0.0.156.69: Flags [S.], cksum 0xd8d8 (correct), seq 251778587, ack 6510, win 26883, options [mss 1460], length 0
20:30:51.365346 IP (tos 0x0, ttl 255, id 4, offset 0, flags [none], proto TCP (6), length 40)
10.0.0.156.69 > 54.187.112.38.443: Flags [.], cksum 0x487d (correct), ack 1, win 4380, length 0
20:30:51.370691 IP (tos 0x0, ttl 255, id 5, offset 0, flags [none], proto TCP (6), length 107)
10.0.0.156.69 > 54.187.112.38.443: Flags [P.], cksum 0xcfe2 (correct), seq 1:68, ack 1, win 4380, length 67
...
20:30:51.538547 IP (tos 0x0, ttl 225, id 22598, offset 0, flags [DF], proto TCP (6), length 40)
54.187.112.38.443 > 10.0.0.156.69: Flags [.], cksum 0xf052 (correct), ack 68, win 26883, length 0
20:30:51.539161 IP (tos 0x0, ttl 225, id 22599, offset 0, flags [DF], proto TCP (6), length 196)
54.187.112.38.443 > 10.0.0.156.69: Flags [P.], cksum 0xaa95 (correct), seq 1:157, ack 68, win 26883, length 156
20:30:51.573473 IP (tos 0x0, ttl 255, id 6, offset 0, flags [none], proto TCP (6), length 101)
10.0.0.156.69 > 54.187.112.38.443: Flags [P.], cksum 0xb612 (correct), seq 68:129, ack 157, win 4224, length 61
...
20:30:51.780552 IP (tos 0x0, ttl 225, id 22600, offset 0, flags [DF], proto TCP (6), length 40)
54.187.112.38.443 > 10.0.0.156.69: Flags [.], cksum 0xef79 (correct), ack 129, win 26883, length 0
20:30:51.789900 IP (tos 0x0, ttl 255, id 7, offset 0, flags [none], proto TCP (6), length 131)
10.0.0.156.69 > 54.187.112.38.443: Flags [P.], cksum 0x7089 (correct), seq 129:220, ack 157, win 4224, length 91
...
20:30:51.953549 IP (tos 0x0, ttl 225, id 22601, offset 0, flags [DF], proto TCP (6), length 40)
54.187.112.38.443 > 10.0.0.156.69: Flags [.], cksum 0xef1e (correct), ack 220, win 26883, length 0
20:30:51.953846 IP (tos 0x0, ttl 225, id 22602, offset 0, flags [DF], proto TCP (6), length 131)
54.187.112.38.443 > 10.0.0.156.69: Flags [P.], cksum 0xa2cb (correct), seq 157:248, ack 220, win 26883, length 91
...
20:30:51.995802 IP (tos 0x0, ttl 255, id 8, offset 0, flags [none], proto TCP (6), length 413)
10.0.0.156.69 > 54.187.112.38.443: Flags [P.], cksum 0x8a54 (correct), seq 220:593, ack 248, win 4133, length 373
You can see the RasPi asking for openapi.tuyaeu.com You can also see the bulb asking for a3.tuyaus.com
When I do it from the app on my phone, the bulb instead asks for a3.tuyaeu.com
Interesting is that the bulb now seems to remain on the WiFi network, whereas before it would revert to pairing mode after a short while. So there does seem to be some difference.
The reason the device asks for a3.tuyaus.com
is because it's receiving region US
from smartconfig, you must specify your region as EU
. Did you update and use the --region
flag @codetheweb added?
Incorrect assumption, yes and yes (as stated in my updates)...
My (anonymized) command is currently: DEBUG=* tuya-cli link --api-key --api-secret --schema --ssid --password *** -t Europe/Amsterdam -r eu
As noted above, you can see the RasPi asking for openapi.tuyaeu.com, which shows that the region is set correctly. You can also see the bulb still asking for a3.tuyaus.com, which shows it is getting different data somehow from tuya-cli than from the app, because with the app it asks for a3.tuyaeu.com
Just trying to help here by providing data. I'm not a noob, I can code, but am too busy atm to dig too deep in the code...
In nodemodules/@tuyapi/link/index.js I found: this.uid = await this.api.putUser({countryCode: '1', username: this.email, password: this.password, usernameType: 2});
Does this countryCode parameter do anything?
🤔 I'm kinda at a loss as to why the bulb continues to ask for the US region when the config is set to the EU.
I doubt the country code will make a difference but you can try. It's just the mobile phone prefix (so for the US it's +1
).
I tried changing it to 31 (The Netherlands, matching timezone 'Europe/Amsterdam', but that did - indeed - not change the bulb's behavior...
I'm lost as well... Looking at the documentation doesn't help much either. (And that is ignoring stupid errors in there like MOBLIE instead of MOBILE, or switching 2 parameters in the example from the description...)
Actually, y'know what: the tokens returned from the API still use the old AZ/EU/CN region encoding. Try replacing options.region
with 'EU' on line 157 in @tuyapi/link/lib/link.js.
Will do, gimme a few...
BINGO!!!!!!
But not sure whether the output is completely correct?
@tuyapi/link:wizard Found device(s)! [ { id: '***',
ip: '94.*.*.*',
name: 'LED SMART',
productId: '***',
uuid: '***' } ] +1ms
@tuyapi/link:manual Aborting broadcast of data... +7s
✔ Device(s) registered!
✖ Device(s) failed to be registered!
Error: permission deny
at OpenAPI._client.got_1.default.extend.hooks.afterResponse.response (/usr/local/lib/node_modules/@tuyapi/cli/node_modules/@tuyapi/openapi/dist/api.js:68:31)
at EventEmitter.emitter.on (/usr/local/lib/node_modules/@tuyapi/cli/node_modules/got/dist/source/as-promise.js:87:38)
at process._tickCallback (internal/process/next_tick.js:68
Nice 👍.
I stupidly forgot to use the -r
flag value when creating a new API instance to pull registered device details. Update tuya-cli
(might want to nuke node_modules
just to make sure any manual changes you've made go away) and it should be good.
I am about to go to bed, so my main PC is shut down, but wil test in the morning and update...
with the newest update of tuya-cli
i'm able to register my devices by following the setup instructions!
Totally stopped triggering the devices again for me... Still investigating!
Update: for some reason I am now getting 'AZ' region tokens, despite the region being specified!
Ok, so I nuked node_modules again and reinstalled tuya-cli with npm, and now it works... Must've somehow picked up an incorrect version...
Glad you got it working. I'll update the setup guide to include instructions about the region.
How do I update the tuya-cli package?
npm update -g @tuyapi/cli
.
Updated the package but I am still getting the same timout error.
DEBUG=* sudo tuya-cli link --api-key xxx --api-secret xxx --ssid xxx --password xxx --schema xxx -t Germany/Berlin -r eu
Getting EU back as the region, so that seems to work, but still...
Does it matter if the bulb is in slow or fast flashing mode?
I think there might be a problem with my ssid input since my wifi has spaces in its name. Do I have to put it into brackets or " or something like that? I feel like that might be the problem
It should be flashing quick. And putting quotes around the SSID should work (and for password too) It tells the cli to present that as a single parameter (it’s actually the cli that’s breaking it up at the space).
I'm getting this issue too and can't for the life of me figure out why :(
I can connect to the plug (Teckin SP27) with the Smart Life app, all devices involved are connected to 2.4GHz. I'm running a Pi 4 with openHABian - it was connected via ethernet but have since connected via wifi, don't know if this makes a difference? I'm getting a token back with EU as the region which is correct.
Forgive my ignorance, I'm no noob to tech but am very much so with command line so don't know if I'm missing something!
Same for me, still not working, also with quick flashing. I edited the link.js file and wrote my ssid and password directly into the file, so that there cannot be anything wrong with it. Still getting timeout errors.... I´m running the commands on my Pi 3B, could there be a problem with my Pi?
I´m so done 🤦♂
Ensure your RasPi is only connected by WiFi, and not also by cable! (If Eth0 is up, it'll be preferred, and send the packets out the cable instead of the WiFi... Most APs will not replay the magic packets if they come in over the LAN cable!)
Ensure your RasPi is connected to a 2.4GHz channel, or the device will be unable to see the magic packets.
On the command line issue:
iwconfig wlan0
I created a special IoT WiFi SSID on my AP mesh that is 2.4GHz only, and when I use the LINK command, I first log in to the RasPi on the WiFi IP, and then issue an ifconfig eth0 down
, and when I am done, I do ifconfig eth0 up
...
Finally, I have a few Teckin SP21's here, and gave up on them, but they also do not work reliably with the Tuya App, so I am not buying any Teckin crap anymore!
Thanks for the detailed response @FearNaBoinne but still no dice I'm afraid. Tried every step including setting up a separate SSID. As you describe having issues with Teckin it may well be the plugs - I find they do work well enough with the Smart Life app, but was hoping to integrate them into openHAB. Nevermind! Cheers
I have now successfully done this with a MOES thermostat, 2 LSC filament bulbs, 1 LSC Smartplug, and failed with all 4 Teckin plugs... The only difference I have seen between app and Tuya-CLI is that the app will repeat the magic packets after a while, but haven't dug in to that in more detail in my PCAPs... Been rather busy IRL this weekend. ;)
My long term goal is to rewrite the tuya plugins for Domoticz from pytuya to tuyapi, but if there is one thing I have too little of, it is free time... (And one thing I have too much of is things to do!)
I am still unable to connect my devices, same as original issue. Is the schema part just the Channel ID, or do you have to add something else with it?
I've followed the setup directions up to step 5, but spinner hangs on
Registering devices(s)...
and eventually throws✖ Device(s) failed to be registered! Error: Timed out waiting for devices to connect.
I'm sure I am using the correct inputs because I'm still able to connect it to the Tuya Smart app fine.
I even tried increasing the timeout directly in the source to some really high number, but that didn't seem to have any effect.
It's quite curious because, very occasionally (~10% of the tries), when running the
tuya-cli link ...
command, I will hear my device make noises which match the noises it makes when I successfully connect it to the Tuya Smart app (presumably a test for turning on/off the power). But even aftertuya-cli link
instigates this, nothing happens and the timeout error is subsequently thrown :\@codetheweb do you or anyone have advice on how to troubleshoot this? I'm willing to provide any additional info you might need. Thanks!
Desktop (please complete the following information):