search

SynAckFin / TuyOTA

Flashing Tuya devices with Tasmota firmware.
GNU General Public License v3.0
88 stars 13 forks source link

"Globe" Branded Smart Bulb #9

Open mssmison opened 5 years ago

mssmison commented 5 years ago

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.

pi@raspberrypi:~/TuyOTA $ sudo ./tuyota.pl
Getting interface into stable state
RTNETLINK answers: Cannot assign requested address
RTNETLINK answers: Cannot assign requested address
Done
Using WiFi device wlan0 for Access Point
Starting Access Point with SSID ZAGDU-789
Giving Access Point IP address 10.44.57.1, pid is 1598
Redirecting device 192.168.1.10 to use Access Point ZAGDU-789
Unable to open socket to 192.168.1.10: No route to host
The device might be at the next stage, ignoring for now
DHCP Discover 80:7d:3a:3a:ce:ba 10.44.57.230
DHCP Discover 80:7d:3a:3a:ce:ba 10.44.57.230
DHCP Request 80:7d:3a:3a:ce:ba 10.44.57.230
Received DNS query for a.gw.tuyaeu.com.
Sending 10.44.57.1 as response
Receiving www request
URL: /gw.json?a=s.gw.token.get
Response: HTTP/1.1 200 OK
{"t":1547951445,"e":false,"success":false,"errorCode":"SING_VALIDATE_FALED_TOKEN_EXPIRE","errorMsg":"非法请求"}
Shutting down...
Setting up IP Address 192.168.4.2 for Final Stages
Getting interface into stable state
RTNETLINK answers: Cannot assign requested address
Done
Setting up wifi scan
Setting up listener for FinalStage
Shutting down...
Getting interface into stable state
RTNETLINK answers: Cannot assign requested address
Done
Finished
Exiting....
Shutting down...
damondins commented 5 years ago

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.

SynAckFin commented 5 years ago

If you are prepared to edit the script then try changing about line 277 from:

my $payload = sprintf('{"passwd":"%s","ssid":"%s","token":"EUb6IPWXYTn455"}',$Password,$SSID);

to my $payload = sprintf('{"passwd":"%s","ssid":"%s","token":""}',$Password,$SSID); and see what happens.

damondins commented 5 years ago

@SynAckFin just made the edit and same result.

Getting interface into stable state RTNETLINK answers: Cannot assign requested address RTNETLINK answers: Cannot assign requested address Done Using WiFi device wlan0 for Access Point Starting Access Point with SSID ZAGDU-789 Giving Access Point IP address 10.44.57.1, pid is 13971 Redirecting device 192.168.1.169 to use Access Point ZAGDU-789 Redirect appears successful New device detected. ID: 42300042dc4f22edcef2 IP:192.168.1.152 New device detected. ID: 04200320dc4f222e83f4 IP:192.168.1.169 Asking device to move networks and upgrade... Redirecting device 192.168.1.169 to use Access Point ZAGDU-789 Unable to open socket to 192.168.1.169: No route to host The device might be at the next stage, ignoring for now New device detected. ID: 5700118884f3eb1d3064 IP:192.168.1.129 DHCP Discover dc:4f:22:2e:83:f4 10.44.57.231 New device detected. ID: 42300042dc4f22edd01d IP:192.168.1.140 DHCP Discover dc:4f:22:2e:83:f4 10.44.57.231 New device detected. ID: 00662375b4e62d5be578 IP:192.168.1.175 New device detected. ID: 0620047984f3eb4331fa IP:192.168.1.159 New device detected. ID: 07440243bcddc2fae50b IP:192.168.1.116 New device detected. ID: 0720024884f3eb0058b3 IP:192.168.1.119 New device detected. ID: 01200949ecfabc87ca64 IP:192.168.1.128 DHCP Request dc:4f:22:2e:83:f4 10.44.57.231 **** Device 04200320dc4f222e83f4 has changed IP from 192.168.1.169 to 10.44.57.231 Received DNS query for mq.gw.tuyaus.com. Sending 10.44.57.1 as response Accepting MQTT connection, forwarding to mq.gw.tuyaus.com. Received DNS query for a.tuyaus.com. Sending 10.44.57.1 as response Receiving www request Fetching Request Content URL: /gw.json?a=s.gw.update Response: HTTP/1.1 200 OK {"t":1547987388,"e":false,"success":true} Receiving www request Fetching Request Content URL: /gw.json?a=s.gw.dev.update Response: HTTP/1.1 200 OK {"t":1547987388,"e":false,"success":true} Receiving www request Fetching Request Content URL: /gw.json?a=atop.online.debug.log Response: HTTP/1.1 200 OK {"result":true,"t":1547987392,"e":false,"success":true} Receiving www request Fetching Request Content URL: /gw.json?a=s.gw.dev.timer.count Response: HTTP/1.1 200 OK {"result":{"devId":"04200320dc4f222e83f4","count":0,"lastFetchTime":0},"t":1547987403,"e":false,"success":true} Shutting down... Setting up IP Address 192.168.4.2 for Final Stages Getting interface into stable state RTNETLINK answers: Cannot assign requested address Done Setting up wifi scan Setting up listener for FinalStage Shutting down... Getting interface into stable state RTNETLINK answers: Cannot assign requested address Done Finished Exiting.... Shutting down...

