v2.3.0

• The tool's code is a package of modules, each for one thing - the command
  line, a run's context, its route, running it, its report, the plug in its
  eWeLink account - with each chip family's steps under
  tools/autoflash/routes/<family>/, where one file held it all before.
  Nothing a run does changes.
• The tool converts the Sonoff S61 (--firmware openbeken, esphome or
  sonoff), in every direction: from Sonoff's firmware through eWeLink, from
  OpenBeken or ESPHome to the other or back to Sonoff's firmware, each one
  update the plug installs as it restarts; the plug's own Wi-Fi and meter
  calibration stay on the plug for each firmware to read. Its backup (the
  plug's own data, and Sonoff's firmware from the public dump) is taken
  through OpenBeken's flash reads after the first conversion: a run to
  ESPHome installs OpenBeken first, as the interim firmware, backs the plug
  up through it, then has it fetch ESPHome, so ESPHome keeps no way to read
  the plug out. The tool sends the interim firmware with a marker after it,
  naming the app it installs, which is how the firmware knows it is the interim
  one; a marker for any other app never counts, and is erased. The interim
  firmware is named autoflash-recovery-CDEF from its first start, as the
  S60's interim firmwares are, and once it has fetched the next firmware it
  erases its own settings, so ESPHome - or a later OpenBeken - finds nothing
  of it. A run that lost its record recognises a plug left on it, and goes on
  from there. Tested end to end in the emulator in every direction; not yet on
  a real plug.
• From Sonoff's firmware the run finds the plug in eWeLink before it asks
  which firmware you want, because which firmware a plug can have depends on
  what plug it is. The question is a stage of its own (Choosing the firmware),
  after Discovering the plug; with --firmware you are not asked.
• The S61's firmware is published: OpenBeken 1.1.0 (OpenBK7231T_App at
  ce1abad with the 4 MB table, a hook before an OTA's restart, the tool's
  OpenBeken driver and the S61's table for it) and ESPHome 1.2.0
  for the S61 (built with ESPHome
  2026.10.0 on
  LibreTiny 1.13.0), built and pinned by tools/repo/update_firmware.py openbeken and esphome --plug sonoff-s61.
• The repository is laid out by what things are: tools/espressif/ and
  tools/beken/ for each chip family's tooling and emulator, tools/ewelink/,
  tools/repo/, devices/<plug>/ for what is one plug's alone, tests/
  mirroring tools/. The published firmware, firmware.json and SHA256SUMS
  are together in artifacts/, where SHA256SUMS names its files bare, so
  sha256sum -c works in the directory a release's files are downloaded to.
  On Windows, start.cmd is the one start file, whether you double-click it
  or run it from a terminal.
• Breaking for Home Assistant adoption: the ESPHome configs moved to
  devices/sonoff-s60/esphome.yaml and devices/sonoff-s61/esphome.yaml,
  and the package_import_url a plug gives Home Assistant names the new
  paths. A plug on ESPHome 1.4.0 or earlier names the old path, which no
  longer exists, so Home Assistant cannot adopt it until it is updated to the
  image built from the moved config - which running the tool again does
  (below); the plug itself runs as before.
• When Home Assistant adopts a plug, it now writes a short config that loads
  this project's ESPHome config, instead of a full copy. It uses the release
  your plug's firmware came from, which cannot change, so your plug gets a fix
  only when you choose a newer release. A plug adopted earlier keeps its copy;
  docs/home-assistant-adoption.md explains how to switch it to the short config.
• ESPHome for the S60 is 1.6.0: a change to its config, built with ESPHome
  2026.10.0 as
  1.4.0 was. Its bootloader is unchanged, so a plug on ESPHome already is
  not given a new one. It is the image built from the moved config, and
  names the plug as every firmware does (below). Its apparent power,
  reactive power and power factor are worked out each second from the
  calibrated voltage, current and power of the same readings, where they
  came from the meter's raw readings:
  a load close to resistive took those past a power factor of 1, and the log
  filled with each reading refused as impossible, many a second
  (reported).
  Reactive power is 0 while power is within 1.5% of voltage times current:
  the meter gets them within about 1% on a resistive load, where a 1 kW
  heater used to read up to 148 var. And they change only in a second steady with
  the last: as a load switches, the meter's power follows its current a
  second or three behind, and a 2 kW heater's thermostat used to read up
  to 1782 var and a power factor of 0.66.
• Every firmware the tool installs names the plug alike, in lower case as
  ESPHome requires: the firmware and the last three bytes of its MAC, as its
  hostname and its name inside the firmware - tasmota-abcdef (Tasmota's
  device name too), esphome-abcdef (its friendly name esphome abcdef) and
  openbeken-abcdef (both of OpenBeken's names, its mDNS and DHCP
  hostnames), where OpenBeken was named S61. What plug it is goes in
  Tasmota's template, Sonoff-S60 where it was the product model (Sonoff S60TPG), and ESPHome's comment: one for every model, so one image serves
  them all. The report gives neither the name nor the plug type and region:
  the model line says both.
