Controlling Tuya devices with cloud API instead of controlling them locally about tuyapi HOT 125 OPEN

In the cloud API sign is generated by:

• Sorting all the parameters it cares about[1] into alphabetical order by their key names, ignoring null valued ones.
• Joining them in the form: value1=test||value2=test||...||valuen=test
• Appending the appSecret to the string (so it becomes value1=test||value2=test||...||appSecret
• MD5 this string.

There is a special case for the parameter postData, which is done by:

• MD5'ing the JSON form data
• rearrange the ASCII encoded MD5 hash in this order: bytes[8:16] + bytes[0:8] + bytes[24:32] + bytes[16:24].

Just before you do the final MD5 of the whole string, it should look like this:
a=<action>||...||postData=<hash>||...||appSecret

[1] ["a", "v", "lat", "lon", "lang", "deviceId", "imei", "imsi", "appVersion", "ttid", "isH5", "h5Token", "os", "clientId", "postData", "time", "n4h5", "sid", "sp"]

from tuyapi.

Bill - I was using them fine for 2 days before it quit working (Exactly the same time my Android app quit working), and did all sorts of fun stuff to my account, the only thing I couldn't test was sending on/off. (my device was at the office unplugged). Bit jumbled, but here is the response for listing the devices on my account.

Code - 200String - {"result":{"devices":[{"schema":"[{\"attr\":5,\"code\":\"switch_on\",\"desc\":\"\",\"iconname\":\"icon-dp_power\",\"id\":1,\"mode\":\"rw\",\"name\":\"??????\"Notice: [App 1] # 2018-08-13 07:30:00 # Day of Week = Mondayown\",\"desc\":\"\",\"id\":2,\"mode\":\"rw\",\"name\":\"?????????\",\"passive\":true,\"property\":{\"unit\":\"???\",\"min\":0,\"max\":86400,\"scale\":0,\"step\":1,\"type\":\"value\"},\"type\":\"obj\"}]","appRnVersion":"1.0","panelConfig":{},"icon":"smart/icon/socket_new2.pNotice: [App 1] # 2018-08-13 07:45:00 # Checking Schedules"000000004w_","ability":0,"attribute":976,"iconUrl":"https://images.tuyaus.com/smart/icon/socket_new2.png","runtimeEnv":"prod","displayMsgs":{},"devId":"0320019068c63ac5d581","phase":1,"schemaExt":"[]","rnFind":false,"productId":"ahg3J1WYWKKAWA1L","dps":{"1":true,"2":0},"actNotice: [App 1] # 2018-08-13 07:45:00 # Day of Week = Monday":true,"i18nTime":1530791181409,"uiPhase":"release","localKey":"61c35fb403582d55"}],"groups":[]},"t":1534156825550,"success":true,"status":"ok"}

from tuyapi.

You have to apply to https://developer.tuya.com/user/cloud to get an accesskey. i will update this thread once i have more details. but if anyone has additional ideas, please let me know

from tuyapi.

I believe the MD5 hash is the same as what's implemented in TuyAPI (see here), although I could be wrong.

from tuyapi.

@bahorn thank you for the reply. i will try this as soon as i get the accesskey from tuya.
This is funny though. their instructions at https://docs.tuya.com/en/cloudapi/cloud_access.html#access-mode are incorrect. they do tell you to sort, but they use only one | and the access key is in the front and not the back of the string.

from tuyapi.

Also one thing i was not aware of is that the postData is part of the MD5 hash to generate the sign. thank you

from tuyapi.

@bahorn May I ask where did you get this information for the cloud API sign ?

I just got my accessKey and keySecret from Tuya and I have tried both your method and the instructions on Tuya, that @michmike said. Using PostMan, I tried doing API requests and end up getting the following response after multiple tries:

{
    "t": 1517217462399,
    "success": false,
    "errorCode": "SING_VALIDATE_FALED_4",
    "status": "error",
    "errorMsg": "Parameter or Data Error"
}

If I wish to send postData, for example to turn on my application, could you perhaps share a screenshot or collection in PostMan of what needs to be sent? I've spent hours on this to no avail.

from tuyapi.

@dominicklee I just recorded on my old phone (android old enough so i could have a root certificate for fiddler) so i got all the information about resquest&post-data + responses.

I have recorded the following scenarios with the official SmartLife app:

• Connecting with auto-connect (saved password in app-data) & going all the way to log-out
• Connecting with mobile-no + password & going all the way to log-out
• Connecting with mobile-no + sms-code & going all the way to log-out
• From main menu, removing a device
• From main menu, adding a device

I will need a little time to format everything (and scramble some personnal info before making it public) but i will make all the info available, maybe tonight (GMT -5) if I have time

The only thing i'm not able to record is the action on the device. If I click to turn it on or off, nothings happens in fiddler, so no HTTP request seams to be made to the server, it must be something else. I checked for UDP on the network and it's not that either. So that's the part I did not figure out !

from tuyapi.

@dominicklee I stripped down my personal Python implementation that should clear up the issues.
https://gist.github.com/bahorn/9bebbbf37c2167f7057aea0244ff2d92

@Ericmas001 Devices are controlled by MQTT. Use Wireshark to log it, you can set a filter for just MQTT.

Just to explain more of how this works, when you attempt to login you are given:

• a token
• A RSA public key
• An exponent for this key.

You construct the RSA key given and use it to encrypt the MD5(all 128 bits encoded as hex) of your password. This is then padded and then sent on to the server (along with the token). If the login details are correct, you get returned a session ID for use in other mobile requests. Worth noting is the "ecode" and the "p10001" thing that are returned along with the session ID, which you need to login to the MQTT server.

After you login, you should make a call to "tuya.m.device.my.list" to get a list of devices, their uuids and local keys. With this, you can then connect to their MQTT server to issue commands.
MQTT login details are of the form:
Username: pThing+"_"+appKey+"_mb_"+sessionID+md5(md5(appKey)+ecode)[8:24]
Password: MD5(MD5(appSecret)+ecode)[8:24]

from tuyapi.

I would like to update that I have tried the methods as mentioned by @bahorn and sadly I have received "PERMISSION_DENIED" with the access keys that I have been given. I don't exactly understand why this does not work. Perhaps Tuya is limiting the cloud API access to the respective companies who ordered custom devices.

If anyone got the Tuya cloud REST API working on a no-name (generic) Tuya device, please let me know.

from tuyapi.

https://github.com/Ericmas001/Tuya-Api-Tools/wiki/Requests

I scrambled some info and applied a little formatting to my fiddler outputs (I did not do it manually, of course a little script helped me 😃)
So you can see all the Requests/Responses that were sent.

There is more information than needed, but it's never too much when you try to understand something 😃

@bahorn The appKey and appSecret, can they be seen on those request or taken from existing app, or I really need to apply for one at the Tuya API Team ?

from tuyapi.

@Ericmas001 wow, that looks like it was a lot of work - thank you. The API keys I thought were sent in HTTP/HTTPS requests to Tuya's servers, but from your requests it looks like that isn't the case.

from tuyapi.

@Ericmas001 the clientId is actually the accessKey which Tuya app uses. But you will not be able use any Tuya Cloud API without knowing the keySecret, which is technically in the md5 hashed sign.

Unless you can decode the sign, which is virtually impossible, you won't be able to get the keySecret.

And as said, I rightfully requested for a set of API credentials from Tuya and tried them. They apparently do not give me permission to do anything on any generic devices.

from tuyapi.

Also, one more things you guys should understand is that Tuya devices can be controlled via both MQTT and HTTPS API. However, their app chose to use MQTT for some reason, which explains why actions could not be recorded in an HTTP sniffer.

from tuyapi.

I've done a bit of wiresharking between my phone, device and tuya cloud using the eFamilyCloud app and I can successfully decode all of the MQTT messages from the device using my device key.

The MD5 example on the Tuya site is not 100% accurate and needs some modification to get the MD5 hash that the site shows out the other end. I think their formatting in the code boxes is a bit messed up.

I can login to the cloud and subscribe to MQTT queues using the mqttfx app and if I send a control action from my phone, I can see it appear in the subscription queue and then decode the message using a PowerShell script I wrote. Wireshark shows your username and password in the MQTT connect message in plain text.

I've tried reversing this and constructing a message to send to the MQTT queue using the same method but unfortunately it just gets dropped by the server. I'm pretty sure that I'm signing the message in the same way that the eFamilyCloud app does so I had got to the point where I thought there must be some set up done over HTTPS before the MQTT conversation starts. My decode script decodes both genuine MQTT data and my own constructed data in the same way.

I've gone as far as exporting a conversation between my phone and the cloud (which successfully controls the device) and then another conversation between mqttfx and the cloud with my encoded data (which doesn't work) and the MQTT conversation looks identical (bar the data and IPs etc.)

It's possible that I'm not encoding the 'data' json part of the message correctly.

When I get a few minutes, I'll tidy up the encode/decode PowerShell scripts and publish them.

Turns out I had a few minutes, here's where I got with the encode/decode

https://github.com/bobalob/PS-Tuya-Tools

from tuyapi.

@bobalob I'm a MQTT total noob, so maybe this makes no sence, but does MQTT have some kind of headers, like HttpHeaders, that could be different, something like a userAgent that would be blocked or i don't know ...

from tuyapi.

@Ericmas001 You can extract them from the many apps, which was discussed early on in #5. In the app I looked at I found the signing process was dumped in the android logs, which includes the AppSecret and AppKey. (Look for "SignRequest" or something on that line.)

I was able to send messages directly to their MQTT server using the paho-mqtt Python library. I just logged in using details I took from packet captures (I only later figured out how usernames/passwords were generated). The app actually supports MQTT over TLS but never uses it for some reason.

Worth noting that you can actually replay messages sent over MQTT as the time is actually ignored (or at least by the devices I used).

@bobalob Are you sending it to the topic "smart/mb/out/"? You code for producing messages seems correct but I don't have a Windows box on me right to verify. The first commented out template is what I've used to control devices.

@dominicklee I actually didn't know the Cloud/App API supported that. I thought it would fall back to it when I forced everything though a HTTP proxy but it never did so I assumed they didn't support it.

I tested the tuya.m.device.dp.publish action yesterday and was able to turn the light on/off.

Just wondering, did you modify my code to use any of the cloud actions listed on https://docs.tuya.com/en/cloudapi/cloudAPI/index.html
I only ever got an "PERMISSION_DENIED" when attempting to use an action that wasn't a mobile one (where my API key was from). I assume cloud Keys can't access mobile ones as well.

from tuyapi.

@bahorn I'm impressed that you were able to use tuya.m.device.dp.publish to turn lights on/off. I actually requested for cloud keys but for some reason I could not get those to work with the cloudAPI in doing the dp.device publish. See image for details

from tuyapi.

@bahorn You have successfully got the app access working it seems. However, the cloud access for API is not exactly the same, and that is what I am trying to figure out.

from tuyapi.

@dominicklee
I just made some progress on getting the cloud API working literally 30 seconds ago.
Turns out they actually were doing something different. (The secret was being added to the start of signing string?!).
Each endpoint is specific to the type of key though.

Just got a call to both tuya.p.weather.city.info.list and tuya.cloud.device.get working.

Code:
https://gist.github.com/bahorn/160b4143badd1b6fae61cec629fce339

from tuyapi.

@bahorn Yes, I was publishing on the "smart/mb/out/devId" while subscribed to smart/mb/in and another topic pXXXXXX/mb/euXXXXXXXX. I wasn't aware you could replay a message from the phone. I did try that but that also got dropped. Perhaps the application I'm using is doing something weird or I'm missing something.

from tuyapi.

@Ericmas001 there are headers in the packet for various MQTT controls like message type, flags, QoS, retain etc. I'm setting those all the same as the app does.

from tuyapi.

@bahorn and @Ericmas001 Thank you guys for your helpful inputs! I have been able to to get Tuya mobile API working using your code examples and hints. Although I still haven't been able to control devices with the Tuya Cloud API, I feel the mobile API would do just as well in terms of controlling devices.

To confirm and clear up any confusion, the mobile API is signed as:
a=tuya.m.device.dp.publish||clientId=<accessKey>||lang=en||os=Android||postData=<your request JSON md5>||sid=<needed for dp actions>||time=<unix time in seconds>||v=1.0||<keySecret>

For mobile, you will need to be logged in (with an SID provided) to perform actions.

While the Tuya Cloud API is signed as:
<keySecret>a=tuya.cloud.device.dp.publish|clientId=<accessKey>|lang=en|os=Linux|postData=<your request JSON md5>|time=<unix time in seconds>|v=1.0

Both API credentials are different. However, even if you request the cloud API credentials for Tuya, they will only allow you to access only the devices you manufacture with them. If you are able to get the API keys for another working app, that may work but it goes beyond the scope of this issue.

from tuyapi.

@bahorn have you been able to use the mobile or cloud API to control the devices as well?

I have yet to try what @dominicklee mentioned where you can use the API versus MQTT to control the power plug

from tuyapi.

@dominicklee I'd love to see your progress. Any chance you have a fork hosted somewhere with these changes?

from tuyapi.

I like the idea of this library using LOCAL control over Cloud control. Of course, having both options would be ideal, giving the user choice, and providing failover if one isn't available.

Another nice aspect of getting at least SOME of the Cloud API worked out... the Cloud API returns deviceID and localKey for all devices. Having this piece in place would keep people from having to wireshark their keys and would act as a "discovery" mode of sorts.

from tuyapi.

@dlashua right, it would be ideal if a user could just sign in with the same username & password and be able to control all their devices.

I'm planning to add cloud control of devices as optional functionality if this ever works. (Meaning, TuyAPI will default to controlling stuff locally unless told otherwise by the user.)

from tuyapi.

That's perfect! I applied for the Cloud API Key 3 days ago so that I could help get this underway, but I've yet to get info from them and my application still shows as "under review".

It's a shame they didn't make this a little bit easier. Tuya products are EVERYWHERE, they work quite well (as long as you use their permissions laiden apps), and are fairly inexpensive. And all that's "missing" is some documentation, and a way to easily access localKey.

There are several big downsides to the cloud approach as Tuya presents it. As best as I can tell, you'll need to perform a "tuya.cloud.user.sync" for each user that wishes to use the cloud through your key. Additionally, at that point, that cloud account will have access (without a password, from that point on) to that user's devices. So, this means 1) you can't put the Cloud API creds directly in the library or else everyone will have access to everyone else's devices, 2) because of this, a intermediate API will need to be developed for the library to hit, 3) this API will have to be hosted somewhere ($$$) and publically available, 4) users will have to trust this cloud service with their credentials.

