Gosund Flashing issue (Stuck at dev.timer.count)

[dhami220]

This is my second gosund outlet. First flashed fine, and this one gets stuck at dev.timer.count stage.

Hardware: PI (v1.2) with wifi adapter

Device firmware: 1.0.0

What have I tried:

• Old tuya2sonoff.pl scrip - same issue
• increasing timer by using -t 300 (used different amount without success)
• tuya app and smartlife app
• resetting the device to defaults in the app
• unplug/plug prior to running firmware
• Changed firmware version in the script to 9.9.0

Other observations:

• There are couple of instances of "Accepting MQTT connection, forwarding to not set". Could that be the issue?

Log:

pi@raspberrypi:~/TuyOTA $ sudo ./tuyota.pl -ip 192.168.1.8 -t 120
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 1063
Redirecting device 192.168.1.8 to use Access Point ZAGDU-789
Unable to open socket to 192.168.1.8: No route to host
The device might be at the next stage, ignoring for now
DHCP Discover b4:e6:2d:0c:be:c3 10.44.57.155
DHCP Discover b4:e6:2d:0c:be:c3 10.44.57.155
DHCP Request b4:e6:2d:0c:be:c3 10.44.57.155
Accepting MQTT connection, forwarding to
not set
**** New device detected. ID: 03200329b4e62d0cbec3 IP:10.44.57.155
**** New device looks to be part way through upgrading
**** Forcing it to retry the upgrade
Redirecting device 10.44.57.155 to use Access Point ZAGDU-789
**** Redirect appears successful
Accepting MQTT connection, forwarding to
not set
DHCP Discover b4:e6:2d:0c:be:c3 10.44.57.155
DHCP Discover b4:e6:2d:0c:be:c3 10.44.57.155
DHCP Request b4:e6:2d:0c:be:c3 10.44.57.155
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
URL: /gw.json?a=s.gw.update
Response: HTTP/1.1 200 OK
{"t":1547906672,"e":false,"success":true}
Receiving www request
URL: /gw.json?a=s.gw.dev.update
Response: HTTP/1.1 200 OK
{"t":1547906672,"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":1547906674,"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":"03200329b4e62d0cbec3","count":0,"lastFetchTime":1533399266},"t":1547906686,"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...

[SynAckFin]

Accepting MQTT connection, forwarding to
not set

That happens if the device doesn't do a DNS query for Tuya's MQTT server before attempting a connection. Its Ok in this case because just a little further you have:

Received DNS query for mq.gw.tuyaus.com.

Which means that messages will go through.
If the device doesn't ask for /gw.json?a=tuya.device.upgrade.silent.get then the script can't try to force a firmware upgrade.
What you could try is:

1. Power the device off
2. Start the script with the flags -t 300 that will tell it to spend 5 minutes waiting for the upgrade request.
3. Power on the device.

There is one more thing you could try and that is make the timeout even longer and re-provisioning (factory reset and set up with SmartLife) and set the devices Access Point as ZAGDU-789

[dhami220]

Could you elaborate on the last instruction "Set the devices access point as ZAGDU-789"?

1. Reset device by pressing button for 10 s.
2. Start script with 300 delay
3. Provision gosund w/ home wifi. When I try to provision w/ZAGDU-789 (by connecting my phone to that network), it fails because I the phone does not have internet connectivity. Should phone have internet connectivity? Maybe that is the issue.
4. there is a setting to set the device to AP in smartlife. When I try that, I get the error again that my ZAGDU fails network connectivity.

[SynAckFin]