• The S60's installer is sent to Sonoff's updater as version 9.9.9, as the
  S61's firmware is, where it was sent as its own version (4.4.4): a Sonoff
  release numbered above the installer would otherwise have stopped the
  conversion, should the S60's updater take only a newer version as the
  S61's does. The installer itself, and its published file, are unchanged.
• The report says whether the end-of-run checks passed (Checks passed),
  instead of giving the relay's and the power meter's results: what is checked
  can differ from one kind of device to another, and the report stays the
  same. For a plug the checks still switch its relay off and on, and what
  they found is in the run's log.
• A run from a converted plug - back to Sonoff's firmware, say - reports
  the plug's model and its Sonoff firmware from what the tool kept of the
  plug at its first conversion; it used to give __ for both.
• While the report is put together after the last stage - the device's
  checks take a few seconds - "Generating your report..." shows with the
  stages' spinner, and goes when the report is shown.
• The links after a successful run start with GitHub Sponsors, before Ko-fi
  and PayPal.
• The addresses of a list of links line up under one another.
• At PROCEED, an answer other than the word - an Enter or a y pressed by
  habit - asks again ("Only the TYPED word PROCEED is accepted"); it used to
  stop the run. q stops. Ctrl-C there stops the run at once, as at every
  question; it used to count as a first press during work.
• A Ctrl-C at a question is not shown as ^C, and what the run says next
  starts on a row of its own.
• A run starts at the top of the window, with all of it to use: what the
  window showed is scrolled up into its scrollback, not cleared, so it can
  still be scrolled back to.
• A question cut short by Ctrl-C or q - PROCEED, say - is taken off the
  screen with its note when the run stops, as an answered one is; it used to
  stay, with its stage shown twice: underway above it, stopped below.
• If a step was interrupted last time and the device does not show it
  finished, the tool now repeats it by itself. It used to ask you, and if you
  answered "it did finish" for a step that had not, the run waited for good on
  a firmware never sent.
• Never two blank lines in a row: one left above something taken off the
  screen - "Looking for supported devices..." - no longer doubles the next.
• In VS Code's terminal a run starts under the command that started it,
  where it starts at the top of the window elsewhere: VS Code pins a command
  scrolled out of sight over the window's top rows, which covered the run's
  first.
• An S61 whose new firmware its bootloader would not install starts
  Sonoff's firmware again: the run now sends the firmware again by itself
  (twice at most), instead of asking you to switch the device off and on again
  and again. You are asked PROCEED once a run, not again for this. A run that
  stopped to ask you to switch the device off and on takes it as done when you
  run it again. The same goes for ESPHome fetched by OpenBeken (J2, O1), which
  restarts by itself to install it: if OpenBeken's uptime shows it has
  restarted since, ESPHome was not installed, and it is fetched again, with no
  switch off and on to ask you for. The S61's fault suite has each case, an
  image its bootloader refuses (--simulate-bad-image STEP).
• A step recorded as done that the device disagrees with is now done again by
  itself; the run used to ask you whether to: on an S61, a plug still on the
  firmware it was leaving; on an S60, a high slot, partition table or
  Safeboot not as the step left them, or the recovery firmware where the
  official app should be.
• A device not seen on the network at the start is looked for twice more
  by itself, 15 s apart, before the run asks you what to do: one just plugged
  in, or on a busy Wi-Fi, answers a moment later.
• If the device gives no answer to a password or key check, the tool tries
  again by itself with what you typed, before asking you to choose again.
• On an S60, an upload cut off by the network is sent again by itself once
  the device shows it did not take it; it used to be left to you to upload
  through the device's page. An upload the dev...

Emulator source: QEMU 64aed50

The source of the emulator the Sonoff S60 runs on, so that its image builds from this repository alone: tools/espressif/emulator/emu.sh downloads it once, checks it against the SHA-256 emu.Dockerfile pins, and builds with no network (see docs/emulator.md).

• qemu-lcgamboa-64aed50.tar.xz: lcgamboa/qemu, branch picsimlab-esp32 at commit 64aed503e34a7f52f648374d7d5706ca6d71b606, unmodified, with the subprojects its build fetches (dtc, keycodemapdb, berkeley-softfloat-3, berkeley-testfloat-3, unicode-ident-1-rs).
• SHA-256 37f3cbc81b82c43a1bfa44b75c95278a506c871380be65e3727582f9c1640895.

QEMU is licensed under the GPL, version 2. This project's changes to it are the patches in tools/espressif/emulator/patches/, applied when the image is built. This commit includes lcgamboa/qemu #13 to #17, see docs/upstream-contributions.md.

One release holds one archive, named after the upstream commit, and is never changed: a new pin is a new release. This one follows emulator-source-qemu-e39508f, which stays for older checkouts. It is not a release of the conversion tool.

Emulator source: QEMU e39508f

The source of the emulator the Sonoff S60 runs on, so that its image builds from this repository alone: tools/emulator/emu.sh downloads it once, checks it against the SHA-256 emu.Dockerfile pins, and builds with no network (see docs/emulator.md).

• qemu-lcgamboa-e39508f.tar.xz: lcgamboa/qemu, branch picsimlab-esp32 at commit e39508f79cb0681bbe15cfcebd40a3f45cdc3c48, unmodified, with the subprojects its build fetches (dtc, keycodemapdb, berkeley-softfloat-3, berkeley-testfloat-3, unicode-ident-1-rs).
• SHA-256 863c653128bd9dafd353e5321d5e31e00337dfd42346ee30e8d496eadaaf3b82.

QEMU is licensed under the GPL, version 2. This project's changes to it are the patches in tools/emulator/fork/, applied when the image is built; several are also offered upstream (lcgamboa/qemu #13 to #17, see docs/upstream-contributions.md).

One release holds one archive, named after the upstream commit, and is never changed: a new pin is a new release. This one replaces the emulator-source release (deleted 2026-10-29, see docs/emulator.md). It is not a release of the conversion tool.

Emulator source: BekenEmulator d9a3772

The source of the emulator the Sonoff S61 runs on, so that it is set up from this repository alone: docs/s61-tools/emulator/bk-emu.sh downloads it once, checks it against the SHA-256 docs/s61-tools/emulator/UPSTREAM pins, and applies this project's patches.

• bekenemulator-d9a3772.tar.xz: openshwprojects/BekenEmulator at commit d9a3772a26fa92158be72faf46855726ef8e21d7, unmodified: its src/, tests/, tools/, README and requirements, and none of its firmwares/. Firmware dumps, Sonoff's among them, are never published by this repository; bk-emu.sh fetches the ones it needs from upstream's repository, which publishes them. Made with bk-emu.sh source (git archive, so the same commit gives the same bytes).
• SHA-256 f4e3169f0b240e1978febafe2bb8452c5f6f8727ebb8ff4ac36c18a890588abf.

BekenEmulator publishes no licence. This project's changes to it are the patches in docs/s61-tools/emulator/patches/, applied when bk-emu.sh sets it up.

One release holds one archive, named after the upstream commit, and is never changed: a new pin is a new release. It is not a release of the conversion tool.

v2.2.0

