"Globe" Branded Smart Bulb #9
Comments
|
I'm getting the same thing with the lombex bulb and the ChiHope outlet strip. I'm able to reprovision to the smartlife app afterward but can't get it to go further. The chiHope has a TYWE3S Module. I'm not sure if that could be an issue or not. |
|
If you are prepared to edit the script then try changing about line 277 from: to |
|
@SynAckFin just made the edit and same result. Getting interface into stable state |
|
I just pulled the newest TuyOTA script and now I'm getting this Getting interface into stable state |
|
Progress has been made you are no longer getting the SING_VALIDATE_FALED_TOKEN_EXPIRE
This a bug that I thought I'd fixed a couple of days ago (#2). Are you sure you have the latest version from the master repository? https://raw.githubusercontent.com/SynAckFin/TuyOTA/master/tuyota.pl |
|
I renamed the directory and ran git clone https://github.com/SynAckFin/TuyOTA it created the new folder so should be... |
|
ok so rebooted and reran the script after reconnecting the device to smartlife and the error is gone but back to the 1st issue.... Stage One firmware not found, downloading it image_user2-0x81000 100%[===================>] 233.61K --.-KB/s in 0.1s 2019-01-20 07:18:22 (2.13 MB/s) - ‘image_user2-0x81000.bin’ saved [239220/239220] Stage Two firmware not found, downloading it sonoff.bin 100%[===================>] 471.20K 2.58MB/s in 0.2s 2019-01-20 07:18:23 (2.58 MB/s) - ‘sonoff.bin’ saved [482512/482512] Getting interface into stable state |
|
SingHong Tunable White experiencing the same issue. I changed the token and it doesnt error on that but same result |
|
That looks better. Unfortunately your device isn't asking for an upgrade. You will see the following when it does: |
|
Ok will wait to see what is figured out |
|
@SynAckFin Have you seen this? @kueblc also has a tool to speed up the process through MQTT calls to force an upgrade |
|
Did some more digging on the failed token Received DNS query for a.gw.tuyaeu.com. "非法请求" Translation: This is the line of code that needs to be fixed Here is some of the data I found on tuya's site that may be related. looks like there is an update command. Also could there be different tokens for each of their servers? POST /gw.json?a=s.gw.token.get&gwId=01200950ecfabc795eb3&other={“token”:“7wBxo260”,“region”:“AZ”,“tlinkStat”:{“configure”:“smartconfig”,“time”:6,“source”:“station”,“path”:“multicast”}}&t=7&v=3.0&sign=cd5c887908064c32c8f8185ac32ffbf5 HTTP/1.1 POST /gw.json?a=s.gw.dev.pk.active&gwId=01200950ecfabc795eb3&other={“token”:“7wBxo260”}&t=1523597921&v=3.0&sign=84da2c27ddbf551ec2f0938c0790c7d6 HTTP/1.1 (application/x-www-form-urlencoded) POST /gw.json?a=s.gw.update&gwId=01200950ecfabc795eb3&t=1523598924&v=2.0&sign=01468796fe75f6b66f2e5a8e67533349 HTTP/1.1 (application/x-www-form-urlencoded) POST /gw.json?a=atop.online.debug.log&gwId=01200950ecfabc795eb3&t=1523578928&sign=56d0cf5a79efac8fc4fde30f7a4740e5 HTTP/1.1 (application/x-www-form-urlencoded)strong text POST /gw.json?a=s.gw.dev.timer.count&gwId=01200950ecfabc795eb3&t=1523578939&sign=dc95e227bbd7bd6ca5036e1c68cd99f4 HTTP/1.1 (application/x-www-form-urlencoded) |
|
I changed the token to 1LhrIv9P I'm now getting an ILLEGAL_REGION error. Getting interface into stable state |
That line doesn't have anything to do with the tuya API. It is crafting a DNS response to the devices DNS query. The token is part of the way a device is linked to the app and your account. When a device is provisioned via the app the app generates a random token and communicates this token to the cloud (it expires after a short period of time). It also sends this token to the device together with your SSID and password. The device then connects to your WiFI network and talks to the tuya cloud using this token. The cloud then associates the device with the app because of the shared token. Configuration information and encryption keys are then sent to both the device and app. Once the encryption keys are sent then neither the device nor the app use the token again. What was discovered is that if the device had been provisioned and a packet was sent to the device with a new SSID, password and token then the device would move to that WiFi network and not try to provision again, that is, it would ignore the token. Unfortunately it looks like this isn't true for all devices and it seems your device tries to restart provisioning again. Since the token isn't valid you are getting the TOKEN errors. |
|
I tried tonight with "token":null and "token":"" but both resulted in the same. I'm totally up for extracting the token when it's provisioned. Any idea on how I'd do that? |
|
I have already attempted the token generated on provisioning the device. I used Package Capture on Android to capture the traffic between the app and it's api's |
|
@SynAckFin yeah I'm working with @kueblc as well using his mocktuyacloud @drushbrook I'm guessing no luck? |
|
No luck.. but I got further with the Tuya-Convert process. I ended up bricking the device so off to the shops tonight to buy some more ;) |
|
@drushbrook |
|
@Jason2866 - yes already all over it and discovered it 8 hours ago and have one bricked device (because I used the default third party - at the time was tasmota-minimal) and another semi bricked. I know I can use alternative firmwares using a different url. |
|
They have now changed the default to |
|
If you managed to get this script running you will handle it easily to compile you own Tasmota version. |
Trying to get this bulb updated tonight with the latest version. I think it's the token expire that's the issue, but not sure on how to resolve that one. The script does make the bulb go into pairing mode it seems though.
The text was updated successfully, but these errors were encountered: