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.

Emulator: public plugs

Plugs for the emulator with nothing of Sonoff's or of any real plug in them, from which the firmware a conversion ends on is tested (docs/emulator.md#public-plugs). Not a release of the tool.

v2.0.0

ESPHome, as well as Tasmota: the run asks at the start which the plug should
end up running. And a plug can move between them later, or back to Sonoff's
own firmware.

A major release because the tool is now Autoflash, and the names that called
it after the S60 have gone:

• tools/s60_autoflash.py is tools/autoflash_cli.py. start.sh,
  start.ps1 and start.cmd run it as before; a command that named the
  old file needs the new name.

• The settings it reads start AUTOFLASH_. In .env, S60_WIFI_SSID,
  S60_WIFI_PASSWORD and S60_SUDO_PASSWORD are still read, and the run asks
  for them to be renamed; S60_PYTHON_HOME is not, and is now
  AUTOFLASH_PYTHON_HOME.

• A run looks for the plug first. One already on Tasmota or ESPHome is offered
  the other two: Tasmota, ESPHome, or Sonoff's own firmware and settings put
  back from the backup taken when it was first converted (only where that
  backup is on this computer). One left part way through a conversion is
  recognised, and can go on to any of the three.

• Every way round is over the air and checked as the first conversion is:
  every block read back and compared byte for byte, and the plug switched
  only once all of it is.

• The bootloader becomes ESPHome's on every route, once: it starts all three
  firmwares, and rolls back an update that fails to start. The final check of
  a Tasmota plug now covers it too.

• Choosing ESPHome needs nothing built or installed: the run installs a
  ready-made ESPHome for the S60 (ESPHome/sonoff_s60.yaml), with the plug's Wi-Fi
  written in, in memory only. It joins your Wi-Fi by itself, has no password
  to start with, as Tasmota has none, and Home Assistant finds it and can
  adopt it.

• Every block of ESPHome is read back and checked before the plug switches to
  it. The plug's memory layout stays as Sonoff made it; its bootloader becomes
  ESPHome's own, so ESPHome can roll back an update that fails to start.

• The answer is kept with the run, so carrying on an unfinished run carries
  on the same way. --firmware tasmota or --firmware esphome answers it in
  advance, as an unattended run must.

• The report says which firmware the plug ended up with, and the relay and
  meter are checked through ESPHome on its route.

• The report calls Windows 11 so where Python 3.10 or 3.11, not the tool's
  portable one, called it Windows 10.

• The report's answers are shorter: "(portable)" for the tool's own Python,
  "Failed" for a backup that failed, "Switches (meter confirms)" for the relay.

• The plug's own network is looked for by this plug's names only - Tasmota's,
  and the ESP_ name it sometimes shows instead, which was missed before - so
  a neighbour's Tasmota is never mistaken for it. Wherever you are asked to
  join it, its exact name is given.

• That ESP_ name is only the one Tasmota's network has for a moment, as it
  turns it on and before it names it - which a computer can still list for a
  minute after, perhaps first. The network is now taken by its real name
  wherever that is listed, and caught in that moment it is looked at again,
  where before you could be asked to join one already gone.

• A power cut while the memory layout is rebuilt for Tasmota no longer costs
  Tasmota its settings. The rebuild wrote over where they were kept, so the
  plug came back waiting on its setup network, and the next run then stopped
  for good on the plug having changed. Now the settings are moved aside
  first, with an interim layout pointing at them, and the run itself waits
  for the plug, puts them back and tries again - up to three times in all,
  for a power cut, a read-back that differed, or the plug changing since its
  checks. A plug that did lose them is found on its setup network.

• A plug switched off and on before the installer has done its work goes
  back to Sonoff's firmware - by design, so nothing is lost - but the run then
  waited a quarter of an hour for an installer that was gone. It now sees
  Sonoff's firmware and sends the installer again, up to three times.

• A backup cut off by the home Wi-Fi going - the installer then raises its
  own network - is read again wherever the installer is once you have joined
  that, where before both tries went to its address on the home network and
  timed out, and an unattended run carried on without a backup.

• Tasmota sent through the installer whose upload took, though its answer
  was lost on the way back (a weak signal), joined your Wi-Fi by itself -
  and the try again waited a quarter of an hour for the installer, gone. It
  now finds Tasmota there, on your network or its own, and carries on.

