Gosund WP3 Endless ........... Won't Flash

cheechie commented 5 years ago

Just purchased a Gosund model- WP3. It has the 1.0.5 firmware https://www.amazon.com/Assistant-Required-Enabled-Control-Gosund/dp/B072ZX8RTZ

I have tried flashing with both Kali Linux in Virtual Box and with a Raspberry Pi B3.
When I put the plug into pairing mode and then press enter to flash. The plug stops blinking fast but it never programs. In both cases I get the exact same error.

Waiting for the upgraded device to appear If this does not work have a look at the '*.log'-files in the 'scripts' subfolder! ........................................................................................................

Here are my logs.

smarthack-wifi.log

^Cwlan0: interface state ENABLED->DISABLED wlan0: AP-STA-DISCONNECTED 60:01:94:c8:bd:3b wlan0: AP-STA-DISCONNECTED c8:38:90:13:35:bf wlan0: AP-DISABLED wlan0: CTRL-EVENT-TERMINATING nl80211: deinit ifname=wlan0 disabled_11b_rates=0 Backing up NetworkManager.cfg... Restarting NetworkManager... Backing up /etc/dnsmasq.conf... Writing dnsmasq config file... Creating new /etc/dnsmasq.conf... Writing hostapd config file... Configuring AP interface... Applying iptables rules... Starting DNSMASQ server... Starting AP on wlan0 in screen terminal... Configuration file: /etc/hostapd/hostapd.conf Using interface wlan0 with hwaddr d8:3d:4c:94:35:f5 and ssid "vtrust-flash" wlan0: interface state UNINITIALIZED->ENABLED wlan0: AP-ENABLED wlan0: STA c8:38:90:13:35:bf IEEE 802.11: authenticated wlan0: STA c8:38:90:13:35:bf IEEE 802.11: associated (aid 1) wlan0: AP-STA-CONNECTED c8:38:70:13:35:df wlan0: STA c8:38:90:13:35:bf RADIUS: starting accounting session 44D22CF0B138FFAC wlan0: STA c8:38:90:13:35:bf WPA: pairwise key handshake completed (RSN) wlan0: STA 60:01:94:c8:bd:3b IEEE 802.11: authenticated wlan0: STA 60:01:94:c8:bd:3b IEEE 802.11: associated (aid 2) wlan0: AP-STA-CONNECTED 60:01:94:c8:bd:3b wlan0: STA 60:01:94:c8:bd:3b RADIUS: starting accounting session CB46AEC709694B4F wlan0: STA 60:01:94:c8:bd:3b WPA: pairwise key handshake completed (RSN) wlan0: AP-STA-DISCONNECTED 60:01:94:c9:bd:3a wlan0: STA 60:01:94:c8:bd:3b IEEE 802.11: disassociated wlan0: STA 60:01:94:c8:bd:3b IEEE 802.11: disassociated wlan0: STA 60:01:94:c8:bd:3b IEEE 802.11: disassociated wlan0: STA 60:01:94:c8:bd:3b IEEE 802.11: disassociated wlan0: STA 60:01:94:c8:bd:3b IEEE 802.11: disassociated wlan0: STA 60:01:94:c8:bd:3b IEEE 802.11: disassociated wlan0: STA 60:01:94:c8:bd:3b IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE) wlan0: STA 60:01:94:c8:bd:3b IEEE 802.11: authenticated wlan0: STA 60:01:94:c8:bd:3b IEEE 802.11: associated (aid 2) wlan0: AP-STA-CONNECTED 60:01:94:c8:bd:3b wlan0: STA 60:01:94:c8:bd:3b RADIUS: starting accounting session 31D0DEBEC5B93FA6 wlan0: STA 60:01:94:c8:bd:3b WPA: pairwise key handshake completed (RSN) wlan0: AP-STA-DISCONNECTED60:01:94:c8:bd:3b wlan0: STA 60:01:94:c8:bd:3b IEEE 802.11: authenticated wlan0: STA 60:01:94:c8:bd:3b IEEE 802.11: associated (aid 2) wlan0: AP-STA-CONNECTED 60:01:94:c8:bd:3b wlan0: STA 60:01:94:c8:bd:3b RADIUS: starting accounting session 31D0DEBEC5B93FA6 wlan0: STA 60:01:94:c8:bd:3b WPA: pairwise key handshake completed (RSN) wlan0: AP-STA-DISCONNECTED 60:01:94:c8:bd:3b wlan0: STA 60:01:94:c8:bd:3b IEEE 802.11: disassociated wlan0: STA 60:01:94:c8:bd:3b IEEE 802.11: disassociated wlan0: STA 60:01:94:c8:bd:3b IEEE 802.11: disassociated wlan0: STA 60:01:94:c8:bd:3b IEEE 802.11: disassociated wlan0: STA 60:01:94:c8:bd:3b IEEE 802.11: disassociated wlan0: STA 60:01:94:c8:bd:3b IEEE 802.11: disassociated wlan0: STA 60:01:94:c8:bd:3b IEEE 802.11: disassociated wlan0: STA 60:01:94:c8:bd:3b IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)

