Repository navigation
Replies: 17 comments 33 replies
Successful S60TPF (EU / Type E/F) conversion & fix for stalled chunk transfersI just successfully converted the European model (S60TPF, Stock 1.2.0) to official Tasmota! Relay switching and power monitoring (236 V) both work as expected. Issue encountered during Stage 9 (E2):During Stage 9, the script got stuck waiting at block 100 on the first attempt and block 43 on the second. Checking the Tasmota console on the plug revealed: Root cause: • fetch_chunk in Berry did not call client.close(), keeping TCP sockets lingering across hundreds of sequential requests. Solution: I've opened a Pull Request with the fix: https://github.com/adamsthws/Sonoff-OTA/pull/ |
|
For anyone else reading along - this is now resolved in the latest versions. @jetronic18s - Thankyou for the excellent PR! |
|
Success ! Result for the second plug: One more: ON forth plug I have experienced an issue: I think it was caused by weak wonky Wifi Signal - after moving plug to better spot I have restarted process with result: And next one converted without problems: |
|
@amikot- retries have now been added to handle the occasional wonky wifi signal, so it should be more robust in future. Thankyou for the report! |
|
Two EU plugs converted, no issues experienced: |
|
Thankyou for the report! |
|
S60TPG Conversion - Using Mac-OS Sequoia 15.7.4 Python 3.12.2 (already installed) 1st Attempt failed at Stage 6 - On Screen messaging suggesting an AP had been created but this did not exist. Retried attempting to continue the installation at the suggested IP [18:01:33] FAILED: the plug at 192.168.0.22 did not answer the eWeLink discovery; check it is switched on and LAN Control is on in the eWeLink app ewelink could still see the device so I tried again from scratch. This time the installation did not pause at step 6 but continued to Stage 8 The s60 was visible on the ip address and running Tasmota-safeboot. It's working however I'm not sure any of this is particularly MAC related. I was getting reports of -79dbm wifi. I'm not sure why, my wifi strength is much better than that but perhaps is connecting to a different repeater. |
That would be great actually. PasteBin might be our best bet |
|
Paste link gave me all sorts of redirects & Norton alerts !! |
|
Thanks for those logs. They've led to fixes that are now in the repo. (Nothing in it turned out to be Mac-specific)
Your plug works as it is, but it's worth finishing to avoid future upgrade issue... From your Sonoff-OTA folder:
(Before writing anything, the plug checks itself: the memory layout, that official Tasmota is running, and that the temporary startup firmware is still in place. If anything doesn't match, it stops and nothing is written) |
|
Brilliant Thanks. Exactly as you said & all good. This is a great piece of work. |
|
Thanks for reporting back. I’m glad to hear you were able to get there in the end |
|
Just did a succesfull conversion from a WIndows 10 PC. Initially had issues connecting to the plug, because my IOT devices live on a seperate VLAN (although temp firewall rule to allow all traffic between my PC and the plug was in place). Workaround was moving my laptop to the IOT VLAN temporary. 
|
|
Thankyou. You are the first Windows user to |
|
Hello! I need help recovering my Sonoff S60TPF.
Could you please advise on the safest recovery procedure? I have not manually uploaded any firmware files through the Tasmota web interface. Thank you! |
|
Hi, thanks for the report, let's get you sorted out... Your plug is safe. Stage 9 only copies the startup firmware into a spare area of memory. It doesn't change the partition table or what the plug boots from, so you can retry again as many times as needed. Another S60TPF user seems to have hit the same stop in Stage 9 (see the report above). The plug gives up on the first network hiccup while downloading, and doesn't tell the computer, so the computer just waits. A fix to add automatic retries is in the pipeline. You could keep retrying manually in the mean time (make sure the plug and computer both have strong Wi-Fi signal). Kaspersky may also be part of it, because it can interrupt local network connections. If it keeps failing, you might try pausing Kaspersky's firewall for the run. To find out why it stopped, it would be great if you send me these three things?
You can paste them here inside a ``` code block. |
|
Quick update - the fix is now merged, if you run the latest version against the plug you it should get you over the line. Let us know how it goes! |
|
Any updates on the recovery @zvezdaabzelil-png ? |
|
|
And a second one |
|
Thankyou @diegohumanista! |
|
Hi, |
|
Thankyou @xmeir - You are the first MacOS user to report a successful end-to-end conversion - much appreciated! |
|
Yep working. I holed back the soldering method for a while but this method come in the best time. The Sonoff LAN control is a hit and miss for me as when no internet the eWeLink app sometimes not loading. Need to disable the mobile internet and some device not show up as online in LAN mode and when they show up after turn off can't even turn back on so manually need to unplug. Now with tasmota can control instantly from phone with Tasmotrol + Tailscale :) |
|
Thankyou @pidro8899! |
|
Smooth sailing, especially compared with the botch-job I did on the sibling plug with the soldering method ... |
|
Thankyou Morteh! |
|
Worked with no issues. Just all sensors display 0, but thats not flashing related issue I guess. |
|
Data arriving from the meter is a good sign: the meter is alive and the pin is right. Flashing can't have damaged the meter. The plug only listens to the meter chip (a CSE7766 on GPIO7), and the chip keeps its calibration in its own memory. I'd speculate the meter might be sending readings it marks as invalid, or readings with no calibration in them. Could you send:
Depending on what the bytes show, we might be able to work around it, for example by calibrating the meter by hand. |
|
|
Thanks @f5AFfMhv, that log helps. I compared your frames with three working S60s... I suspect it may be a hardware fault in the voltage sensing. The meter chip itself is healthy but its voltage input is getting almost nothing (about 1/600 of the mains voltage). Power is worked out from voltage × current, so it reads 0 too. The conversion can't be to blame because the ESP32 only ever receives data from the meter chip. Does the eWeLink app's usage history for this plug show energy right up to the day you converted it? May I ask you to run one more check to see whether the meter was still working when you converted it? This grabs the energy history from your Sonoff backup. From your Sonoff-OTA folder... Run this, send me the outputpython3 - <<'EOF'
import glob, json, sys
sys.path.insert(0, ".")
from tools.inspect_stock_nvs import parse
for path in glob.glob("captures/plugs/*/sonoff-backup/flash.bin"):
names, values = parse(open(path, "rb").read()[0x9000:0x19000])
def blob(namespace, key):
for (n, k), v in values.items():
if names[n] == namespace and k == key:
return b"".join(v.chunks[i] for i in sorted(v.chunks))
return b""
usual = json.loads(blob("user_usual", "content").rstrip(b"\0") or b"{}")
print({k: v for k, v in usual.items() if "Energy" in k or "LastTime" in k})
history = b"".join(blob("histEnergy", f"histEnergy{i}") for i in range(9))
print(f"{len(history)} bytes of energy history, {sum(1 for b in history if b)} non-zero")
lines = [i for i in range(0, len(history), 16) if any(history[i:i + 16])]
for i in lines[-40:]:
print(f"{i:5d}: {history[i:i + 16].hex(' ')}")
EOFYour best options are likely to be... 1. Return it 2. Keep using it, for current only Example config: current onlyThis replaces the First check that the current follows the load: a kettle or heater of about 2 kW should read about 8–9 A. Then set Current floor just above what it shows with the relay on and nothing plugged in. # Current-only metering for an S60 whose meter has lost its voltage input.
# Use in place of the `cse7766` sensor and its `uart:`; the relay must be the
# switch with `id: relay`.
uart:
id: meter_uart
rx_pin: GPIO7
baud_rate: 4800
parity: EVEN
number:
- platform: template
id: nominal_voltage
name: "Nominal voltage"
entity_category: config
unit_of_measurement: V
min_value: 100
max_value: 260
step: 1
initial_value: 230
optimistic: true
restore_value: true
mode: box
# Readings below this count as 0 A: set it just above what the plug shows
# with the relay on and nothing plugged in.
- platform: template
id: current_floor
name: "Current floor"
entity_category: config
unit_of_measurement: A
min_value: 0
max_value: 1
step: 0.01
initial_value: 0.08
optimistic: true
restore_value: true
mode: box
sensor:
- platform: template
id: meter_current
name: "Current"
device_class: current
state_class: measurement
unit_of_measurement: A
accuracy_decimals: 2
filters:
- throttle_average: 2s
- platform: template
id: estimated_load
name: "Estimated load"
device_class: apparent_power
state_class: measurement
unit_of_measurement: VA
accuracy_decimals: 0
filters:
- throttle_average: 2s
# What the faulty voltage input reads: about 0.4 V now, about 230 V if
# it is ever repaired.
- platform: template
id: meter_voltage
name: "Meter voltage reading"
entity_category: diagnostic
device_class: voltage
unit_of_measurement: V
accuracy_decimals: 1
filters:
- throttle_average: 10s
interval:
- interval: 20ms
then:
- lambda: |-
// The CSE7766 sends a 24-byte frame about every 50 ms: a header,
// 0x5A, coefficient/cycle pairs for voltage (2-7), current (8-13)
// and power (14-19), a flags byte (20), a pulse count and a checksum.
static uint8_t frame[24];
static size_t len = 0;
uint8_t byte;
while (id(meter_uart).available() > 0 && id(meter_uart).read_byte(&byte)) {
if (len == 1 && byte != 0x5A)
len = 0;
if (len == 0 && byte != 0x55 && byte != 0xAA && (byte & 0xF0) != 0xF0)
continue;
frame[len++] = byte;
if (len < sizeof(frame))
continue;
len = 0;
uint8_t sum = 0;
for (int i = 2; i < 23; i++)
sum += frame[i];
if (sum != frame[23]) {
ESP_LOGW("meter", "Checksum mismatch");
continue;
}
auto u24 = [](const uint8_t *p) { return (uint32_t) p[0] << 16 | p[1] << 8 | p[2]; };
const uint8_t head = frame[0], flags = frame[20];
// 0xAA: never calibrated; 0xF? with bit 0: its calibration is corrupt.
if (head == 0xAA || ((head & 0xF0) == 0xF0 && (head & 0x01)))
continue;
// 0xF? with bit 2: the current is below what the chip can measure.
const bool current_too_low = (head & 0xF0) == 0xF0 && (head & 0x04);
const uint32_t voltage_cycle = u24(frame + 5), current_cycle = u24(frame + 11);
if ((flags & 0x40) && voltage_cycle)
id(meter_voltage).publish_state((float) u24(frame + 2) / voltage_cycle);
float amps;
if (!id(relay).state || current_too_low) {
amps = 0;
} else if ((flags & 0x20) && current_cycle) {
amps = (float) u24(frame + 8) / current_cycle;
if (amps < id(current_floor).state)
amps = 0;
} else {
continue; // no new current reading in this frame
}
id(meter_current).publish_state(amps);
id(estimated_load).publish_state(amps * id(nominal_voltage).state);
}3. Repair it Only if you're proficient with electronics repair. It's a mains voltage device - getting it wrong could mean breaking out the fire extinguisher!
Where the fault *might* beIn divadiow's S60 teardown on Elektroda (https://www.elektroda.com/rtvforum/topic4122886.html), the CSE7759B meter chip sits on the back of the ESP module, which stands upright on the main board. Mains voltage reaches the chip through a single module pad marked VI (pin 4, `V2P`, on the chip). The likeliest causes: - a cracked solder joint on the VI pad; - one of the voltage-divider resistors on the main board that feed it, gone open circuit.
Photos: divadiow on Elektroda. Left: the main board's pads for the module. VI is voltage in; IP/IN are current in, and those still work on your plug. Middle: the back of the module, with the meter chip. Right: the chip's pins; |
|
Thanks for esphome template :) I was able to read the current. Compared it with standalone energy meter and it matches pretty good with larger loads, but not so well with small loads. Maybe it's due chip limitations. I don't have history reading from ewelink, I deleted device from app quite sometime ago. I drilled a hole in socket case for direct uart tasmota flashing, I don't see any physical damage for PCB. but who knows, maybe that has caused voltage reading issue. I didn't try uart flashing, socket was just sitting in the box for a month until I found this repo and picked it up again. Here is the script output {'lcdEnergy': 0, 'hourEnergyStart': 0, 'histHourLastTime': '2026-10-20-0-7-13', 'dayEnergyStart': 0, 'histDayLastTime': '2026-10-20-0-7-13', 'monthEnergyStart': 0, 'histMonLastTime': '2026-10-20-0-7-13', 'totalEnergy': 0, 'histEnergyIndex': 0}
18144 bytes of energy history, 0 non-zero |
|
Glad the current reading works Small loads are a limitation of the chip. It measures current across a 1 mΩ shunt, so a 50 mA load gives it only about 50 µV to work with. The config above drops anything under "current floor", so anything under 0.08 A, about 18 W show as 0. You could try taking out the no-load reading instead of cutting at a floor. On an RMS reading, a noise floor adds in quadrature, so it can be subtracted the same way. In the lambda, replace these three lines: amps = (float) u24(frame + 8) / current_cycle;
if (amps < id(current_floor).state)
amps = 0;with: // The input reads a little even with no load. That adds in
// quadrature, so take it out the same way.
const float raw = (float) u24(frame + 8) / current_cycle;
const float idle = id(current_floor).state;
amps = raw > idle ? sqrtf(raw * raw - idle * idle) : 0;Then set Current floor to 0, turn the relay on with nothing plugged in, note what Current shows, and set Current floor to that value. |
|
Successful conversion of a S60TPF (EU) plug. On first try I got "bridge delivery failed", second try went smooth. Result: Converted
Tool version: 1.2.0
Plug model: S60TPF
Plug type / region: Europe (Type E/F)
Stock firmware: 1.2.0
Sonoff backup: Completed
Computer: Debian GNU/Linux 13 (trixie)
Python: 3.12.10 (portable, downloaded by this tool)
Time taken: 4m 42s (this session; the run was resumed)
Stage times: 1=0s, 2=2s, 3=6s, 4=9s, 5=21s, 6=11s, 7=23s, 8=43s, 9=2s, 10=36s, 11=9s, 12=52s, 13=39s, 14=43s, 15=3s
Plug busy: 9=1s, 10=36s, 11=8s, 14=40s
Retries: None
Plug Wi-Fi signal: -54 dBm
Typed the Wi-Fi: No
Joined setup network: No
Name in Tasmota: Sonoff S60TPF
Relay: Switches (seen on the meter)
Power meter: On: 241 V, 0 W; off: 0 V, 0 W |
|
Robust error handling and auto-retry is planned in the next release so any issues (like your bridge issue) are handled automatically. Thankyou for your report. Much appreciated! |
|
Great, I converted from Tasmota to ESPHome with one try! Thanks for this project! Stage 1 of 5 - Confirming prerequisites - Complete (0s)
Stage 2 of 5 - Validating local files - Complete (2s)
Stage 3 of 5 - Leaving Tasmota - Complete (59s)
Stage 4 of 5 - Installing ESPHome - Complete (14s)
Stage 5 of 5 - Checking ESPHome - Complete (1m 20s)
Conversion complete!
The plug is running ESPHome...
Your plug: http://192.168.5.90/
Result: Converted
Firmware: ESPHome
Converted from: Tasmota
Tool version: 2.0.1
Plug model: __
Plug type / region: __
Stock firmware: __
Sonoff backup: Not taken
Computer: Windows 11 (build 10.0.26200)
Python: 3.12.10 (portable)
Time taken: 2m 48s
Stage times: 1=0s, 2=2s, 3=59s, 4=14s, 5=1m20s
Plug busy: 3=45s
Retries: None
Plug Wi-Fi signal: -36 dBm
Typed the Wi-Fi: No
Joined setup network: No
Name in ESPHome: Sonoff S60
Relay: Switches (meter confirms)
Power meter: On: 245.722 V, 2.41192 W; off: 245.722 V, 0 W |
|
You certainly provided and interesting scenario for the tool... Backstory: Where It Got Stuck: Recovery: Going Forward: Thanks again @WildeRNS |
|
Worked great - thanks! Result: Converted |
|
Thankyou for sharing your report @Hassfan! |
|
Thanks for your work! |
|
Thanks for sharing @kacperbiernacki! |
|
Successfully converted a UK S60 plug. However, noticed that the log was throwing up a bunch of errors. Removed power_factor, apparent_power, and reactive_power sensor blocks from the template and all is good. |
|
Thank you Noel! Please could I ask you to share your full log with me? (PasteBin might be a good method) EDIT: no need for those logs, please disregard |
|
@northernnoel81 Those three sensors came from ESPHome's meter driver, which works them out from the meter's raw, uncalibrated readings. On certain loads when the power factor reads just over 1 the driver logs every such reading (many a second). This will be fixed in the next release (next few days). The fix involved working them out from the calibrated voltage, current and power instead. I've also sent a fix upstream to ESPHome for the log noise: PR:22224 Removing the blocks as you did is fine. Thankyou for reporting this! |
|
Thanks a lot @adamsthws ! |
|
Thankyou for reporting back @levaitamas ! |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Example report
At the end of it's run the tool displays your conversion report, please drop that report in here.
Your report allows others to see whether it converted cleanly, stopped partway, or you
only ran the read-only checks. Every report helps.
Found a bug that needs a code fix? Open an issue as well, and link it here.
All reactions