I just tried that last one myself, doesn't look like it will work because your phone needs access to the internet.
As an alternative open a terminal and start pinging your devices ip address (even though it isn't provisioned, then as soon as there is a ping response from the IP start the script. Don't forget to specify the IP and a longer timeout.

[dhami220]

1. provisioned w/smart life
2. pings plug ip, and started the script at the same time ping responded.
3. stuck at timer.count

i didn't follow your comment "start pinging devices ip address (even though it isn't provisioned".

If the device is not provisioned, it does not have an ip address assigned and not sure which ip to ping...

thanks for taking the time to troubleshoot my issue.

In parallel, I tried turning off home assistant, pi hole, removed firewall from my router, but still getting the same issue. I am starting to believe that the firmware on this device (1.0.0) is different than the one i flashed before with your script and that is causing the device to not request the update normally.

The previous device I flashed was with tuya2sonoff.pl and using ubuntu 18.1. Do you expect that to make any difference?

[SynAckFin]

You followed the instructions correctly. I wanted you capture the traffic as as possible after provisioning just in case it sent a firmware upgrade request then.

The only other thing I can suggest is run the script again but with a very long timeout of say -t 7200 (2 hours) then just leave it running for a couple of hours.

[sylvandb]

Putting the phone on ZAGDU worked with the tuya2sonoff script because the way it set up and proxied DNS and HTTP requests provided enough functionality for the Smart Life app and the smart device. Not sure the tuyota script does as much.

[dhami220]

Ran for ~4 hrs without success.

Will try connecting to ZAGDU through phone tomorrow with tuya app (smarlife didn't work). Will keep the data on to see if phone can still provision using data and no internet through ZAGDU.

Thanks for all the tips!

[dhami220]

Something interesting happened. my plug is broadcasting "SmartLife-BEC3" hotspot (open).

Script is not detecting the device anymore. I will attempt to reset, but wait to hear if someone has any suggestion for utilizing the hotspot to fix this issue.

[SynAckFin]

You device is in AP mode for provisioning. Go into the SmartLife app and choose add new device and then choose AP mode and follow the instructions. At the end you should have a working device linked to the SmartLife app and you can then decide whether to try again.

[SynAckFin]

If any of you know how to capture the complete provisioning sequence for any of these devices failing to upgrade then it might help if you captured it and sent it to me.

By complete provisioning sequence I mean you factory reset and then reprovision using the SmartLife app and then capture about 5 minutes worth of packets to and from the device from the moment it first connects to your access point.
WARNING
The capture will contain security keys for your device but these will change the next time you re-provision. The capture might also contain information from other devices on your network if you do not apply the correct filters.

[dhami220]

I will be happy to provide that but first need to figure out how to do it :) Hopefully, google has the answer.

[SynAckFin]

The easiest way I know of is to use Network Manager to set up a fully function Access Point, provision using that access point while using tcpdump on the wlan0 to capture the traffic

[dhami220]

@SynAckFin: Will this work?

1. Setup a dedicate router, and wifi. (trying to isolate the communication, but not sure how effective this will be :).
2. Connect a phone and a computer to that wifi.
3. Start wireshark on the pc.
4. Provision plug using the phone and wifi using smartlife.
5. capture packets for 5 mins using wireshark.

Questions:

1. Looks like I can filter using the plug ip address, but that only gives ~10-15 lines per min, which basically contain the same info. I am assuming you are looking for all the logs. Any recommendation on what filter to apply so only information related to the plug is captured?

2. Would you mind giving an email where I can send the captured data? probably not a good idea to post here.

[SynAckFin]

That looks okay.
Using the IP address as a filter is okay and I'd expect an initial burst of traffic followed by about 10-15 packets per minute. Although they are mostly the same I'm hoping to pick up an indication as to why it isn't asking for the packet upgrade and what I can do to force it.
If you can save the packets as a pcap file that would be great.
You can get my email address by clicking on my name, I've added one to my profile for you to use.

[kueblc]

Hi @SynAckFin, feel free to take a look at my repo as I've already worked out a potential solution. If you have the secKey (different from localKey) you can send an upgrade message over MQTT. If you're interested in other aspects of the provisioning process I can share details of that with you too.

I'm sure you've already captured the provisioning but just so we're on the same page, and in case anyone else is interested,

1. App sends UDP packets on broadcast encoded with network credentials, a token, and a secret
2. Device decodes this and connects to your network
3. Device calls a.gw.tuyaus.com (or eu, cn) with s.gw.token.get with the token. There is no payload but the params are signed with accessKey.
4. Cloud validates the token and returns time and endpoint information
5. Device calls a.tuyaus.com (note there is no .gw) with s.gw.dev.pk.active with token and secret. The payload is encrypted and signed with accessKey.
6. Cloud assigns device keys and schema, along with a few other identifiers. secKey is used from hereon out to communicate with the cloud.
7. Device connects to Cloud MQTT at mq.gw.tuyaus.com, using secKey for AES encryption
8. Device calls a.tuyaus.com with atop.online.debug.log with the values of the exception registers. The payload is encoded and signed with secKey.
9. Cloud responds with result true. I assume this is to continue reporting, I haven't verified this.
10. The device may ask for a silent upgrade here, by a call to a.tuyaus.com with tuya.device.upgrade.silent.get. The payload, encrypted with secKey, is the etag that was assigned in step 6. If not configured for automatic upgrades (hard coded in firmware) the device will simply proceed to routine operation, including polling for timers.

[kueblc]

By the way there are two different APIs a device might call when it receives an upgrade command over MQTT. Some devices call s.gw.upgrade, some call tuya.device.upgrade.get. I haven't found a pattern just yet, my initial inkling was that one is an older version and used by older firmware, but I'm not sure that holds 100%.

[sylvandb]

On one device I was able to force an upgrade by 1) provisioning my phone and the device on the ZAGDU network created by the older tuya2sonoff script, 2) using the smartlife app to request a firmware upgrade. The script then intercepted the upgrade and marched thru the intermediate firmware, FinalStage and uploading tasmota as expected.