damondins commented 5 years ago

I just pulled the newest TuyOTA script and now I'm getting this

Getting interface into stable state RTNETLINK answers: Cannot assign requested address RTNETLINK answers: Cannot assign requested address Done Using WiFi device wlan0 for Access Point Starting Access Point with SSID ZAGDU-789 Giving Access Point IP address 10.44.57.1, pid is 29401 Redirecting device 192.168.1.169 to use Access Point ZAGDU-789 Redirect appears successful New device detected. ID: 07440243bcddc2fae50b IP:192.168.1.116 New device detected. ID: 0720024884f3eb0058b3 IP:192.168.1.119 New device detected. ID: 01200949ecfabc87ca64 IP:192.168.1.128 New device detected. ID: 42300042dc4f22edcef2 IP:192.168.1.152 New device detected. ID: 5700118884f3eb1d3064 IP:192.168.1.129 New device detected. ID: 42300042dc4f22edd01d IP:192.168.1.140 New device detected. ID: 00662375b4e62d5be578 IP:192.168.1.175 New device detected. ID: 0620047984f3eb4331fa IP:192.168.1.159 DHCP Discover dc:4f:22:2e:83:f4 10.44.57.33 DHCP Request dc:4f:22:2e:83:f4 10.44.57.33 New device detected. ID: 04200320dc4f222e83f4 IP:10.44.57.33 New device looks to be part way through upgrading Forcing it to retry the upgrade Redirecting device 10.44.57.33 to use Access Point ZAGDU-789 **** Redirect appears successful Received DNS query for mq.gw.tuyaus.com. Sending 10.44.57.1 as response Received DNS query for mq.gw.tuyaus.com. Sending 10.44.57.1 as response Received DNS query for mq.gw.tuyaus.com. Sending 10.44.57.1 as response Received DNS query for mq.gw.tuyaus.com. Sending 10.44.57.1 as response DHCP Discover dc:4f:22:2e:83:f4 10.44.57.33 DHCP Request dc:4f:22:2e:83:f4 10.44.57.33 Received DNS query for mq.gw.tuyaus.com. Sending 10.44.57.1 as response Accepting MQTT connection, forwarding to mq.gw.tuyaus.com. Received DNS query for a.tuyaus.com. Sending 10.44.57.1 as response Receiving www request Fetching Request Content URL: /gw.json?a=s.gw.update Response: HTTP/1.1 200 OK {"t":1547988461,"e":false,"success":true} Receiving www request Fetching Request Content URL: /gw.json?a=s.gw.dev.update Response: HTTP/1.1 200 OK {"t":1547988461,"e":false,"success":true} Receiving www request Fetching Request Content URL: /gw.json?a=atop.online.debug.log Response: HTTP/1.1 200 OK {"result":true,"t":1547988463,"e":false,"success":true} DHCP Request f0:fe:6b:41:8d:8e f0:fe:6b:41:8d:8e: Unknown host Bad arg length for Socket::pack_sockaddr_in, length is 0, should be 4 at /usr/lib/arm-linux-gnueabihf/perl/5.24/Socket.pm line 157, <$fh> line 15. Exiting.... Shutting down...

SynAckFin commented 5 years ago

Progress has been made you are no longer getting the SING_VALIDATE_FALED_TOKEN_EXPIRE

Bad arg length for Socket::pack_sockaddr_in, length is 0, should be 4 at /usr/lib/arm-linux-gnueabihf/perl/5.24/Socket.pm line 157, <$fh> line 15.

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

damondins commented 5 years ago

I renamed the directory and ran git clone https://github.com/SynAckFin/TuyOTA it created the new folder so should be...

damondins commented 5 years ago

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 --2019-01-20 07:18:21-- https://github.com/SynAckFin/TuyOTA/raw/master/static/image_user2-0x81000.bin Resolving github.com (github.com)... 192.30.253.112, 192.30.253.113 Connecting to github.com (github.com)|192.30.253.112|:443... connected. HTTP request sent, awaiting response... 302 Found Location: https://raw.githubusercontent.com/SynAckFin/TuyOTA/master/static/image_user2-0x81000.bin [following] --2019-01-20 07:18:22-- https://raw.githubusercontent.com/SynAckFin/TuyOTA/master/static/image_user2-0x81000.bin Resolving raw.githubusercontent.com (raw.githubusercontent.com)... 151.101.48.133 Connecting to raw.githubusercontent.com (raw.githubusercontent.com)|151.101.48.133|:443... connected. HTTP request sent, awaiting response... 200 OK Length: 239220 (234K) [application/octet-stream] Saving to: ‘image_user2-0x81000.bin’

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 --2019-01-20 07:18:22-- https://github.com/SynAckFin/TuyOTA/raw/master/static/sonoff.bin Resolving github.com (github.com)... 192.30.253.113, 192.30.253.112 Connecting to github.com (github.com)|192.30.253.113|:443... connected. HTTP request sent, awaiting response... 302 Found Location: https://raw.githubusercontent.com/SynAckFin/TuyOTA/master/static/sonoff.bin [following] --2019-01-20 07:18:23-- https://raw.githubusercontent.com/SynAckFin/TuyOTA/master/static/sonoff.bin Resolving raw.githubusercontent.com (raw.githubusercontent.com)... 151.101.48.133 Connecting to raw.githubusercontent.com (raw.githubusercontent.com)|151.101.48.133|:443... connected. HTTP request sent, awaiting response... 200 OK Length: 482512 (471K) [application/octet-stream] Saving to: ‘sonoff.bin’

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 RTNETLINK answers: Cannot assign requested address RTNETLINK answers: Cannot assign requested address Done Using WiFi device wlan0 for Access Point Creating Access Point config file hostapd.conf Starting Access Point with SSID ZAGDU-789 Giving Access Point IP address 10.44.57.1, pid is 3558 Redirecting device 192.168.1.169 to use Access Point ZAGDU-789 Redirect appears successful New device detected. ID: 42300042dc4f22edd01d IP:192.168.1.140 New device detected. ID: 00662375b4e62d5be578 IP:192.168.1.175 New device detected. ID: 0620047984f3eb4331fa IP:192.168.1.159 New device detected. ID: 07440243bcddc2fae50b IP:192.168.1.116 New device detected. ID: 0720024884f3eb0058b3 IP:192.168.1.119 New device detected. ID: 01200949ecfabc87ca64 IP:192.168.1.128 New device detected. ID: 42300042dc4f22edcef2 IP:192.168.1.152 New device detected. ID: 04200320dc4f222e83f4 IP:192.168.1.169 Asking device to move networks and upgrade... Redirecting device 192.168.1.169 to use Access Point ZAGDU-789 Unable to open socket to 192.168.1.169: No route to host The device might be at the next stage, ignoring for now New device detected. ID: 5700118884f3eb1d3064 IP:192.168.1.129 DHCP Discover dc:4f:22:2e:83:f4 10.44.57.80 DHCP Discover dc:4f:22:2e:83:f4 10.44.57.80 DHCP Discover dc:4f:22:2e:83:f4 10.44.57.80 DHCP Discover dc:4f:22:2e:83:f4 10.44.57.80 DHCP Discover dc:4f:22:2e:83:f4 10.44.57.80 DHCP Discover dc:4f:22:2e:83:f4 10.44.57.80 DHCP Discover dc:4f:22:2e:83:f4 10.44.57.80 DHCP Request f0:fe:6b:41:8d:8e 10.44.57.176 DHCP Discover dc:4f:22:2e:83:f4 10.44.57.80 DHCP Discover dc:4f:22:2e:83:f4 10.44.57.80 DHCP Discover dc:4f:22:2e:83:f4 10.44.57.80 DHCP Discover dc:4f:22:2e:83:f4 10.44.57.80 DHCP Discover dc:4f:22:2e:83:f4 10.44.57.80 DHCP Discover dc:4f:22:2e:83:f4 10.44.57.80 DHCP Discover dc:4f:22:2e:83:f4 10.44.57.80 DHCP Request dc:4f:22:2e:83:f4 10.44.57.80 **** Device 04200320dc4f222e83f4 has changed IP from 192.168.1.169 to 10.44.57.80 Received DNS query for mq.gw.tuyaus.com. Sending 10.44.57.1 as response Accepting MQTT connection, forwarding to mq.gw.tuyaus.com. Received DNS query for a.tuyaus.com. Sending 10.44.57.1 as response Receiving www request Fetching Request Content URL: /gw.json?a=s.gw.update Response: HTTP/1.1 200 OK {"t":1547990381,"e":false,"success":true} Receiving www request Fetching Request Content URL: /gw.json?a=s.gw.dev.update Response: HTTP/1.1 200 OK {"t":1547990382,"e":false,"success":true} Receiving www request Fetching Request Content URL: /gw.json?a=atop.online.debug.log Response: HTTP/1.1 200 OK {"result":true,"t":1547990385,"e":false,"success":true} Receiving www request Fetching Request Content URL: /gw.json?a=s.gw.dev.timer.count Response: HTTP/1.1 200 OK {"result":{"devId":"04200320dc4f222e83f4","count":0,"lastFetchTime":0},"t":1547990396,"e":false,"success":true} Shutting down... Setting up IP Address 192.168.4.2 for Final Stages Getting interface into stable state RTNETLINK answers: Cannot assign requested address Done Setting up wifi scan Setting up listener for FinalStage Shutting down... Getting interface into stable state RTNETLINK answers: Cannot assign requested address Done Finished Exiting.... Shutting down...

damondins commented 5 years ago

SingHong Tunable White experiencing the same issue. I changed the token and it doesnt error on that but same result

SynAckFin commented 5 years ago

That looks better. Unfortunately your device isn't asking for an upgrade. You will see the following when it does: URL: /gw.json?a=tuya.device.upgrade.silent.get This is the same issue as #8 and we haven't found a way around it yet.

damondins commented 5 years ago

Ok will wait to see what is figured out

damondins commented 5 years ago

@SynAckFin Have you seen this?

@kueblc also has a tool to speed up the process through MQTT calls to force an upgrade https://github.com/kueblc/mocktuyacloud

damondins commented 5 years ago

Did some more digging on the failed token

Received DNS query for a.gw.tuyaeu.com. Sending 10.44.57.1 as response Receiving www request URL: /gw.json?a=s.gw.token.get Response: HTTP/1.1 200 OK {"t":1548144879,"e":false,"success":false,"errorCode":"SING_VALIDATE_FALED_TOKEN_EXPIRE","errorMsg":"非法请求"}

"非法请求" Translation: "errorMsg":"API or API version is incorrect"

This is the line of code that needs to be fixed my $response = pack("nnnnnn",$ident, 0x8180, 1, 1, 0, 0);

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)

drushbrook commented 5 years ago

I changed the token to 1LhrIv9P

I'm now getting an ILLEGAL_REGION error.

Getting interface into stable state RTNETLINK answers: Cannot assign requested address Done Using WiFi device wlan0 for Access Point Starting Access Point with SSID ZAGDU-789 Giving Access Point IP address 10.44.57.1, pid is 10267 Redirecting device 172.28.5.145 to use Access Point ZAGDU-789 **** Redirect appears successful DHCP Discover 80:7d:3a:37:86:17 10.44.57.77 DHCP Request 80:7d:3a:37:86:17 10.44.57.77 Received DNS query for a.gw.tuyaus.com. Sending 10.44.57.1 as response Receiving www request URL: /gw.json?a=s.gw.token.get Response: HTTP/1.1 200 OK {"t":1548161257,"e":false,"success":false,"errorCode":"ILLEGAL_REGION","errorMsg":"非法可用区"} Receiving www request URL: /gw.json?a=s.gw.token.get Response: HTTP/1.1 200 OK {"t":1548161260,"e":false,"success":false,"errorCode":"ILLEGAL_REGION","errorMsg":"非法可用区"} Receiving www request URL: /gw.json?a=s.gw.token.get Response: HTTP/1.1 200 OK {"t":1548161264,"e":false,"success":false,"errorCode":"ILLEGAL_REGION","errorMsg":"非法可用区"} Receiving www request URL: /gw.json?a=s.gw.token.get Response: HTTP/1.1 200 OK {"t":1548161267,"e":false,"success":false,"errorCode":"ILLEGAL_REGION","errorMsg":"非法可用区"} Receiving www request URL: /gw.json?a=s.gw.token.get Response: HTTP/1.1 200 OK {"t":1548161270,"e":false,"success":false,"errorCode":"ILLEGAL_REGION","errorMsg":"非法可用区"}

SynAckFin commented 5 years ago

This is the line of code that needs to be fixed my $response = pack("nnnnnn",$ident, 0x8180, 1, 1, 0, 0);

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. At the moment I am trying to find a way around this. There are several things you could try. In all cases make sure the device has been provisioned using the app. The first one is to extract the token when it is provisioned by the app and then try using that token. The second is to try an empty token ("token":"") and the third is to try a null token ("token":null).

mssmison commented 5 years ago

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?

SynAckFin commented 5 years ago

In order capture the token you would need to use something like aircrack-ng to capture and decode the packets and then use wireshark to analyse/view them. There is an alternative method of installing new firmware developed by @kueblc which is detailed here.

drushbrook commented 5 years ago

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

mssmison commented 5 years ago

@SynAckFin yeah I'm working with @kueblc as well using his mocktuyacloud

@drushbrook I'm guessing no luck?

drushbrook commented 5 years ago

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 ;)

Jason2866 commented 5 years ago

@drushbrook There is an alternative methode of installing alternative firmware. Take a look here https://github.com/ct-Open-Source/tuya-convert/

drushbrook commented 5 years ago

@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.

SynAckFin commented 5 years ago

They have now changed the default to sonoff-classic-vtrust.bin which automatically connects to the vtrust-flash access point. My recommendation is that you download sonoff-basic and point the thirdparty.bin softlink to it.

Jason2866 commented 5 years ago

If you managed to get this script running you will handle it easily to compile you own Tasmota version. The benefit would be all your wanted settings (wifi, timezone, mqtt broker setup...) is already in. The device will work without any further configuration after power cycle. So do as @SynAckFin told you and use your Tasmota version :-)