SP20 bricked

[Scope666]

Hello,

I believe I have bricked my Teckin SP20, very similar to this issue: https://github.com/ct-Open-Source/tuya-convert/issues/650

The mac address reports as being Espressif Inc.

I can only get the light to flash for a split second when holding the button while plugging it in. No access point is being offered. It's unresponsive to the 5 second button hold command.

Is there anyway to recover?

smarthack-psk.log smarthack-wifi.log smarthack-web.log smarthack-udp.log smarthack-mqtt.log

terminal_output.txt

[kueblc]

Your device is not bricked. It is running the intermediate firmware. 5 second button hold command is a function of Tuya firmware, so it is expected that this does not work while running another firmware.

While you are not running tuya-convert, plug the device in and wait a minute. Check to see if there is a vtrust-recovery network. This will confirm that the device is functioning correctly.

From there, you can rollback to stock firmware or proceed to flashing.

If you wish to rollback, simply browse to http://10.42.42.42/undo while connected to vtrust-recovery. If you wish to proceed, you can restart tuya-convert, but do not connect a phone, simply plug the device and press enter.

You can skip the backup if you believe it is causing issues. Some have reported success by commenting out the backup code.

[Scope666]

Thanks for the reply.

I've waited for many minutes, the vtrust-recovery network is NOT THERE. That's why I believe I'm bricked. I've scanned with multiple devices, that SSID is not being created.

I've also tried some of the procedures found in other issues here, including multiple USB Wi-Fi adaptors, trying different client devices to connect to vtrust-flash, and hot plugging the SP20 after the dots start, no matter what I do I can't get it's mac address to show in the log, it's simply not trying to connect to vtrust-flash.

[jlverhagen]

I believe I may have just run into this issue today. My Teckin SP20 didn't get flashed properly and afterwards the power/status LED only turned on for about a second when plugging it into an AC outlet, and then nothing, no response to the onboard button, and no wifi AP to connect to. I exited tuya-convert, unplugged/replugged the SP20 to see if it would come to life, but it didn't appear to be doing anything. I unplugged it and tried a second SP20.

The second SP20 flashed successfully. I configured it and it's working as expected.

After flashing this second SP20 I had left tuya-convert running, leaving it on the prompt asking if I wanted to flash another device. I left tuya-convert on that prompt. I went back and plugged in the first SP20 that failed to flash and I tried pressing the button on the SP20 various ways (long press, several rapid presses, etc), and eventually I just left it plugged in with no sign of life and still no vtrust-recovery or tasmota SSID. I reconnected my phone back to vtrust-flash (still no vtrust-recovery) and went to http://10.42.42.42. And on that page it looked like I was seeing the details for the failed SP20 and not the raspberry pi running tuya-convert or the SP20 I had just successfully flashed. Still connected to vtrust-flash, I went to http://10.42.42.42/undo and that appeared to restore the device so I could then attempt a re-flash.

The second flash attempt for the first SP20 that failed the first time did succeed and now works as expected with Tasmota.

[Scope666]

I think they should add a warning about the Teckin SP20 as it seems like a common problem with tuya-convert. EVERY other device I used it on worked without incident, it's just that model plug that has problems. It happened to two out of two for me, I had to fix both by cutting an access door and serial flashing them.

I tried what you did to recover, it never worked for me. I had a 2nd window open tailing the wi-fi log and neither of the failed plugs would ever connect to vtrust-flash no matter what I tried.

[jlverhagen]

I just had an issue on a second SP20 and this time I can't seem to do anything to get it working again through tuya-convert. Looks like I may be flashing that one via serial. A third problematic SP20 wouldn't seem to take the intermediate firmware most of the time. When it did take the intermediate firmware, it would fail at the firmware backup stage after the backup stopped downloading. I aborted at those failures and was able to use vtrust-recovery to recover and try again. Failed about a dozen times, using a Raspberry Pi 3B to run tuya-convert. Then I moved the SP20 to an outlet on the other side of the room, about 10ft further away from the Raspberry Pi than it was originally, and it flashed on the next attempt with no problems. Originally the SP20 was about 4ft from the Raspberry Pi and plugged into a power strip connected to a wall outlet that also powers my PC. Too close to the flash access point (maybe), dirty power (probably), or just a coincidence (shrug)?

So I'm batting .750 on my 4-pack of Teckin SP20s that was purchased from Amazon about a year ago (1 easily flashed with Tasmota, 2 stubbornly flashed with Tasmota, and 1 unresponsive). Based on some of the issues others have had with flashing the SP20, I'll call that a win and move on.

[Scope666]

I have definitely seen weirdness when a device is too close to an access point. I have a Roku TV that lives in the same room as the Unifi Dream Machine and it acts up because the signal is so hot there.

