Closed dhami220 closed 5 years ago
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:
-t 300
that will tell it to spend 5 minutes waiting for the upgrade request.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
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.
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.
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?
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.
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.
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!
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.
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.
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.
I will be happy to provide that but first need to figure out how to do it :) Hopefully, google has the answer.
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
@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.
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.
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,
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.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.mq.gw.tuyaus.com
, using secKey for AES encryptiona.tuyaus.com
with atop.online.debug.log
with the values of the exception registers. The payload is encoded and signed with secKey.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.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%.
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.)
@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?
@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.
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 calltuya.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.
[...] 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.
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!!!
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:
Other observations:
Log: