Closed pocki80 closed 4 years ago
Hi, I'm the original contributor of the new tuya cloud API
You may try my CLI script which I've developed to push data from Tuya cloud into my influx/grafana instance: https://github.com/nalajcie/tuya-cloud-to-influxdb
I converted my tuya devices to tasmota because it was easier to integrate them into my smart home that way - so I don't have any device for testing currently.
The script works, but returns empty list of the devices (I suspect they deleted it after some time of inactivity). You may run it with debug enabled, so You will see all of the params sent to the remote server, eg.:
DEBUG=* ./cli.js list
(you may use the same trick with Your own scripts, as most of the output is the debug info from @tuyapi/cloud) It might be also as the message states - the servers were busy at that time and it You repeat Your query - You will receive a meaningful response.
thx - i now managed to get the devices list by skipping the first call and adding the groupid directly to the second call. Looks like the API accepts only one action request, then raising that error starting the second action. Maybe there's the need to renew some token or sid or key?
btw: i also tried tuya-cloud-to-influxdb code, but it fails to login using ./cli.js auth mymailaddress mypassword
. It doesnot work with a username, neither.
Ok, I don't know what You're doing differently as my script just calls api.loginEx({email, password})
(the API region is initialized to be EU
but it shouldn't matter, you will be redirected to other server on login success if that would be necessary).
No token renewal is needed in new API (I've successfully used tuya-cloud-to-influxdb
a few minutes ago and it was possible to do multiple API requests within single session (authorization) without any issues.
See some tips regarding how to debug it here: https://github.com/nalajcie/tuya-cloud-to-influxdb/issues/3#issuecomment-681715935
You may also try to change countryCode
in loginEx implementation to the correct code for You (currently hardcoded as 48
(Poland) as it was not relevant while developing the new API originally), maybe this is the problem?
Actually, changing countryCode in @tuyapi/cloud
source code from 'EU'
to '43'
makes it work again. Looks like that porject confuses regionCode and countryCode.
This may be the new requirement of the API server (we don't know as this API is undocumented).
Edit: I see that I have also local changes - I'm sending 48
for countryCode
for tuya.m.user.email.token.create
and tuya.m.user.email.token.create
. After that I use "EU" as a countryCode
and it works.
Can You confirm that everything is working if You initialize API with region='43'
and hard-code the endpoint
in initializer?
If so - maybe You can prepare PR which allows to initialize custom endpoint
and allows passing any region
possible - and fallbacks to region
check (must be then AZ, AY or EU) if endpoint
is not explicitly given? The documentation would have to be updated as well.
@pocki80 you may also want to try @tuyapi/openapi if it works for your use case. It should be more stable and better supported since it uses an official API.
Yeah, it would be much better.
My use case was to get hourly/daily/monthly energy usage from the Tuya-based socket.
I tried OpenAPI and these attributes were not available by it (searching through the docs it seems that they are still unavailable -only instantaneous V, I and P - https://docs.tuya.com/en/iot/open-api/standard-function/electrician-category/categorykgczpc/s?id=K9gf7o5prgf7s ).
It turns out that the energy is not computed on the Tuya device itself, just aggregated in the cloud (so: no internet, no/invalid energy usage) - this was main reason to switch to Tasmota (energy computed in-device).
to solve this you have to add a requestId
if (this.apiEtVersion) {
pairs.et = this.apiEtVersion;
pairs.ttid = 'tuya';
pairs.requestId=uuidv4();
}
I use the example code from your "new" API method. After the successful login I can successfully fetch
tuya.m.location.list
.But then, the request
api.request({action: 'tuya.m.my.group.device.list', gid: group.groupId})
causes the response"success":false,"errorCode":"REPEATED_REQUEST","status":"error","errorMsg":"The server is busy, please try again later"
thus the operation fails.