In my opinion I think the Teckin SP20 is problematic enough that a warning should be added to the script text that mentions not attempting on that unit unless you're prepared to serial flash if it fails.

[crocokyle]

I also experienced the same thing today and wanted to document it. Bricked two Teckin SP20s. No vtrust-recovery SSID found. I agree that there should be a warning listed for the SP20.

Another troubleshooting step to note is that I tried the method @jlverhagen mentioned by running start_flash.sh. I can see the device temporarily connects with IP 10.42.42.42. I then try browsing to http://10.42.42.42 or http://10.42.42.42/undo and get a timeout on both.

start_flash.sh outputs

Fetching firmware backup
<blah blah blah curl STATUS blah blah blah>
0 bytes transferred
curl: (28) Connection timed out after 90000 milliseconds 
Could not fetch a complete backup

UPDATE:

After doing exactly what @jlverhagen said by unplugging, pressing buttons, etc. Somehow I managed to get the vtrust-recovery SSID to show up even without any LEDs or apparent button response. This wasn't instant on either device and it took multiple attempts. After I connected to vtrust-recovery from my phone, After this, I navigated to http://10.42.42.42/undo and the device reset with no issues. I attempted to flash again however, when Fetching firmware backup I am getting an average transfer speed of 300 Bps with a total download time of about 30 minutes. This obviously times out after the 90000 ms and recreates the same issue. This time, instead of terminating start_flash.sh when the backup failed, I decided to proceed anyway and flash tasmota.bin.

This completed successfully and I was able to recover all the bricked devices using the same method. I can now access the tasmota-xxxxx SSID with no problem.

[brickedkludge]

I started issue #650 that @Scope666 refers to at the top of this page. I recently tried flashing a Teckin SP20 again and saw some odd behavior but also eventual success. I wanted to post my notes here since this seems to be the best thread I could find about this topic.

I flashed a Teckin SP20 that I received directly from Teckin in January 2021 as a warranty replacement. I didn't know whether it had an ESP8266 inside or a patched firmware that would stop tuya_convert from working. I had never connected this plug to the Tuya/Smartlife app since I didn't want to risk it updating to a newer patched firmware that might make things worse.

I flashed using a Raspberry Pi 4b to run tuya_convert.

My first attempt to flash was held up because I couldn't see the vtrust_flash SSID from my phone. I worked around that by changing the channel field in ~/tuya_convert/scripts/hostapd.conf as described in issue #1006 where I posted about that problem.

Then start_flash.sh proceeded to the point where it tried to download the original firmware, but this failed with a timeout error. After this, the device would only give a brief blue/red flash when plugging it in and there was no response to pressing the button (no LED change and no toggle of the internal relay). Holding the button to enter fast-flash Quick/EZ pairing mode didn't work either. This is all the same behavior I saw in the original issue #650.

Here's the relevant error output from start_flash.sh:

======================================================
Starting smart config pairing procedure
Waiting for the device to install the intermediate firmware
Put device in EZ config mode (blinking fast)
Sending SSID                  vtrust-flash
Sending wifiPassword          
Sending token                 00000000
Sending secret                0101
................
SmartConfig complete.
Resending SmartConfig Packets
...........................................................................................
IoT-device is online with ip 10.42.42.42
Fetching firmware backup
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0 1024k    0  5840    0     0     64      0  4:33:04  0:01:30  4:31:34     0
curl: (28) Operation timed out after 90001 milliseconds with 5840 out of 1048576 bytes received
Could not fetch a complete backup
Do you want to continue anyway? [y/N] n
======================================================
Cleaning up...
Closing AP
Exiting...

See logs below. Story continues in the next post.

smarthack-mqtt.log smarthack-psk.log smarthack-udp.log smarthack-web.log smarthack-wifi.log start_flash_output.log ..

[brickedkludge]

At this point I figured I was screwed like I was in my original issue #650.

It's been 1.5 years since I posted that original issue and the details are fuzzy beyond what I typed in my posts. I don't recall ever noticing or connecting to a vtrust_recovery SSID generated by the "stuck" SP20 smart plug. I don't know if that's because the SP20 wasn't generating that AP or just that I didn't know what I was doing and didn't look for it. In my original issue Kueblc mentioned that the SP20 might be stuck with the intermediate firmware and that I needed to trigger an undo operation via "http://10.42.42.42/undo" to get back to the original firmware. It probably went unsaid that I needed to connect to vtrust_recovery to do this, but I just didn't know what I was doing.