• A plug whose Tasmota lost its settings part way through - switched off and
  on 7 times, say - waited on its own network while the run kept looking for
  it on yours, and once past setting Tasmota up (F4), the run asked for Wi-Fi
  details it could not use. It is now found on its own network and set up
  through it again, and Tasmota set up again where its template went too.

• Tasmota given the Wi-Fi on its setup network that took the details and
  restarted onto your Wi-Fi before saying so was sent them again, and the run
  then waited a quarter of an hour for you to join its network - gone. A
  network gone after no word is now taken as the plug on your Wi-Fi, and it
  is looked for there.

• An ESPHome plug whose API is encrypted, asked for its Wi-Fi without the
  key, could be taken for one without the tool's Wi-Fi action, where it
  answered and hung up before the tool's next write; the run then asked for
  the Wi-Fi password rather than for the key. Its answer is now read.

• A run started again (--new) after the memory layout was rebuilt for
  Tasmota, before official Tasmota was set up, took the plug for one on its
  way from ESPHome and sent it round steps that need Sonoff's layout, which
  never finished. This computer's record of the plug now tells the two
  apart, and the run goes on from official Tasmota.

• A plug offline in eWeLink when the installer is to be sent - after a send
  cut off part way, say - is waited for for up to three minutes, then the
  run says to switch it off and on, where before it was refused at once
  and the firewall blamed.

• A run stopped as the memory layout was committed - its window closed, say -
  whose plug then finished the commit by itself, carried on by checking the
  plug's network on the startup firmware, which cannot say it, and went back
  to the start of the conversion with no way forward. It now sees the commit
  done and carries on from there.

• After the installer could not be sent again (the plug offline in
  eWeLink), a plug slow to answer made the run ask you to join the
  installer's own network, which it had never raised. The next try now
  follows.

• ESPHome's page arriving damaged - a byte changed on its way - stopped the
  run with "something unexpected went wrong". It is now asked for again, as
  when the connection drops.

• A power cut while the official startup firmware was written back (G1)
  left the sector being written half done, and every later run refused to
  carry on - the conversion stuck for good, though the plug kept running
  Tasmota. That one sector is now written again.

• The installer gives up an upload that has gone silent for a minute. A
  computer going to sleep part way through sending it Tasmota (D1) - its lid
  closed, say - left the installer waiting for good: it answered nothing
  more, neither on your network nor on its own, until it was switched off
  and on.

• An upload of Tasmota to the installer cut off by the network is noticed
  after two minutes, not five, and tried again - through the installer's
  own network, if it has raised that and you have joined it.

• Tasmota sent through the installer's own network, after an earlier try
  cut off by the network had the installer save your Wi-Fi for it, joined
  your Wi-Fi by itself - while the run waited for a setup network it never
  raised, and asked you to join it. The run now sends you back to your usual
  Wi-Fi and finds it there; any wait for Tasmota's setup network also looks
  for Tasmota on your network.

• A Tasmota plug too busy to say its template in time - just started, or
  answering the run's look round the network - was taken for a Tasmota not
  yet set up as an S60, and sent down the wrong route, which never finished.
  It is asked again, and left to the next look rather than guessed at.

• A plug switched on as the run starts - offline in eWeLink, and not yet
  answering on the network - is waited for for up to a minute while it joins
  the Wi-Fi and the cloud, where before the run stopped at once to ask.

• An upload of official Tasmota to the startup firmware that stalls is
  noticed after two minutes, not ten, and tried again from a restart - up
  to three times - before it is left to be done by hand.

• The installer is now 4.4.3. It starts even when an upload of Tasmota into
  Sonoff's slot (D1) was cut off part way - by a power cut, or the computer
  stopping - where 4.4.2 refused to start, leaving a plug with no network at
  all that only a serial cable could recover.

• A run started again after D1 was cut off finds the plug on the installer
  and carries on from the backup, instead of looking for it in eWeLink -
  which it cannot answer - and being told to switch it off and on. An upload
  to the installer that stops is tried again by itself, three times in all.

• Ctrl-C no longer stops a run part way by itself. The first asks, at the
  end of the stage under way, whether to stop there - carrying on by itself
  after 30 seconds; a second within ten seconds stops at once, as before. At
  a question, or waiting on you, it stops at once. Closing the window stops
  the run, and the next one says that is why it stopped.

• Two runs on the same plug at once are refused, the second told which run
  has it: each would write over what the other was doing. The one refused
  leaves the other's l...