smarthack-web.log

^CTraceback (most recent call last): File "./fake-registration-server.py", line 129, in main() File "./fake-registration-server.py", line 125, in main tornado.ioloop.IOLoop.current().start() File "/usr/lib/python3/dist-packages/tornado/platform/asyncio.py", line 132, in start self.asyncio_loop.run_forever() File "/usr/lib/python3.6/asyncio/base_events.py", line 438, in run_forever self._run_once() File "/usr/lib/python3.6/asyncio/base_events.py", line 1415, in _run_once event_list = self._selector.select(timeout) File "/usr/lib/python3.6/selectors.py", line 445, in select fd_event_list = self._epoll.poll(timeout, max_ev) KeyboardInterrupt Listening on port 80 [32m[I 190520 10:22:01 web:2162][m 200 GET / (10.42.42.24) 0.93ms [33m[W 190520 10:22:01 web:2162][m 404 GET /favicon.ico (10.42.42.24) 2.73ms

probonopd commented 5 years ago

Did you flash the device out of the factory-new box, or did the device have contact to the app and/or the internet before you tried to flashed it?

cheechie commented 5 years ago

I flashed it out of the factory-new box, it was never connected to the cloud.

eterpstra commented 5 years ago

How can i check what the firmare version is?

jfractalj commented 5 years ago

I'm having the same issue with the same model device. I am running the script from an Ubuntu 18.04 VM.

cheechie commented 5 years ago

I'm having the same issue with the same model device. I am running the script from an Ubuntu 18.04 VM.

Did you flash it right out of the box?

jfractalj commented 5 years ago

Yes I did. I've had it sitting in the box for over a month. I also noticed that the resolv.conf is not providing DHCP. Do you know if that is expected behavior?

cheechie commented 5 years ago

Where is resolv.conf located, I don't see it.

jfractalj commented 5 years ago

sorry, I was typing without thinking. The dnsmasq process was not running. A symptom is not being able to get an IP via DHCP on your secondary device (smartphone, etc). Are you having the same issue?

cheechie commented 5 years ago

My 2nd device (I have used both iphone and android) has access to the internet when connecting to the vtrust-flash network from my wifi dongle. I never looked or check their ip's

jfractalj commented 5 years ago

Yeah, the vtrust-flash network doesn't route out to the internet. They are routing out through their mobile networks to get there. For me, the process did not work because dnsmasq wasn't working properly. I had a conflict with systemd-resolved. I fixed it by running: sudo systemctl stop systemd-resolved I then reran the scripts. The process then completed. This also worked with a plug that has been connected to the app.

cheechie commented 5 years ago

Both devices where in airplane mode and only connected to the vtrust-flash network. Is this vtrust-flash network not supposed to route out to the internet?

That's good to hear it worked with the one that was connected to the app.

jfractalj commented 5 years ago

That's my understanding, but I am probably wrong.

If you run the command sudo dnsmasq on the machine you are running the script on, what is the output?

cheechie commented 5 years ago

I'm not at that machine right now, I will try that command when I'm back.

sebastianklein96 commented 5 years ago

After looking through the Tuya files I'm under the impression that the vtrust-wifi network should indeed forward traffic to the internet. If you have a look in ~/tuya-convert/scripts/setup_ap.sh, line 62-70, it reads as follows:

echo "Configuring AP interface..."
sudo ifconfig $WLAN up 10.42.42.1 netmask 255.255.255.0
echo "Applying iptables rules..."
sudo iptables --flush
sudo iptables --table nat --flush
sudo iptables --delete-chain
sudo iptables --table nat --delete-chain
sudo iptables --table nat --append POSTROUTING --out-interface $ETH -j MASQUERADE
sudo iptables --append FORWARD --in-interface $WLAN -j ACCEPT

To my understanding, the line sudo iptables --table nat --append POSTROUTING --out-interface $ETH -j MASQUERADE forwards all outgoing traffic from the WLAN interface (vtrust-flash) to $ETH, which would be your ethernet interface connected to the internet. The line following that routes all incoming traffic from your ethernet interface to your wifi interface.

This setup file is called in start_flash.sh, line 39, so it takes effect immediately when starting the flash process. It also makes sense to allow internet access, since tuya-convert allows for the user to grab a 3rd party bin file via http directly through the curl commands while tuya-convert is running.

In that case, assuming that the dnsmasq config running behind tuya-convert isn't catching the traffic to the tuya servers anymore, you would be providing an internet connection to your device by connecting it to vtrust-flash.

eterpstra commented 5 years ago

@jfractalj I ran that comment and I am getting the following output:

dnsmasq: failed to bind DHCP server socket: Address already in use

jfractalj commented 5 years ago

@sebastianklein96 yes you are correct of course. I made an offhanded comment about how I thought it worked while troubleshooting my problem instead of looking. My apologies.

@eterpstra it looks like you are having the same issue I was having. If you run sudo netstat -tulpn | grep :53 it should reveal the process that is blocking dnsmasq.

cheechie commented 5 years ago

when I run "sudo dnsmasq" I get the same error dnsmasq: failed to bind DHCP server socket: Address already in use

@eterpstra it looks like you are having the same issue I was having. If you run sudo netstat -tulpn | grep :53 it should reveal the process that is blocking dnsmasq.

root@kali:~# sudo netstat -tulpn | grep :53 tcp 0 0 0.0.0.0:53 0.0.0.0: LISTEN 2043/dnsmasq
tcp6 0 0 :::53 ::: LISTEN 2043/dnsmasq
udp 0 0 0.0.0.0:53 0.0.0.0: 2043/dnsmasq
udp6 0 0 :::53 ::: 2043/dnsmasq

command1

jfractalj commented 5 years ago

Looks like you already have dnsmasq running. Is the script running in the background? If not, you can kill that process with kill -9 2043 and try running the script again to see if you have better luck.

cheechie commented 5 years ago

kill that process with kill -9 2043 and try running the script again to see if you have better luck.

Tried that and no luck. Weird that it does it on the Raspberry Pi and Virtual Box Kali.

jfractalj commented 5 years ago

So you may not be having the same issue as me after all. The symptoms look the same as the device not being able to get an IP address, but outside of that I am not sure. Sorry I haven't been more helpful.

eterpstra commented 5 years ago

I also tried and kill the processes with the mentioned method but when I put the plugs in pairing mode and start flashing it stops after 2 seconds and then a red light shows up

jfractalj commented 5 years ago

That's what happened with me. I ran Wireshark on the wireless interface of the middlebox machine to inspect traffic and realized that there was no traffic at all passing from the outlet even though the script logs showed that the device joined and disconnected from the AP. This led me to believe that the issue I was having may be a general connectivity issue. This took me down the path of testing the ap script and finding my DHCP issue. I hope the steps I took to troubleshoot help.

cheechie commented 5 years ago

I also tried and kill the processes with the mentioned method but when I put the plugs in pairing mode and start flashing it stops after 2 seconds and then a red light shows up

That exactly what mine does with the following error.

wlan0: AP-STA-DISCONNECTED 60:01:94:c8:bd:3b wlan0: STA 60:01:94:c8:bd:3b IEEE 802.11: disassociated wlan0: STA 60:01:94:c8:bd:3b IEEE 802.11: disassociated wlan0: STA 60:01:94:c8:bd:3b IEEE 802.11: disassociated wlan0: STA 60:01:94:c8:bd:3b IEEE 802.11: disassociated wlan0: STA 60:01:94:c8:bd:3b IEEE 802.11: disassociated wlan0: STA 60:01:94:c8:bd:3b IEEE 802.11: disassociated wlan0: STA 60:01:94:c8:bd:3b IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)

RichardUUU commented 5 years ago

Same problem here. Fresh install of rPi and tuya-convert. Brand new out-of-the-box Gosund model- WP3.

jfractalj commented 5 years ago

I have one more device that I can test with, but it has been connected to the internet and is a few months old. If it helps, I can try to replicate your issue to see if there's anything I can do to help. Did you use the prebuilt rPi Kali image or the Raspbian?

Edit: I just ordered a single Gosund WP3 to compare to the ones I already have. Hopefully, between the two I can replicate your issue.

eterpstra commented 5 years ago

I don't think that is the problem anymore. The devices which are now available are flashed with the latest firmware unfortunately.

RichardUUU commented 5 years ago

I also couldn't flash a Topgreener switch. Bummer if I can't use these.

jfractalj commented 5 years ago

@eterpstra If that were the case, wouldn't the devices I have connected to the internet also have this firmware? I am able to flash those still.

eterpstra commented 5 years ago

@jfractalj well I am not sure about that. The fact is that the last couple of days people started new topics with different devices which are not flashable anymore. And for the past few months, everything looked fine for "old" models.

jfractalj commented 5 years ago

@eterpstra Either way, I have a new on on the way that arrives tomorrow. I'll play with it then and see if I encounter the same issue.

cheechie commented 5 years ago

@eterpstra Either way, I have a new on on the way that arrives tomorrow. I'll play with it then and see if I encounter the same issue.

I am interested to see what you find out.

jfractalj commented 5 years ago

The new device worked for me. After flashing I did the curl http://10.42.42.42/undo. The firmware module states it is a 1.0.4 firmware vs the 1.0.5 stated above. It also states no new firmware updates are available. Does anyone have a copy of the 1.0.5 .bin?

pritpaul commented 5 years ago

I was able to successfully flash a WP3 ordered from Amazon on 5/24 (ordered the 1-pack). I don't know what the original firmware was since I didn't connect it to the app, but I have the backed-up firmware file if that's useful.

jfractalj commented 5 years ago

I have one more arriving tomorrow ordered from the original link in this thread. If I am still unable to reproduce the issue, if anyone is interested, I am willing to swap a converted WP3 for a 1.0.5 or one that has this Endless ...... issue in order to help troubleshoot.

jfractalj commented 5 years ago

I received a new device and it does have the 1.0.5 firmware. I am able to reproduce the issue. I can confirm that the devices do not flash because they attempt to connect to another subdomain and requiring a TLS 1.2 connection with the TLS_PSK_WITH_AES_128_CBC_SHA256 cipher to prevent man-in-the-middle.

cheechie commented 5 years ago

I hope there is a way around this!

RichardUUU commented 5 years ago

I'm perversely glad to know there is a good reason for my inability to flash. Now I'm wondering what are the odds this can be overcome? The answer will affect some purchasing decisions. Thoughts anyone?

alcarnes commented 5 years ago

I bought a pack of the WP3s and WP5s from amazon at the same time. The WP3s would not flash but the WP5s would. I ordered another pack of WP5s and by the time I got those, they too had been updated and did not flash. :(

thwe1966 commented 5 years ago

Hi first,

I am new here and have the same problem: the flash process will not start.

Is there now a workarround to be able to flash the devices with the new firmware?

(To my knowledge, it is probably due to the new firmware ... or ???)

CaptClaude commented 5 years ago

Data Point: Bought 4 Gosund WP3s from Amazon in the US just a week ago. After setting up and trying two different Raspberry Pi 3b's and installing git clone -b create-ap https://github.com/kueblc/tuya-convert.git on the second Pi I was still not seeing vtrust-flash. Finally I killed wpa_supplicant and was able to flash all 4 without issue. Unfortunately I appear to have fat-fingered the initial WiFi configuration after flashing and all it would do was slow blink blue/red. Because the whole process interested me, I did a careful job of creating empty log files and capturing them with tail -f for two attempts, one with wpa_supplicant (failed) and one without wpa_supplicant (which succeeded). Doing so makes it clear exactly what gets written to the log files for each of the two cases. Note that some log files are not written to. The point is to show what successful and unsuccessful AP activation logs contain.

Logs with wpa_supplicant running:

==> ./scripts/smarthack-mqtt.log <==

==> ./scripts/smarthack-smartconfig.log <==

==> ./scripts/smarthack-web.log <==

==> ./scripts/smarthack-wifi.log <== Backing up NetworkManager.cfg... Restarting NetworkManager... Backing up /etc/dnsmasq.conf... Writing dnsmasq config file... Creating new /etc/dnsmasq.conf... Writing hostapd config file... Configuring AP interface... Applying iptables rules... Starting DNSMASQ server... Starting AP on wlan0 in screen terminal... Configuration file: /etc/hostapd/hostapd.conf wlan0: Could not connect to kernel driver Using interface wlan0 with hwaddr b8:27:eb:24:d5:c1 and ssid "vtrust-flash" wlan0: interface state UNINITIALIZED->ENABLED wlan0: AP-ENABLED

==> ./scripts/smarthack-web.log <== Listening on port 80

==> ./scripts/smarthack-mqtt.log <== 1561755781: mosquitto version 1.4.10 (build date Wed, 13 Feb 2019 00:45:38 +0000) starting 1561755781: Using default config. 1561755781: Opening ipv4 listen socket on port 1883. 1561755781: Opening ipv6 listen socket on port 1883.

Log files without wpa_supplicant running: (copy/paste complete with some special characters)

==> ./scripts/smarthack-mqtt.log <==

==> ./scripts/smarthack-smartconfig.log <==

==> ./scripts/smarthack-web.log <==

==> ./scripts/smarthack-wifi.log <== wlan0: INTERFACE-DISABLED ^Cwlan0: interface state ENABLED->DISABLED wlan0: AP-DISABLED nl80211: deinit ifname=wlan0 disabled_11b_rates=0

==> ./scripts/smarthack-web.log <== ^CTraceback (most recent call last): File "./fake-registration-server.py", line 129, in main() File "./fake-registration-server.py", line 125, in main tornado.ioloop.IOLoop.current().start() File "/usr/local/lib/python3.5/dist-packages/tornado/platform/asyncio.py", line 148, in start self.asyncio_loop.run_forever() File "/usr/lib/python3.5/asyncio/base_events.py", line 421, in run_forever self._run_once() File "/usr/lib/python3.5/asyncio/base_events.py", line 1388, in _run_once event_list = self._selector.select(timeout) File "/usr/lib/python3.5/selectors.py", line 445, in select fd_event_list = self._epoll.poll(timeout, max_ev) KeyboardInterrupt

==> ./scripts/smarthack-mqtt.log <== ^C1561756084: mosquitto version 1.4.10 terminating

==> ./scripts/smarthack-wifi.log <== Backing up NetworkManager.cfg... Restarting NetworkManager... Backing up /etc/dnsmasq.conf... Writing dnsmasq config file... Creating new /etc/dnsmasq.conf... Writing hostapd config file... Configuring AP interface... Applying iptables rules... Starting DNSMASQ server... Starting AP on wlan0 in screen terminal... Configuration file: /etc/hostapd/hostapd.conf wlan0: Could not connect to kernel driver Using interface wlan0 with hwaddr b8:27:eb:24:d5:c1 and ssid "vtrust-flash" wlan0: interface state UNINITIALIZED->ENABLED wlan0: AP-ENABLED wlan0: STA 18:3d:a2:86:66:78 IEEE 802.11: associated wlan0: AP-STA-CONNECTED 18:3d:a2:86:66:78 wlan0: STA 18:3d:a2:86:66:78 RADIUS: starting accounting session D7D798A392FD4D74 wlan0: STA 18:3d:a2:86:66:78 WPA: pairwise key handshake completed (RSN)

==> ./scripts/smarthack-web.log <== Listening on port 80

==> ./scripts/smarthack-mqtt.log <== 1561756091: mosquitto version 1.4.10 (build date Wed, 13 Feb 2019 00:45:38 +0000) starting 1561756091: Using default config. 1561756091: Opening ipv4 listen socket on port 1883. 1561756091: Opening ipv6 listen socket on port 1883.

==> ./scripts/smarthack-smartconfig.log <== Put Device in Learn Mode! Sending SmartConfig Packets now Sending SSID vtrust-flash Sending wifiPassword flashmeifyoucan SmartConfig in progress .......... SmartConfig complete.

==> ./scripts/smarthack-wifi.log <== wlan0: STA 60:01:94:b6:ad:71 IEEE 802.11: associated wlan0: AP-STA-CONNECTED 60:01:94:b6:ad:71 wlan0: STA 60:01:94:b6:ad:71 RADIUS: starting accounting session 2D4F688D16E19155 wlan0: STA 60:01:94:b6:ad:71 WPA: pairwise key handshake completed (RSN)

==> ./scripts/smarthack-web.log <==

URI:/gw.json?a=s.gw.token.get&gwId=75070011600194b6ad71&other={"token":"00000000","region":"US","tlinkStat":{"configure":"smartconfig","time":2,"source":"ap","path":"broadcast"}}&t=8&v=3.0&sign=c17c06260e6bb67b002167c71c37f354 Answer s.gw.token.get [32m[I 190628 16:09:06 web:2246][m 200 POST /gw.json?a=s.gw.token.get&gwId=75070011600194b6ad71&other={"token":"00000000","region":"US","tlinkStat":{"configure":"smartconfig","time":2,"source":"ap","path":"broadcast"}}&t=8&v=3.0&sign=c17c06260e6bb67b002167c71c37f354 (10.42.42.34) 7.25ms

URI:/gw.json?a=s.gw.dev.pk.active&gwId=75070011600194b6ad71&other={"token":"00000000"}&t=7&v=3.0&sign=8f397850d7d3aae91a413f97ca843957 Answer s.gw.dev.pk.active READ GW ID 75070011600194b6ad71 TRIGGER UPGRADE IN 10 SECONDS [32m[I 190628 16:09:07 web:2246][m 200 POST /gw.json?a=s.gw.dev.pk.active&gwId=75070011600194b6ad71&other={"token":"00000000"}&t=7&v=3.0&sign=8f397850d7d3aae91a413f97ca843957 (10.42.42.34) 16.79ms Trigger upgrade in 10 seconds

URI:/gw.json?a=s.gw.update&gwId=75070011600194b6ad71&t=10&v=2.0&sign=913803e1ac2e97e73808c7fd9e8718c2 Answer s.gw.update [32m[I 190628 16:09:10 web:2246][m 200 POST /gw.json?a=s.gw.update&gwId=75070011600194b6ad71&t=10&v=2.0&sign=913803e1ac2e97e73808c7fd9e8718c2 (10.42.42.34) 8.34ms

==> ./scripts/smarthack-mqtt.log <== 1561756147: New connection from 10.42.42.34 on port 1883. 1561756147: New client connected from 10.42.42.34 as 75070011600194b6ad71 (c1, k60, u'75070011600194b6ad71'). 1561756147: Sending CONNACK to 75070011600194b6ad71 (0, 0) 1561756147: Received SUBSCRIBE from 75070011600194b6ad71 1561756147: smart/device/in/75070011600194b6ad71 (QoS 0) 1561756147: 75070011600194b6ad71 0 smart/device/in/75070011600194b6ad71 1561756147: Sending SUBACK to 75070011600194b6ad71

==> ./scripts/smarthack-web.log <==

URI:/gw.json?a=s.gw.dev.update&gwId=75070011600194b6ad71&t=8&v=2.0&sign=633f28c82c770121e2391ce582f3524b Answer s.gw.update [32m[I 190628 16:09:12 web:2246][m 200 POST /gw.json?a=s.gw.dev.update&gwId=75070011600194b6ad71&t=8&v=2.0&sign=633f28c82c770121e2391ce582f3524b (10.42.42.34) 6.71ms

URI:/gw.json?a=atop.online.debug.log&gwId=75070011600194b6ad71&t=7&sign=2493f6120bddc32934e20801174d2a8f Answer atop.online.debug.log [32m[I 190628 16:09:12 web:2246][m 200 POST /gw.json?a=atop.online.debug.log&gwId=75070011600194b6ad71&t=7&sign=2493f6120bddc32934e20801174d2a8f (10.42.42.34) 6.83ms

URI:/gw.json?a=tuya.device.dynamic.config.get&gwId=75070011600194b6ad71&t=7&v=1.0&sign=d54d8a322a7af28e8254d2dc3c0b6f61 WARN: unknown request: tuya.device.dynamic.config.get (/gw.json?a=tuya.device.dynamic.config.get&gwId=75070011600194b6ad71&t=7&v=1.0&sign=d54d8a322a7af28e8254d2dc3c0b6f61) [32m[I 190628 16:09:12 web:2246][m 200 POST /gw.json?a=tuya.device.dynamic.config.get&gwId=75070011600194b6ad71&t=7&v=1.0&sign=d54d8a322a7af28e8254d2dc3c0b6f61 (10.42.42.34) 5.43ms 104d564ea05c165a3aead8f14432eadf b'2.1a05c165a3aead8f1t5inCMDHpcJKQpxfOe2RbRE2MRmH0B9HvYjWRmoks1LR67IGzkLArQuNbRqgoUm8Jsm5uMafEvnzLLz/1MQ4v1jWvpPiy4jmSutAbFCPuJ7dg4SXZL9kLEC9aqKXAOwI'

URI:/gw.json?a=tuya.device.upgrade.get&gwId=75070011600194b6ad71&t=11&v=4.0&sign=f808517e7b29cb769beec7125b673b37 Answer s.gw.upgrade b'{"result":{"auto":3,"fileSize":"506587","etag":"0000000000","version":"9.0.0","url":"http://10.42.42.1/files/upgrade.bin","md5":"dc92883ebc44f64253bfb004433fc929"},"t":100,"e":false,"success":true}' [32m[I 190628 16:09:17 web:2246][m 200 POST /gw.json?a=tuya.device.upgrade.get&gwId=75070011600194b6ad71&t=11&v=4.0&sign=f808517e7b29cb769beec7125b673b37 (10.42.42.34) 34.03ms

URI:/gw.json?a=s.gw.upgrade.updatestatus&gwId=75070011600194b6ad71&t=100&sign=5c1e80541323e61c18a19366b6008791 Answer s.gw.upgrade b'{"result":{"auto":3,"fileSize":"506587","etag":"0000000000","version":"9.0.0","url":"http://10.42.42.1/files/upgrade.bin","md5":"dc92883ebc44f64253bfb004433fc929"},"t":100,"e":false,"success":true}' [32m[I 190628 16:09:17 web:2246][m 200 POST /gw.json?a=s.gw.upgrade.updatestatus&gwId=75070011600194b6ad71&t=100&sign=5c1e80541323e61c18a19366b6008791 (10.42.42.34) 8.66ms

==> ./scripts/smarthack-mqtt.log <== 1561756157: New connection from 127.0.0.1 on port 1883. 1561756157: New client connected from 127.0.0.1 as P1 (c1, k60). 1561756157: Sending CONNACK to P1 (0, 0) 1561756157: Received PUBLISH from P1 (d0, q0, r0, m0, 'smart/device/in/75070011600194b6ad71', ... (147 bytes)) 1561756157: Sending PUBLISH to 75070011600194b6ad71 (d0, q0, r0, m0, 'smart/device/in/75070011600194b6ad71', ... (147 bytes)) 1561756157: Socket error on client P1, disconnecting.

==> ./scripts/smarthack-wifi.log <== wlan0: STA 60:01:94:b6:ad:71 IEEE 802.11: disassociated wlan0: AP-STA-DISCONNECTED 60:01:94:b6:ad:71 wlan0: STA 60:01:94:b6:ad:71 IEEE 802.11: disassociated wlan0: STA 60:01:94:b6:ad:71 IEEE 802.11: disassociated wlan0: STA 60:01:94:b6:ad:71 IEEE 802.11: disassociated wlan0: STA 60:01:94:b6:ad:71 IEEE 802.11: disassociated wlan0: STA 60:01:94:b6:ad:71 IEEE 802.11: disassociated wlan0: STA 60:01:94:b6:ad:71 IEEE 802.11: disassociated wlan0: STA 60:01:94:b6:ad:71 IEEE 802.11: disassociated wlan0: STA 60:01:94:b6:ad:71 IEEE 802.11: disassociated wlan0: STA 60:01:94:b6:ad:71 IEEE 802.11: disassociated wlan0: STA 60:01:94:b6:ad:71 IEEE 802.11: disassociated

==> ./scripts/smarthack-web.log <== [32m[I 190628 16:09:26 web:2246][m 206 GET /files/upgrade.bin (10.42.42.34) 56.48ms [32m[I 190628 16:09:28 web:2246][m 206 GET /files/upgrade.bin (10.42.42.34) 1620.45ms

==> ./scripts/smarthack-mqtt.log <== 1561756166: Received PUBLISH from 75070011600194b6ad71 (d0, q0, r0, m0, 'smart/device/out/75070011600194b6ad71', ... (80 bytes)) 1561756167: Received PUBLISH from 75070011600194b6ad71 (d0, q0, r0, m0, 'smart/device/out/75070011600194b6ad71', ... (81 bytes))

==> ./scripts/smarthack-wifi.log <== wlan0: STA 60:01:94:b6:ad:71 IEEE 802.11: associated wlan0: AP-STA-CONNECTED 60:01:94:b6:ad:71 wlan0: STA 60:01:94:b6:ad:71 RADIUS: starting accounting session 20999E1CBA87CCE9 wlan0: STA 60:01:94:b6:ad:71 WPA: pairwise key handshake completed (RSN)

Prior to doing this the RPi 3b was painstakingly updated following this guide.

In answer to the question "how do I recover my WiFi after using an RPi as a vtrust-flash server, just reboot.

thwe1966 commented 5 years ago

Hello,

tried again, even with a blank 'wpa_suplicant' -> no success!

Details:

Device: Teckin smart plug (eu) https://www.amazon.de/gp/product/B07HHFKWJJ/ref=ppx_yo_dt_b_asin_title_o02_s01?ie=UTF8&psc=1
Raspberry Pi 3 B with Strech lite, completely new
tuya-convert installed and started with 'start_flash' (wlan 'vtrust-flash' is established, connection with a smartphone works)
Teckin smart-plug is in pairing mode (led is flashing fast)
After pressing 'Enter' -> 'starting pairing procedure ... waiting for the upgraded device to appear ...'
Led on the Teckin goes out briefly, then constantly on
flush program can apparently not appear correctly / completely the device

screenshot

smarthack-mqtt.log

smarthack-smartconfig.log

smarthack-web.log

smarthack-wifi.log

Is a flashing of these devices not possible anymore?

CaptClaude commented 5 years ago

I now have a WP3 that behaves the same way, although I sudo killall wpa_supplicant prior to running ./start_flash.sh. I make the WP3 blink fast (blue), start the process, the script runs for a few seconds and the WP3 turns red (so something is happening) but the script just puts dots on the screen and never progresses. The only suspicious thing in any of the log files is in smarthack-mqtt.log:

1561943563: mosquitto version 1.4.10 (build date Wed, 13 Feb 2019 00:45:38 +0000) starting 1561943563: Using default config. 1561943563: Opening ipv4 listen socket on port 1883. 1561943563: Error: Address already in use

And I don't really know whether it is suspicious. In the log for a successful flash, I see this:

1561754370: mosquitto version 1.4.10 (build date Wed, 13 Feb 2019 00:45:38 +0000) starting 1561754370: Using default config. 1561754370: Opening ipv4 listen socket on port 1883. 1561754370: Opening ipv6 listen socket on port 1883. 1561754498: New connection from 10.42.42.12 on port 1883. 1561754498: New client connected from 10.42.42.12 as 05835352dc4f228bf8dc (c1, k60, u'05835352dc4f228bf8dc'). 1561754498: Sending CONNACK to 05835352dc4f228bf8dc (0, 0) 1561754498: Received SUBSCRIBE from 05835352dc4f228bf8dc 1561754498: smart/device/in/05835352dc4f228bf8dc (QoS 0) 1561754498: 05835352dc4f228bf8dc 0 smart/device/in/05835352dc4f228bf8dc 1561754498: Sending SUBACK to 05835352dc4f228bf8dc

I also connected my smartphone to vtrust-flash and will try again with something else connected to it. There are some other hints in other posts that I saw last night that I will try as well. [EDIT] Tried again with a MacBook Pro connected to vtrust-flash and got the ipv6 listening message but then nothing.

I think this one has tuya-convert-proof firmware in it. grumble

CaptClaude commented 5 years ago

I got an email with the following question from @kevinduongcalabrio whose comment may not yet have percolated to the surface:

Do you know which firmware version your GoSunds were running on when you received them or are running on now?

Answer: One is running whatever version of Tuya/Gosund firmware it came with (I do not have the happyhome or whatever it is called app) and the other three are running the latest Tasmota because they successfully flashed.

wezmininger commented 5 years ago

I bought a 4 pack of gosund WP3 from amazon July 1 2019 Using the tuya-convert instructions I was able to get one of them flashed. The other 3 are making me go insane with not working. None have eve been connected to any app or wifi and they have only been plugged in while trying to flash

Ive even unplugged my normal router and setup an old one as a totally new network with the pi for AP wired in and still cant get the other 3 to flash.

RpiB3 (not +, tho I tried 2 of those as well) Rpi lite Stretch image 9 April 2019 release (new buster image was just released so I had to dig for the old version) Ive started with a fresh image nearly every attempt and always done update and upgrades

I can join the vtrust-flash wifi network with another pi3b (to simulate the phone, or whatever) get an ip of 10.42.42.26 with this device. put the device (ive tried this over with all 3 of the ones i havent managed to flash) in fast blue flash mode.

no matter how long or how fast i press Enter to start the flash process, the blue light flashes for a bit, then turns solid red and stays that way. The light only turns red after I start the flashing process

In the wifi logs I can see that the device joins the AP.

If I hadnt managed to get 1 of the 4 pack working I would give up expecting that they were maybe updated, but these have never been connected to the internet.

Im about to just chop them open and flash with FTDI.

CaptClaude commented 5 years ago

@wesmininger Check out this closed issue #207 about opening the WP3 for flashing. My experience was 3 Good, 1 No Flash. I will pry my no-flash open and do the same. Post your process and results.

graphite-elegance commented 5 years ago

Has anyone noticed that these aren't using the "tuya" app but now the "Go Smart" app that is specifically for the Gosund switches? Does that mean the Tuya Convert needs a fork for the Gosund "Go Smart" information possibly??

kueblc commented 5 years ago

From the README

A Chinese company named Tuya offers a free-to-brand turnkey smart home solution to anyone. Using their offer is dead-simple, since everything can be done by clicking through the Tuya web page, from choosing your pre-designed products or pre-programmed wifi-modules (mostly ESP8266) to building your own app. In the end, this has resulted in as they claim over 11 000 devices 'made' by over 10 000 vendors using Tuyas firmware and cloud services.

Most products have their own brand on the app, it is the same library under the hood.

Tech4Ever commented 5 years ago

Thanks @kueblc for giving me the hint that there are other with my problem:

Yesterday I received 4 Gosund SP1 EU devices an Ihave the exact same problems reported above:

When I start the flashing procedure, after around 5-10 seconds I can here the device switch and the blinking blue LED turns red or turns off. I don´t get any error or success message on my raspi.

I have no solution, maybe they are not flashable anymore as some others guessed.

TimelessNL commented 5 years ago

@kueblc In #249 you mentioned that if the device does not send HTTP GET requests it may have the patched firmware. But are there any other signs?

I bough myself some LSC Smart Connect bulbs sold by Action. for example this E14 bulb which is based around the ESP8285 and SM2135E. When running _./startflash.sh it does indeed connect to the AP after the initial smart-config procedure. But neither does it request a DHCP lease nor is it accessible on its 10.42.42.42 static address. Or is there any knowledge if they completely changed the IP address?

Unfortunately opening the bulb is a one way trip as is seen on the picture below, and even after opening the TX/RX pins are not easily accessible. 20190824_203358

EDIT: Never mind, after trying an Ubuntu 16.04 install the tuya device did indeed request a DHCP address. No idea why it didn't on 18.04 even while my my phone did get a DHCP lease...

TimelessNL commented 5 years ago

Another small update: I had to reset my bulb a couple of times and during that process I noticed that if you apply power 4 times it actually starts its own little AP called SmartLife-XXXX where the X's are replaced by the last 4 characters of its MAC address. Since my device is a LED bulb it will flash slowly (not fast as during smart-config) and after connecting it will give leases in the 192.168.175.x range.

Maybe someone else noticed this as well?

ct-Open-Source / tuya-convert

Gosund WP3 Endless ........... Won't Flash #199