Anyway, this time I noticed the vtrust_recovery SSID because I had been running InSSIDer (a freely downloadable Windows-based wifi analyzer) and it was visible in its recent SSID history list. However, when I tried to connect to it from my phone the SSID was gone. InSSIDer showed that the vtrust_recovery AP signal was appearing and disappearing. Sometimes I could see it on my phone and sometimes I couldn't. Even when I could, I would repeatedly try to connect and my phone would fail to connect.

Based on a comment from @jlverhagen in this thread, I tried moving the SP20 to a different location in the room to see if that would help me connect to vtrust_recovery. I don't recall that immediately solving my problem, but eventually after trying to connect 10-20 times (with nothing else changing in between) I was able to connect successfully and send a curl "http://10.42.42.42/undo" command from a terminal emulator app on my android phone. At this point the SP20 restarted and was functioning normally again with the original firmware!

Armed with the knowledge that I could now likely recover the SP20 if needed and encouraged by comments in this thread from @jlverhagen and @crocokyle, I decided to try running tuya_convert on this plug again with the plug in the new location.

This time start_flash.sh would get stuck repeatedly "Resending SmartConfig Packets" and would eventually timeout. Here's the relevant output:

Sending SSID                  vtrust-flash
Sending wifiPassword          
Sending token                 00000000
Sending secret                0101
................
SmartConfig complete.
Resending SmartConfig Packets
.................
SmartConfig complete.
Resending SmartConfig Packets
.................
SmartConfig complete.
Resending SmartConfig Packets
................
SmartConfig complete.
Resending SmartConfig Packets
.................
SmartConfig complete.
Resending SmartConfig Packets
.................
SmartConfig complete.
Resending SmartConfig Packets
................
SmartConfig complete.
Resending SmartConfig Packets
.................
SmartConfig complete.
Resending SmartConfig Packets
.................
SmartConfig complete.
Resending SmartConfig Packets
................
SmartConfig complete.
Resending SmartConfig Packets
..............
Timed out while waiting for the device to (re)connect

My recollection is that I tried this several times and it failed similarly each time. I think most times the SP20 would stay responsive and go back to slow-flash mode. I could then hold the button and put it back into fast-flash mode and try again. I think maybe once or twice it did get "stuck" back in the single blue/red flash on start and I had to connect to vtrust_recovery and do the undo step to get it back.

Here are the logs from this step in the process. Story continues in the next post...

smarthack-mqtt.log smarthack-psk.log smarthack-udp.log smarthack-web.log smarthack-wifi.log start_flash_output.log

[brickedkludge]

After several tries, I was confused why I wasn't seeing the same behavior I did at the start where the backup of the original firmware started and then failed and left the plug "stuck" in the bad state with the single blue/red flash on start. The only difference I could think of at this point was that I had moved the plug across the room. So I tried again with the plug back near its original location.

Unbelievably, the next start_flash.sh attempt worked! It even succeeded to pull a backup of the original firmware and then proceeded to successfully flash Tasmota. I can't say for sure that changing the location had an effect, but it's certainly suspicious...

Lots of thanks to @Scope666, @jlverhagen, and @crocokyle for posting their experiences. Hopefully all this detail might help someone else who is running into similar problems.

Here the final successful logs and start_flash.sh output: device-info.txt smarthack-mqtt.log smarthack-psk.log smarthack-udp.log smarthack-web.log smarthack-wifi.log start_flash_output.log

[brickedkludge]

After getting cocky that I'd figured out how to flash Tasmota to the device described above, I tried to flash the other SP20 that came in the same box. Guess how that turned out? :(

The first time I tried I got the same repeated "Resending SmartConfig Packets" pattern I saw above. But this time the smart plug got stuck worse than before. When I plug it in I get a slightly longer blue/red flash and then between zero and several slow blue flashes (about 1 second on, 1 second off) and then the LED stays off. Pressing/holding the button makes no difference. I never see a vtrust_recovery SSID and I've been monitoring it with InSSIDer. I've unplugged/replugged it a couple dozen times with no change in behavior. I've left it sit for a long time. Nothing.

Not sure what else to try now, except to possibly cut it open and try via a soldered connection...

Here are the logs and start_flash.sh output from this failed attempt: smarthack-udp.log smarthack-web.log smarthack-wifi.log start_flash_output.log smarthack-mqtt.log smarthack-psk.log

[Scope666]

After getting cocky that I'd figured out how to flash Tasmota to the device described above, I tried to flash the other SP20 that came in the same box. Guess how that turned out? :(

I originally bought my SP20's in a 4 pack. 2 have holes cut in them and are running Tasmota, the other 2 are still on stock firmware, and I'm using localTuya on them. I'd love to know what's so different about this specific plug that makes it so hard to OTA flash, I've flashed a BUNCH of other devices with Tuya Convert without issue.