Another option will be to require that every user seek their own Cloud API credentials, but, as you can see from my experience, this doesn't cater to the "I want it now" mentality, as I've been waiting three days with no response.

from tuyapi.

@dominicklee You mentioned "they will only allow you to access only the devices you manufacture with them" From what I can tell (and I am coming late to the game) you can only access devices that you register with them. So you could register a device from any manufacturer on your account and get the keys. What this means is if you want to share one of their apps with your implementation (say the Smart Life app) you would actually need those keys. But if you are ok registering the devices yourself, it should work with any device you purchase, but other apps (again such as Smart Life) would not see or have access to those devices. Does that make sense and match what you've seen so far?

from tuyapi.

Has someone made some progress on this, since? I'd like to control a power switch via script.

from tuyapi.

Yep, it's now possible with my new tuyapi/cloud package. Look at the Tuya docs for endpoints specific to controlling devices.

Although this should work, I haven't actually tried it, so let me know what happens @shoeper.

from tuyapi.

Hi everyone,
I'm fairly new to this and I am currently doing a project for university. I've tried to get the access ID and the ACCESS KEY for the cloud API from Tuya but was unable to.
I was wondering if there is anyway to by pass the access ID and access key and just control the devices locally (i.e. no cloud access needed)?

from tuyapi.

from tuyapi.

Hi all:

I'm new to Tuya. I'm trying to use Mobile API to control a device. I did get Cloud API's accessKey and accessSecret. but it does not seem to work with Mobile API.
Here are my questions

1. Can API key/secret of Cloud API used in Mobile API (App API)? If not, how do I get the key/secret of Mobile API?
2. I tried calling tuya.m.user.email.password.register and tuya.m.user.email.password.login. It seems the user account generated by Cloud API is not the same as the SmartLife app account. Can I use Mobile API to access the user account of SmartLife app?

I've already spent a few days but could not get it going anywhere. Any help/hint is appreciated.

from tuyapi.

from tuyapi.

@BillSobel Thanks for clarification. I managed to get appKey and appSecret to make some calls but having trouble in adding devices. More questions

1. If a device has been activated by other app like SmartLife, can it still be activated in my keyspace?
2. How to add/activate the device? I can think of two ways
   a. Device API has a device activation function but it requires some authKey(?) for signing.
   b. Build a mobile app from sdk with appKey/appSecret then activate the device.
   Is there another way?

from tuyapi.

from tuyapi.

@llee2015 check out @tuyapi/link. The built-in token generator function is currently not working; so you'd have to use the .manual() class instead of the .wizard() class. If you can figure out how to generate tokens (it stopped working for me a few weeks ago), it'd be great if you could post the code for doing so.

from tuyapi.

@codetheweb Thanks. So Tuya changed their protocols recently? I'll try registering the device with Mobile app first then look into the UDP way. Will share if I figure out anything useful.

from tuyapi.

from tuyapi.

Hi everyone,
Any one are able to get the correct response of the apis using postman tool ???
If not using postman tool direct api.
I have used the direct api of tuya apis following the code of <[https://github.com/TuyaInc/TuyaDemo/tree/master/cloud-sign/src/main/java] Using this link I got the sign value and I pasted that sign value directly in the postman tool as below

I cant understand why I'm getting "errorCode": "SING_VALIDATE_FALED_4" error like this can any one please help me out. In which case do I get like this

I have given the password by converting to MD5 encryption for example if give password as qdrttt12:
96fbfb9539dc68401908d4bdb2d36721.

Can any one tell me where am I giving wrong details.

Are the apis are get the response using MQTT. If Yes please tell me.

from tuyapi.

@janakigarimella the json payload should be
{
"postData": {
"countryCode":"...",
"email":"...",
"passwd":""
}
}

from tuyapi.

@llee2015 .Thanks for your help but again getting the same response after giving the values of postdata in the postman tool as suggested.Please look at the screen shot is there any thing else missing.

{
"postData": {
"countryCode":"91",
"email":"[email protected]",
"passwd":"96fbfb9539dc68401908d4bdb2d36721"
}
}

given in the postman tool.

client id given from the APP KEY from Edit .

Response:
{
"t": 1533111254008,
"success": false,
"errorCode": "SING_VALIDATE_FALED_4",
"status": "error",
"errorMsg": "Parameter or Data Error"
}

from tuyapi.

@janakigarimella Sorry i made a mistake in the previous response.

1. The POST payload should be
   postData={"countryCode:"...", "email": "...", passwd:"..."}

2. HTTP command content-type has to be "application/x-www-form-urlencoded"

from tuyapi.

Does anyone happen to know how long an SID will last? Does it expire? Thanks!

from tuyapi.

Using android sdk of tuya how they are controlling devices in outside network. Which line compares the inside and outside network and where this line exists. I have created a sample project to their devices.When I goto outside network it shows like Network error and command is not sent sucessfully.

from tuyapi.

@Sytanek don't have any hard numbers for you, but an issued SID lasts for at least ~5 minutes. I'm guessing it works for much longer than that; I just haven't tried an operation that runs for more than 5 minutes yet. 😃

@janakigarimella are you asking how the official Tuya app controls devices when the controlling phone isn't on the same network? If so, the phone calls Tuya's API to control devices from the cloud instead of sending packets locally.

from tuyapi.

@codetheweb thanks! Hrmm, just noticed my official smart life app just an update and also required two factor to log in....and your test script is returning an error to update my app to a newer version. Wonder if they swapped keys, or if the API is changing...

from tuyapi.

@Sytanek I wouldn't be surprised if the API's changed, they seem to have changed it in the past with no warning (can't actually confirm, as I was originally using their API in non-intended ways).

What test script are you talking about, and what's the specific error code?

from tuyapi.

@codetheweb @Sytanek Hey guys, its been a while since I touched those devices. But for your information, I just tested mine and it seems their API is still very much working. So even if updates were made, their old documentation still stands well.

from tuyapi.

At least with the devices I have, they are all functional. Now, if you are suggesting that their firmware is updated, I haven't tried updating the firmware on any of my devices. I will try it and let you know.

from tuyapi.

@codetheweb I am using the nodejs cloud library for testing, with some additional logging added. (I'm actually implementing the mobile api for a proprietary embedded system, so it's been extremely helpful to be able to see where I am screwing up). I "borrowed" the keys from smart life app while implementing my code (I have my own, but easier to use something I know is already working). I was just about to test turning on/off, and got the following error. Launched the Android app and noticed app itself quit working and was forcing me to update giving the same error as below. Once I updated the app, I tried logging in using email and password, and it required me to get a sms with verification code (I think this is just an app requirement, not API)..... Going to try my own mobile api keys next with the existing code. (Though it is interesting the API must have some mechanism for minimum app version, although I didn't see mentioned, and not sure what it is using as the basis).

{ t: 1534207449836,
success: false,
errorCode: 'APP_NEED_UPGRADE',
status: 'error',
errorMsg: 'Please upgrade your app to the latest version' }

Update: It appears my mobile keys work just fine, so the upgrade requirement must be on an app by app basis. I will use mine from now on.

from tuyapi.

@Sytanek 👍 glad you got it figured out.

from tuyapi.

Have spent a bit of time looking through the new apps source code. Haven't been able to identify what part of the api call is allowing them to know what version of the app is running. They are sending quite a bit more as part of the login postdata. I did find mention of a new 2.0 api call for registering that was introduced, and an unpublished api call for upgrading user data. (Not sure why / when this is called yet)

from tuyapi.

from tuyapi.

from tuyapi.

Bill, I was just going through the cloud(technically mobile) api. I decompiled the app, started with the UI Login Form and worked my way backwards through all the method calls and returns. You are right, that It is possible they are older keys, or keys they shouldn't have left active, but they worked with the tuyacloud library, as well as my own code for over a week and two app versions. I did check and the set of keys I used are still in the new app, but the new app is sending quite a bit more data on login. Verified the keys are still accurate through CharlesProxy.

from tuyapi.

@codetheweb found documentation in the tuya sample sdk that says session id is 45 days with no activity. (Or until it errors/expires for any other random reason)

from tuyapi.

Using postman I have been trying to get the list of devices but I am getting error as "SING_VALIDATE_FALED_4" I am not sure when I am doing wrong can anyone please suggest us how to get list of devices in that account
and I am creating sign code with "a=tuya.cloud.user.device.list|time=1534846626|lang=en|v=1.0|os=Linux|clientid=yj83p8srh48ar8aestxq|postData={“countryCode”:“91”} "
Using postman I am using below API

https://a1.tuyacn.com/api.json?a=tuya.cloud.user.device.list&time=1534846626&lang=en&v=1.0&os=Linux&clientid=yj83p8srh48ar8aestxq&sign=760B7F3B96A59545B8E9E1274BAF5417&postData={“countryCode”:“91”}

Error:

{
"t": 1534849171288,
"success": false,
"errorCode": "SING_VALIDATE_FALED_4",
"status": "error",
"errorMsg": "Parameter or Data Error"
}

I tried getting users list but same issue
Sign code with

"a=tuya.cloud.user.list|time=1534850428|lang=en|v=1.0|os=Linux|clientid=rqpatuk4nqpafyujpj7s|parameter={"strartTime": "1534850428","endTime": "1534850990.699","offset": 0,"limit": 1}"

Using postman I am using below API

POST: https://a1.tuyacn.com/api.json?a=tuya.cloud.user.list&time=1534850428&lang=en&v=1.0&os=Linux&clientid=rqpatuk4nqpafyujpj7s&sign=E434CDE9D17937A84615440559B549D5&parameter={"strartTime": "1534850428","endTime": "1534850990.699","offset": 0,"limit": 1}

Error:
{
"t": 1534852817119,
"success": false,
"errorCode": "SING_VALIDATE_FALED_4",
"status": "error",
"errorMsg": "Parameter or Data Error"
}

from tuyapi.

I have been working this a bit and have gotten it to work with the API services.

@uttamraj143 you are using the ” (slanted quotes) which give the "data error". Instead use the " (straight quotes) in the postData={“countryCode”:“91”}. I had the same issue for a long time.

from tuyapi.

You need the secret key for the device to manage it locally, you get that by registering the device with the cloud api. So if you can intercept the traffic and see the key you can access the devices locally, otherwise you do need the cloud access keys. Did you sign up and request them? I found they were fairly easy to get.
…
On Mon, Jul 23, 2018 at 2:53 AM, JohnRambo93 @.***> wrote: Hi everyone, I'm fairly new to this and I am currently doing a project for university. I've tried to get the access ID and the ACCESS KEY for the cloud API from Tuya but was unable to. I was wondering if there is anyway to by pass the access ID and access key and just control the devices locally (i.e. no cloud access needed)? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#20 (comment)>, or mute the thread https://github.com/notifications/unsubscribe-auth/ADLj6K04kyVNuEEDTkwalYjOfTna5fqxks5uJYDmgaJpZM4Rsiok .

Hi, once you have local key - how to make request to Turn On/Off?

from tuyapi.

Hey I was wondering ... Would it be possible to redirect the mqtt trafic to a local broker check what is send to them and then just resend command ?

from tuyapi.

from tuyapi.

yes but I could make a rule in my router to redirect the trafic to my local broker ...

from tuyapi.

from tuyapi.

I also just found that article ... I think MQTT is the way to go for some devices types.

The only unknown topic is: what is the password. I tried some things, but was not successfull :-(

Infos I found is:

I think they mean 16 chars :-) but the localKey is it not :-(

Anyone an idea?

from tuyapi.

IF you are just wanting to control devices you can follow the example from TuyaInc on github.

Auth: https://github.com/TuyaInc/TuyaDemo/blob/master/open-mq-sdk/src/main/java/com/tuya/open/sdk/mq/MqAuthenticationDataProvider.java

Messaging: https://github.com/TuyaInc/TuyaDemo/blob/master/open-mq-sdk/src/main/java/com/tuya/open/sdk/mq/MqConsumer.java

They show how to build your authentication and how to sub to a topic. In the above two references.

from tuyapi.

@uDude What is "AccessId" and "AccessKey" in these examples? Soma API Ids and stuff? Or local encryption keys or something we can get out of the JSOns the APPs get?

from tuyapi.

I forget the which key is which, but I believe it was outlined in https://docs.tuya.com/en/cloudapi/device_access.html

I think, emphasis on think -- not certain, that they are the deviceID and the deviceKey.

from tuyapi.

Bill, I was just going through the cloud(technically mobile) api. I decompiled the app, started with the UI Login Form and worked my way backwards through all the method calls and returns. You are right, that It is possible they are older keys, or keys they shouldn't have left active, but they worked with the tuyacloud library, as well as my own code for over a week and two app versions. I did check and the set of keys I used are still in the new app, but the new app is sending quite a bit more data on login. Verified the keys are still accurate through CharlesProxy.

@BillSobel Did you figure out what was causing Tuya from thinking the "app is outdated"? What can be done to fix that?

from tuyapi.

@BillSobel I tried changing the version to 2.0 just to log in. But for some reason, calling the tuya.m.device.list request will return an "API version error". Does this mean this new version does not support that action, or did they change the API parameters? Does anyone find any published documentation from Tuya on this new mobile update?

from tuyapi.

from tuyapi.

from tuyapi.

Has anyone here got their API v2.0 to work? Have they fully switched to MQTT only or do they still have REST API access to control devices?

This change they did is really affecting my projects

from tuyapi.

Was anyone able to get and access? I tried a year or so ago and got no response.

from tuyapi.

Apparently not. I'm not sure whether their MQTT protocol is still the same. I don't see their API v2.0 being documentated. If anyone believes otherwise, please share the link.

They have bad programmers who slack on the documentation and close people out.

from tuyapi.

Hi!!
I got this info :
devid= 2047***d9448
localkey =faf4ceb8f
what should be the next step to control my device remotely by third party software ( Postman..) ?
Thanks

from tuyapi.

@Ericmas001 Could you please update to the latest SmartLife app on your old phone that has Fiddler and show us what request parameters are being sent for login and turning a device on/off?

Its been months that Tuya did not update their documentation for the 2.0 version API - I believe they unofficially decided to make it closed source. If anything, they removed their 1.0 version API documentation! This is ridiculous. Also, whatever docs they have online right now will not help at all. The "api key" that you get from them does not give access to anything except for the devices you designed yourself, not something you bought on Amazon (or other 3rd party).

I'm determined to figure this out for the sake of data. Tuya apparently gets to track your data on their cloud but they don't let you even control your devices openly. They are the unethical ones here.

from tuyapi.

@BillSobel What keys are you using nowadays? The "borrowed keys" or your own? And if you got mobile keys from Tuya, please shed some light on how you got them.

from tuyapi.

from tuyapi.

I got them from Tuya. Just signed up for an account and sent them my justification (writing home control plugin for HomeSeer). They authorized me within a week or so. Sent from my iPhone please excuse any typos.
…
On Feb 2, 2019, at 1:22 PM, Dominick Lee @.***> wrote: @BillSobel What keys are you using nowadays? The "borrowed keys" or your own? And if you got mobile keys from Tuya, please shed some light on how you got them. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

Hey @BillSobel , I got the token, but when I try to control the device I receive this answer:

{
"code": 2010,
"msg": "device not exist",
"success": false,
"t": 1549147492375
}
What I do wrong ?

from tuyapi.

from tuyapi.

from tuyapi.

@Orneeman What keys is it? Mobile or cloud API? Tuya used to have some documentation but removed alot of the pages. I think this page still has some good references: https://docs.tuya.com/en/cloudapi/cloud_access.html

Carefully read through everything and use Postman. This does take some decent time and trial/error unless you know what you're doing.

from tuyapi.

I got them from Tuya. Just signed up for an account and sent them my justification (writing home control plugin for HomeSeer). They authorized me within a week or so. Sent from my iPhone please excuse any typos.
…
On Feb 2, 2019, at 1:22 PM, Dominick Lee @.***> wrote: @BillSobel What keys are you using nowadays? The "borrowed keys" or your own? And if you got mobile keys from Tuya, please shed some light on how you got them. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

@BillSobel I just sent Tuya a message. Hopefully they will give some good keys. I'm sure our implementations are correct.

from tuyapi.

@Orneeman What keys is it? Mobile or cloud API? Tuya used to have some documentation but removed alot of the pages. I think this page still has some good references: https://docs.tuya.com/en/cloudapi/cloud_access.html

Carefully read through everything and use Postman. This does take some decent time and trial/error unless you know what you're doing.

@BillSobel I have the API key that means I can control my device via Postman?

from tuyapi.

from tuyapi.

Does anyone know how home assistant did the integration via python? Somehow their calls only require username, password and country. Did they do their own backend to encapsulate all these?

from tuyapi.

I checked that: It seems they registered and use an API that is also used by Alexa Skills or something like that. But because of this they only know basic information and control options

from tuyapi.

I am trying to connect cloud API user sync interface then I am facing this kind of response. Anyone know about it, please tell me.

Responce:
{'t': 1549606678728, 'success': False, 'errorCode': 'BIZTYPE_INVALID', 'status': 'error', 'errorMsg': 'API is not supported, please use the latest version.'}

Thanks.

from tuyapi.

from tuyapi.

The error literally tells you what is wrong. You are calling a depreciated api version. Bill Sent from my iPad please excuse any typos
…
On Feb 7, 2019, at 10:21 PM, Christhu @.***> wrote: I am trying to connect cloud API user sync interface then I am facing this kind of response. Anyone know about it, please tell me. Responce: {'t': 1549606678728, 'success': False, 'errorCode': 'BIZTYPE_INVALID', 'status': 'error', 'errorMsg': 'API is not supported, please use the latest version.'} Thanks. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

I am using API version 1.0

This my request

{'a': 'tuya.cloud.user.sync', 'os': 'Linux', 'v': '1.0', 'clientId': 'xxxxxxx', 'lang': 'en', 'time': 1549606677, 'postData': '{"countryCode": "91", "username": "[email protected]", "passwd": "xx", "nick": "", "usernameType": 2}', 'sign': '211b4026884cd871ed25f04ce24bc5d6'}

@BillSobel

from tuyapi.

from tuyapi.

The Tuya docs leave much to be desired. My advice is when you see something like this, go to the docs and change to the Chinese version (/cn in url vs /en) the try bumping the version number manually. Why not linked correctly the 2.0 docs are here for that api https://docs.tuya.com/cn/cloudapi/cloudAPI/tuya.cloud.user.sync_2.0.html Sent from my iPad please excuse any typos
…
On Feb 7, 2019, at 10:31 PM, Christhu @.> wrote: The error literally tells you what is wrong. You are calling a depreciated api version. Bill Sent from my iPad please excuse any typos … On Feb 7, 2019, at 10:21 PM, Christhu @.> wrote: I am trying to connect cloud API user sync interface then I am facing this kind of response. Anyone know about it, please tell me. Responce: {'t': 1549606678728, 'success': False, 'errorCode': 'BIZTYPE_INVALID', 'status': 'error', 'errorMsg': 'API is not supported, please use the latest version.'} Thanks. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread. I am using API version 1.0 This my request {'a': 'tuya.cloud.user.sync', 'os': 'Linux', 'v': '1.0', 'clientId': 'xxxxxxx', 'lang': 'en', 'time': 1549606677, 'postData': '{"countryCode": "91", "username": @.***", "passwd": "xx", "nick": "", "usernameType": 2}', 'sign': '211b4026884cd871ed25f04ce24bc5d6'} — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

Thanks, @BillSobel I cross the BIZTYPE_INVALID error.

Now I am facing the new error I send a request like,
{'a': 'tuya.cloud.user.sync', 'os': 'Linux', 'v': '2.0', 'clientId': 'xxx', 'lang': 'en', 'time': 1549610606, 'postData': '{"schema": "tuyasmart", "countryCode": "91", "username": "[email protected]", "passwd": "xx", "nick": "rajchristhu", "usernameType": 2}', 'sign': 'e7a20e4a072225acd7081c5a3ee08a0d'} {}

And I am getting a response PERMISSION_DENIED,

{'t': 1549610607753, 'success': False, 'errorCode': 'PERMISSION_DENIED', 'status': 'error', 'errorMsg': 'No permission'}

any idea about it @BillSobel

from tuyapi.

from tuyapi.

I am using Cloud API key getting from TUYA website dashboard @BillSobel

from tuyapi.

I am using Cloud API key getting from TUYA website dashboard @BillSobel

This is my credential can I using this Access ID and Key then I implement the register
(tuya.m.user.email.register)

My request:

https://a1.tuyacn.com/api.json {'a': 'tuya.m.user.email.register', 'os': 'Linux', 'v': '1.0', 'clientId': 'myID', 'lang': 'en', 'time': 1549622235, 'postData': '{"countryCode": "91", "email": "[email protected]", "passwd": "password123"}', 'sign': '2d6c877015ab143a154ef5bd1ed9844a'}

My Responce:

{'t': 1549622242495, 'success': False, 'errorCode': 'BIZTYPE_INVALID', 'status': 'error', 'errorMsg': 'API is not supported, please use the latest version.'}

Please clarify this error.
DOCS:
https://docs.tuya.com/en/cloudapi/appAPI/userAPI/tuya.m.user.email.register_1.0.html
https://docs.tuya.com/cn/cloudapi/appAPI/userAPI/tuya.m.user.email.register_1.0.html
@BillSobel

Thanks.

from tuyapi.

@rajchristhu I only started playing with cloud stuff last night and too be honest this thread is just making more confused. But in my journeys the only valid biztypes I found were are 'tuya' and 'smart_life'. But I maybe talking about a completely different API than you or everyone else is.

What is the current state of play of things
I had a quick play with a couple cloud repos and I thought they were doing the same thing but there were a few differences and I'm not sure if they are just separate APIs with similar implantations.

I did manage to get a key from the Tuya site for tuyapi/cloud but the Tuya site said they have a limited life and supply. Anyway I got a bit lost after running the three introduction commands and getting my token.
I did have more sucess with a python tuyapy setup. https://pypi.org/project/tuyapy/ . You just need your normal smart life or tuya app login, it's really simple and easy for people to set up. I managed to create a njs script which lets you log in a similar way to tuyapy does it.

• Am I correct in thinking that tuyapi/cloud only lets you log in using the dev keys from their site?
• Is it possible to login using your normal tuya cloud email and pass on tuyapi/cloud? Or are they kind of separate things?

from tuyapi.

@unparagoned from looking at the source for that Python module, it appears Tuya set up a special URL for Home Assistant users that doesn't require API keys. If someone wants to take a look at that and make a PR to do the same thing for tuyapi/cloud I'm happy to merge it.

You're right, at this point tuyapi/cloud only works with API keys that you get off Tuya's developer site. I didn't know the above method was feasible at the time (but I suspect the Home Assistant integration is somewhat limited).

In general, Tuya user accounts are always associated with a company's API keys; which is why I didn't think it was possible to authenticate solely with a user account.

from tuyapi.

@codetheweb I did give it a good go, but it was pretty much impossible to work in the change to tuyapi/cloud. It feels like they are using completely different apis. It almost feels like they have some sort of helper function sitting in the middle translating queries to the normal api. So I just worked on getting something working. I can now see the state of the devices and set the states to on/off.
It's all relatively simple, apart from the fact the type of POST requests need to be of a very specific type and the settings for getting a token don't work for getting or setting states.
https://github.com/unparagoned/cloudtuya

from tuyapi.