Teckin SP20 - stuck on intermediate firmware, doesn't try to connect to vtrust.

[benaltman]

Hey there,

I had issues flashing one of the two TECKIN SP20 plugs in a pack. From what I've read elsewhere, it appears I've managed to flash the intermediate firmware. Unfortunately I don't have the original flash logs due to a HDD problem encountered soon afterwards. Now, when attempting to connect the plug, it will just resend Smartconfig Packets endlessly, and the device doesn't connect to vtrust-flash.

Device: TECKIN Smart Plug Model SP20 Firmware :Unsure, but has never been connected to Tuya app. Other device from the pack flashed correctly.

Behaviour observed:

• During initial flash, I was never prompted for selection of tasmota/esp, and a backup was never taken as best I can remember.
• Initial device behaviour worked as expected (long press to change between modes). Now, I get a dull blue/red pulse on power, then slow blue pulse anywhere from 2-8 times. The button no longer works to switch modes. If unplugged/replugged quickly, can sometimes get a solid red light but no difference in conversion behaviour. I've seen this behaviour described in other issue reports, but their solutions did not remedy my problem.
• No network is established (vtrust-recovery, tasmota, etc.). Device does not appear to try to connect to vtrust-flash either.
• Other plug in pack got slower and slower during backup process (eventually claiming "7 hours to backup") but still converted in short order.

Things I've tried include: repeated unplug/replug, trying to switch up the order of script vs power on vs vtrust, connecting multiple devices to vtrust, moving laptop close to plug, multiple outlets/locations. It really seems like the plug just doesn't try to connect to anything anymore, and just goes to sleep. The two devices shown in the wifi log are a phone and a laptop, not the plug.

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

[kueblc]

Unfortunately I don't have the original flash logs due to a HDD problem

That's too bad, may have helped to narrow this down

Now, I get a dull blue/red pulse on power, then slow blue pulse anywhere from 2-8 times

This doesn't sound like our intermediate firmware, we don't touch the GPIOs to avoid potential damage when running an unknown hardware configuration

The button no longer works to switch modes.

So it is likely not running stock firmware

Have you checked for probe requests? It could be that it is running Tasmota.

smarthack-wifi.log

handle_probe_req: send failed

Now this is a new one, but seems like a likely culprit for inability to connect to an AP

[benaltman]

Unfortunately I don't have the original flash logs due to a HDD problem

That's too bad, may have helped to narrow this down

Yeah, it's one of those times when life got in the way. By the time I got back to digging into it, the old PC I was using for this gave up the ghost.

Now, I get a dull blue/red pulse on power, then slow blue pulse anywhere from 2-8 times

This doesn't sound like our intermediate firmware, we don't touch the GPIOs to avoid potential damage when running an unknown hardware configuration

That's reassuring in some ways, and not in others. It does explain why none of the behaviour was matching what was expected of intermediate firmware per other issue descriptions.

Have you checked for probe requests? It could be that it is running Tasmota.

Would you mind explaining how I can do this?

smarthack-wifi.log

handle_probe_req: send failed

Now this is a new one, but seems like a likely culprit for inability to connect to an AP

... huh. That is... actually a bit strange. I don't remember seeing that when I previously looked through the logs (last tried this convert a little while ago). I'll regenerate fresh logs when trying to search probe requests per the above. Sorry about that.

It's worth stating that I converted the other Teckin plug after this one failed, so in theory nothing is wrong with the equipment I've been using.

Thanks for the quick response, by the way!

[kueblc]

Have you checked for probe requests? It could be that it is running Tasmota.

Would you mind explaining how I can do this?

If you can place your wifi card into monitor mode, you could use a tool like tcpdump or WireShark to listen in and filter for type mgt and subtype probe-req

[benaltman]

Alright, thanks. I ran wireshark in monitor mode, and when filtering by probe request, it was mostly devices that I recognize (Ecobee, Google, Apple, etc.). I see other devices trying to connect to nearby networks that aren't mine, so I assume those are neighbours since the SSID shows up in my nearby list (Bell, Netgear, etc.).

There is one device that I don't recognize ("Zhejiang_21:ba:e4") that seems to be trying to connect to SSID=RTK 11n AP. However, when I ran Wireshark again without the plug inserted, this device continued to show up. All the other entries seem to be from known devices.

The exception is a device that only shows mac address as source and tries to connect to SSID=Wildcard. It only shows up once in the log, though, which feels strange given the device is powered on for about 10 seconds before turning off the LED.

Is this useful information? I'll admit I'm not sure exactly what I'm looking for to know if it's running Tasmota.

I can upload new versions of the logs as well once I go back to normal wi-fi mode on that laptop, but when I looked through it, there didn't appear to be any errors listed. (other than no_shared_cipher)

[benaltman]

Adding updated logs that don't have that repeated error. Looks like that was probably caused by the computer going to sleep.

I didn't see anything strange in these ones. Any other ideas what I can do?

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

[benaltman]

Just closing this as unresolved - I never ended up getting the plug to reconnect through any combination of actions, and don't really want to tear it open.

Thanks for the support, must've just been a fluke outcome.