• ESPHome for the S60 is 1.4.0: a change to its config, built with ESPHome
  2026.10.0 as
  1.3.0 was. It corrects the meter as Sonoff's firmware does: by the 1.02
  its board calls for, and by the plug's factory calibration
  (#7) - from Sonoff's
  settings where the plug still has them, or, on a plug converted through
  Tasmota, which lost them, from its Sonoff backup, which the tool now
  gives it. Energy, and the daily, monthly, yearly and total energy, are
  counted from the meter's own pulses, calibrated the same way, so they
  agree, and stay right at loads too small for the power reading; the
  totals carry on from 1.3.0's. Its bootloader is unchanged, so a plug on
  ESPHome already is not given a new one.
• A plug converted to Tasmota has its meter calibrated as Sonoff's firmware
  had it: by its board's factor, which read 2% low on Tasmota before, and
  by its factory calibration from its Sonoff backup. Tasmota takes one
  scale for each reading, so the factory calibration's set from 300 W up
  does not carry over. A plug converted before is calibrated by running
  the tool on it and keeping Tasmota (--firmware tasmota); one calibrated
  by hand is left as it is.

v2.1.3

• A plug converted to Tasmota went on to switch nothing after Tasmota had
  restarted six times in a row, each within 10 seconds of starting: taking
  that for a boot loop, Tasmota goes over to its fallback module, Generic,
  keeping only its Wi-Fi (#8).
  The plug's template is now its fallback too. The final check (H1) makes it
  so on a plug converted by an earlier version, and puts the template back
  on one that has already gone over to Generic.
• A plug on ESPHome in safe mode - which ESPHome starts after it was stopped
  within a minute of starting ten times in a row - was taken for one part way
  through a conversion: to stay on ESPHome, the run sent it the startup
  firmware and installed ESPHome again. It is now known for ESPHome in safe
  mode, and the run waits the five minutes until ESPHome restarts as itself.

2.1.2 was withdrawn on the day it was published, from a commit holding work
not meant for release; its number cannot be used again. 2.1.3 is the tool
2.1.2 was.

v2.1.1

• A plug converted to Tasmota could finish without the plug's template -
  when it did not go in with Tasmota's reset and the second try did not take
  either - and so switch nothing: Home Assistant showed only its restart
  button and Wi-Fi (#8).
  The run now checks the template is in place before it calls the plug
  converted, and puts it back if not. The final check (H1) does the same, so
  running it on a finished plug puts a missing template back, keeping the
  plug's other settings.
• A converted plug that had lost its template was taken for one part way
  through a conversion, and sent an update only ESPHome takes: the run
  waited 4 minutes, and stopped. It is now known for a Tasmota without its
  template - found on the network, or given with --plug-ip - and goes on as
  any converted plug does; choosing Tasmota gives it the template alone,
  keeping its other settings, such as MQTT.
• A device with ESPHome's update service and no web page was listed as a
  plug part way through a conversion, whatever it was - another ESPHome
  device on the network, say. Only a plug this computer has a record of is
  listed so now.
• A run stopped before it wrote anything no longer hides, from the next run,
  the run before it that knew where the plug had got to.
• The go-ahead to replace a plug's Tasmota or ESPHome is asked once a run,
  not again when a step is tried again by itself.
• The report of a run from a converted plug said "Sonoff backup: Not taken"
  although this computer had the plug's backup; it now says it was taken by
  an earlier run.
• On Python 3.10, a terminal that reports no size - ssh without one, some
  IDE consoles - was taken as 20 columns wide, and every line wrapped or cut.

v2.1.0

• A converted plug ends on Tasmota
  16.0.0, the
  latest release, where it ended on 15.6.0. Its files now come from the
  release's own page on GitHub. A run left part way by an earlier version
  carries on by itself: with 16.0.0, or - if it had installed 15.6.0 already -
  on 15.6.0, checked byte for byte as ever, which Tasmota's own page updates.
• ESPHome for the S60 is 1.3.0: the same config, built with ESPHome
  2026.10.0,
  the latest release, where 1.2.0 was built with 2026.9.1. Its bootloader is
  unchanged, so a plug on ESPHome already is not given a new one.
• The firmware the tool installs is moved to each new Tasmota and ESPHome
  release one way, written down in
  docs/updating-firmware.md.

v2.0.2

• The steps that write firmware keep the plug busy for about 40% less time:
  18 seconds where they took 30, on the emulator. Every block written was
  read back and sent to this computer to compare, doubling what crossed the
  network while the plug could answer nothing else. Each block now comes
  with its hash, checked on the plug before it is written - a block damaged
  on its way is asked for again, alone - and each step's report still
  hashes everything it wrote, which this computer checks.
• A step's 20 seconds of retries on the plug were counted from its first
  failure and never begun again, so after one short Wi-Fi drop a later one
  found them spent, and the step stopped ("returned HTTP -1 after 1
  attempts"). They now count only the time spent failing
  (#5).
• The plug or the network dropping a request part way through a step - a
  connection reset in a Wi-Fi outage, say - was put as "something unexpected
  went wrong", though the step was tried again as for any other network
  trouble. It now says the connection to the plug was lost.
• A plug the run had just restarted onto your Wi-Fi could be taken, as it
  started up, for one that had lost its settings, and the run asked you to
  join a network of the plug's that had gone a moment later - then, after 15
  minutes, stopped with "something unexpected went wrong". The plug is now
  given a minute to come back first, and a run that gives up on its network
  stops at that step, as any other.
• A send of the installer that failed before the plug was told to fetch it -
  eWeLink's servers dropping this computer's connection, say - was put down to
  this computer's firewall keeping the plug out. It now says the connection to
  eWeLink failed and nothing was sent, or, for a send refused, only that
  nothing was sent.
• Swapping the temporary startup firmware for the official one (G1) first
  checks the plug runs official Tasmota; a Wi-Fi blip as it asked stopped the
  step, as if the check had failed. The plug is now asked again once it
  answers.
• A Tasmota plug that did not answer for a moment when the run read its
  Wi-Fi details - a Wi-Fi blip, say - had you asked to type them. It is now
  asked again once it answers, before you are.
• The command that starts a step on the plug, lost to a Wi-Fi blip before it
  reached the plug, left the step waiting for a plug that never began, then
  failing. It is now sent again once the plug answers.

v2.0.1

• A plug brought back from Tasmota's own safeboot finished its conversion,
  then the run stopped with "something unexpected went wrong" instead of its
  report, which could not name where the plug started. A Tasmota there with
  a web password is now asked for it, where the run stopped, and the rest of
  the run treats the plug as the Tasmota it was.
• The look round the network for a converted plug, 5 to 10 seconds - longer
  when one this computer converted may be restarting - showed nothing on
  screen, so the run seemed to wait for a key; one pressed then was taken as
  the next question's answer, an Enter as its default. The look now says so
  while it looks, then leaves the screen, and a key pressed while nothing is
  asking is dropped.
• The firmware question gives the firmwares by name alone.