Device(s) Failed to be registered! #65
Comments
|
@rbyers8252 everything sounds good... I'm not sure what shell you're using on Windows, but can you please set the environment variable |
|
Very strangely, setting the environment var DEBUG to * already did the trick for me. |
|
Not an expert with all of this. Been a long time since I did a bunch of this. How do I set the environment var debug to * ? |
|
I managed to find it for windows cmd SET DEBUG=* `- Registering devices(s)... @tuyapi/cloud Sending parameters: +202ms
with no registration |
|
If I register it through the app is it the
|
|
@BenjaminKauer if possible, could you run a few tests and see if setting @stephenmhall what's your configuration? Does the computer you're running the tool from have a (enabled) wireless card? Sometimes devices get "stuck", and unplugging then plugging them back in seems to help. |
Ok can I assume from this my PC has to be on the wifi not lan? Now I think about it of course it needs a wifi connection as it will need to connect to the plug before it gets placed on my network. Sorry fundamental misunderstanding from me there. I have wifi but disabled, I will have another go. |
|
well, a lot of it looks to be working but it never registers. `- Registering devices(s)... @tuyapi/cloud Sending parameters: +0ms
Then what looks to be 37 seconds later. `| Registering devices(s)... @tuyapi/cloud Received response: +591ms
Then the same lines over and over for another 107 seconds until, sorry couldnt get the next block to format.
|
|
After all this it might be a faulty unit. I can't register it using the Smart Life app either. Came as a pair and the first one registered fine on the app. |
|
I got this after 116 seconds trying the pre registered one. It did however remove it from the app. It was re discovered by the app ok.
|
|
@stephenmhall are you in the U.S.? If not, your issue may stem from Tuya wanting you to use a different endpoint/server than the default. I just realized this in a different issue. |
|
No I'm in the UK. So I presume I need to edit some of the default details in tuya-cli? I see the endpoints are coded into the cloud/index.js file, does the link-wizard need some extra code to select endpoint when registering. |
|
I'm also having a similar problem and am in the UK, I am able to use the Tuya app on my phone to register it without issue but I get this when trying to do it this way: Matts-MacBook-Pro:~ matt$ tuya-cli link-wizard |
|
For those in the UK: try the instructions below to see if the error is related to your region.
const TuyaLink = require('./index.js');
const register = new TuyaLink.wizard({apiKey: '<your-api-key>',
apiSecret: '<your-api-secret>',
email: 'example@example.com', password: 'example-password',
region: 'EU'});
register.init().then(sid => {
register.linkDevice({ssid: '<your-ssid>', wifiPassword: '<your-wifi-password>'}).then(devices => {
console.log(devices)
});
}).catch(err => {
console.log(err)
});
|
|
Hi Team, I am also facing similar issue, while running "tuya-cli link-wizard". It is throwing error in registering the plug with timeout error message.
bought plugs from China and it works well with Smart Life app and I am using these plugs in Norway..later it would be used in India also :). Error ✖ Device(s) failed to be registered! |
|
I'm experiencing the same issue in the states, I attempt to register but it times out waiting for it to connect to the cloud. I have this Tonbux power strip but haven't tried setting it up with an app (I was hoping to avoid that)
|
|
Has anyone in this thread:
|
|
I was getting the same timeout problem trying to register my bulb from a Raspberry Pi here in the UK. |
|
I tried registering my device three times (the third time I unplugged and plugged the device back in while the link wizard ran), didn't work. I then tried with |
|
Hello, Is there anything I can try / check? |
|
Besides the region parameter, the other one that might affect stuff is the timezone. @the-swissionary @amitn16 @lanceuppercut47 @stephenmhall Try adjusting the timezone parameter in the below code with your UTC offset and see if it works: const TuyaLink = require('./index.js');
const register = new TuyaLink.wizard({apiKey: '<your-api-key>',
apiSecret: '<your-api-secret>',
timezone: '-05:00',
email: 'example@example.com', password: 'example-password',
region: 'EU'});
register.init().then(sid => {
register.linkDevice({ssid: '<your-ssid>', wifiPassword: '<your-wifi-password>'}).then(devices => {
console.log(devices)
});
}).catch(err => {
console.log(err)
}); |
|
I've been able to register the device twice, but it takes a few hours of trying to connect. I tried changing the timezone but it's just as finicky. The default region should be ok since I'm in the US. |
|
Huh. I'm really confused because it works flawlessly for me every single time. |
|
Well, I tried the new code you sent me (try to reply to your message via email, but somehow, my reply must have gotten stuck). |
|
No joy here in UK. Tried EU region code:
Adding timezone didn't work either. |
|
I am able to do that for tuyaapi but not able to integrate with openhab.
local key you have to find using capture packet. ( capture logs while connecting smart plug 1st time iwth Smartlife or any other similar app) you would able to control switch through command line using it.. but openhab integration.. I am still struggling.. any clue.. |
|
@the-swissionary the state of your WiFi adapter shouldn't matter as long as it's enabled; the setup process works by broadcasting a series of UDP packets that are sniffed by Tuya devices. For those who are still struggling to get it to work: do you hear your device "click" during an unsuccessful setup? |
|
Mine doesn't click but I've given up using this new one until it's fixed, the old one works fine now that I know to assign an IP in the config.json |
|
If anyone is still working on this... I tried for days to make this work on my rp3 on ethernet. I disconnected the ethernet and connected it to the built in wifi. Afterwards, I was able to reconnect the ethernet and it worked. tuya-cli link-wizard set it up the first Time on both devices on wifi |
|
The key is highly encoded in a png image using an anti debugging wrapper and lots of native code. Will be unpleasant at best to extract it.
Sent from my iPhone please excuse any typos.
… On Oct 17, 2018, at 1:10 PM, Ingo Fischer ***@***.***> wrote:
This is bad ... Could it be an option to recompile the Smart Life app to get their api secret then everything could work again but with the "official smart life" accountrs from the users ...
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
I think "sharing the key" is a topic of trust because the owner of the account could access all devices and control them ... I do not know if someone is willing to share :-( Key in App: shit :-( Could it be an idea to contact them (the Tuya Cloud Guys) as "group of open source home automation developers" and ask them for maybe an "official" way supported from their side? |
|
@codetheweb For an proxy you would need to also terminate the SSL and re-encrypt before sending to the real server ... so as "charles" is doing by injecting an own root cert in the phone ... puuhhh |
|
If the app lets only are shared you still need user info to login, so should be safe. Def issues of sharing the cloud keys.
Bill
Sent from my iPhone please excuse any typos.
… On Oct 17, 2018, at 1:30 PM, Ingo Fischer ***@***.***> wrote:
I think "sharing the key" is a topic of trust because the owner of the account could access all devices and control them ... I do not know if someone is willing to share :-(
Key in App: shit :-(
Could it be an idea to contact them (the Tuya Cloud Guys) as "group of open source home automation developers" and ask them for maybe an "official" way supported from their side?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
I guess the other option is adding Tuya to Home Assistant and doing it that way.
… On 17 Oct 2018, at 9:30 pm, Ingo Fischer ***@***.***> wrote:
I think "sharing the key" is a topic of trust because the owner of the account could access all devices and control them ... I do not know if someone is willing to share :-(
Key in App: shit :-(
Could it be an idea to contact them (the Tuya Cloud Guys) as "group of open source home automation developers" and ask them for maybe an "official" way supported from their side?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
From what I remember they pin the cert, so this wouldn’t work. I’ll have to go back and verify
Bill
Sent from my iPhone please excuse any typos.
… On Oct 17, 2018, at 1:39 PM, Ingo Fischer ***@***.***> wrote:
http://anyproxy.io/en/#proxy-https ...
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
What you mean with this? Or would the idea be to have "one" account for all the Home Assistant users ... I already thourght the same for ioBroker ... |
But when capturing TLS traffic via Charles works then it should not be pinned because else also Charles would not work ... and I was also able to capture traffic using Charles with Smart Live App on iOS |
|
When I signed up for the API key I called it homebridge, if wanted we could just reuse it.
… On Oct 17, 2018, at 4:49 PM, Ingo Fischer ***@***.***> wrote:
From what I remember they pin the cert, so this wouldn’t work. I’ll have to go back and verify
But when capturing TLS traffic via Charles works then it should not be pinned because else also CHarles would not work
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
I received an email in Chinese from TUYA earlier in the week, let me see what it says.
… On Oct 17, 2018, at 6:15 PM, Northern Man ***@***.***> wrote:
When I signed up for the API key I called it homebridge, if wanted we could just reuse it.
> On Oct 17, 2018, at 4:49 PM, Ingo Fischer ***@***.***> wrote:
>
> From what I remember they pin the cert, so this wouldn’t work. I’ll have to go back and verify
>
> But when capturing TLS traffic via Charles works then it should not be pinned because else also CHarles would not work
>
> —
> You are receiving this because you are subscribed to this thread.
> Reply to this email directly, view it on GitHub, or mute the thread.
|
|
@Apollon77: The contents of the email that Tuya sent out (translated from Chinese): |
My question is, if they change this now, how future proof it will be to use it. I think the Proxy idea will be more future proof because they can kill the free API accounts any time (especially when they see "traffic" on one of them) |
agreed. I will also play around a bit with it ... I send you when I have something ... move this discussion to a new isseu? |
|
@codetheweb I played around a bit with AnyProxy and was working basically good. It generates the certificate key for your computer so nothing shared. I configured it to intercept all https traffic when host contains "tuya" and catched the response when the response contained tuya.m.my.group.device.list . then you get that full blob of data: For me this would contain anything I would need. The devices, the localkeys and also the "data schema". here the files. Install anyproxy via npm beforehand then simply execute node proxy.js ... web interface is also there for getting the certs file |
|
It’s a bit of a hassle but I just mean add Tuya devices to Home Assistant and then link Home Assistant to Homekit.
… On 17 Oct 2018, at 9:48 pm, Ingo Fischer ***@***.***> wrote:
I guess the other option is adding Tuya to Home Assistant and doing it that way.
What you mean with this? Or would the idea be to have "one" account for all the Home Assistant users ... I already thourght the same for ioBroker ...
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
For my proxy code: would be great if someone with Android could test it tinder if the json is the same ... |
|
@Apollon77 nice, thanks. I'll check it out. (The response for Android and iOS should be the same.) Created new issue #91 for discussion. @eddeandres although most people are probably using Tuya devices with HA and Homebridge, I would prefer to retain the flexibility of using other options. |
|
@eddeandres I still do not really get it ... I thought that also the python version uses the "get a free api account" idea, or not ?! If so the problems are the same in the end, or ?! |
|
You might want to anonymize the data you posted. Your home address is visible to the public. |
|
I think you just need the Tuya username and password for HA import of Tuya devices and HA natively supports HomeKit but agreed I’d rather go down the Tuya Homebridge route as it avoids the need to set it all up again.
… On 18 Oct 2018, at 10:14 pm, Ingo Fischer ***@***.***> wrote:
@eddeandres I still do not really get it ... I thought that also the python version uses the "get a free api account" idea, or not ?! If so the problems are the same in the end, or ?!
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
@eddeandres interesting ... can you point ot the HA code for that so that I can have a look?! |
|
@Apollon77 There are still latitude and longitude values in your data 😝 |
|
Was stupid post ... because wrong |
|
@eddeandres HA uses a Auth endpoint where they get a accesstoken and then use this to get device data on polling as a skill would do ... seems no way to get the localkey that way ... |
|
I just pushed an update to Unfortunately, I realized after all this while writing the documentation that Android doesn't support installing root certificates for arbitrary apps. So Android users will have to use the old setup method for now (sorry about that). If you have any ideas on getting Android to work as well, I'd love to hear them. A little sneak peak: Closing this issue. |
|
This issue should be closed (again), but regarding the reversing of the android app and pulling the key from the image see: https://github.com/nalajcie/tuya-sign-hacking It's a neat bit of work. |
and others
I've created the Tuya account and obtained the ID and Key from the site.
When I go to add a device I get the following error.
× Device(s) failed to be registered!
Error: Timed out wating for device(s) to connect to cloud
at Promise (C:\Users\xxxxxx\AppData\Roaming\npm\node_modules@tuyapi\cli\node_modules@tuyapi\cloud\index.js:275:12)
at
I'm using this smart plug https://www.amazon.com/gp/product/B07CHMDP1G/ref=oh_aui_detailpage_o09_s00?ie=UTF8&psc=1 with the Smart Life app. Running Charles on my iPhone I can confirm it's communicating through the Tuya Cloud. I put the switch in pairing mode but the wizard never finds it. Instantly can add it back to the Smart Life app though.
I use the iOS APP KEY from Tuya for apikey in the wizard and iOS APP Secret from Tuya for apisecret in the wizard. Am I doing something wrong?
The text was updated successfully, but these errors were encountered: