"Globe" Branded Smart Bulb about tuyota

[damondins]

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]

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]

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

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]

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]

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

[damondins]

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]

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

[SynAckFin]

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]

Ok will wait to see what is figured out

[damondins]

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

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]

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]

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]

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]

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]

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]

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

@drushbrook I'm guessing no luck?

[drushbrook]

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]

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

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

[SynAckFin]

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]

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