Unfortunately, uploading tasmota was the last of it and the device never came up with the sonoff AP and is now completely non-responsive even including no LED activity or response to the button. I suspect some bad interaction with a GPIO normally toggled as a "sonoff basic". (This was the RGB plug I noted in the failures. perhaps it has an additional MCU.)

[dhami220]

@sylvandb When I connect my phone to ZAGDU, I don't get internet connection and can't complete the provisioning process. I had data on as well, but the app ignores it and gives network connection error. How did you get around that issue?

[sylvandb]

@dhami220 the original script used Network Manager (nmcli) to create the access point, and proxied enough for the phone app and the device to think they were on a normal network. I guess it is possible the modifications I had made to the original script made that possible.

[SynAckFin]

By the way there are two different APIs a device might call when it receives an upgrade command over MQTT. Some devices call s.gw.upgrade, some call tuya.device.upgrade.get. I haven't found a pattern just yet, my initial inkling was that one is an older version and used by older firmware, but I'm not sure that holds 100%.

The tuya.device.upgrade.get request is version 4.0 of the device API, tuya.device.upgrade.silent.get is version 4.1, I dont know what version s.gw.upgrade is but there should be a v=?? embedded within the url that lets you know. The documentation for v4.0 is here. I haven't been able to find any for 4.1 or earlier version.

Hi @SynAckFin, feel free to take a look at my repo as I've already worked out a potential solution. If you have the secKey (different from localKey) you can send an upgrade message over MQTT. If you're interested in other aspects of the provisioning process I can share details of that with you too.

I did consider injecting an upgrade message via MQTT but like you say I'd need the secret key. That's why I was looking at the provisioning. I was considering having them put the device in AP mode then faking the entire provisioning so I could give the device a known key and then send an MQTT upgrade message. Unfortunately, the response to s.gw.dev.pk.active is encoded with an unknown key (accessKey) which means I can't do this.

[kueblc]

[...] faking the entire provisioning so I could give the device a known key and then send an MQTT upgrade message

This is exactly what the example script in MockTuyaCloud does with devices in pairing mode. The response is plaintext so you don't need accessKey.

[dhami220]

Got this plug tasmotized using Tuya-Convert in the first attempt.

Tried w/old PI, but wasn't able to install all the package. Switched to PI 3 B+, and the process went smoothly.

At the end, I had to remove security from the wifi to see the sonoff.

BlitzWolf SHP2 Module worked to turn on and off. LED is blinking (LED work as expected on the first plug that i had tasmotized with tuya2sonoff). I may have to put some specific command through the console to make the LED work, but it is up and running.

Thanks guys for all the hard work!!!