TankSync v3.6.7 — hub RX display redesign + LoRa signal scale

RX-only firmware (display/LED/web) + PWA RSSI scale. TX unchanged. WiFi/LoRa/
reception core byte-for-byte unchanged. Full-circle water, OTA screen (web-UI +
manual + demo) with 24-LED halo progress, flow-state + signal on the hero,
surface-LED breathe, post-reboot '11d ago' -> '--' fix. (esp32/DevKit variant
guarded — no GC9A01 there.)

---

Downloads (every variant for this firmware version)

Transmitter — ESP32-C3 SuperMini

• …-transmitter-lora-esp32c3-<tag>.bin — LoRa SKU (RYLR998 module)
• …-transmitter-lite-espnow-esp32c3-<tag>.bin — Lite SKU (ESP-NOW, built-in radio, no module)

Receiver / Hub

• …-receiver-esp32-<tag>.bin — ESP32 DevKit
• …-receiver-esp32s3-<tag>.bin — ESP32-S3 SuperMini

Each variant ships two images:

• plain .bin — OTA app image, flash at 0x10000, or use the one-click browser flasher / in-app OTA.
• …-full.bin — full-flash image for a fresh/blank board, flash at 0x0 with esptool: esptool.py write_flash 0x0 <file>-full.bin.

Hub RX reliability + ACK correctness (receiver-only; TX unchanged)

• ACK-after-accept gate (deleted/orphaned tank no longer falsely ACKed)
• Missed-packet hardening: UART ring 2048, rx_task on core 1, /api/lora health counters
• Reliability-core frozen at this baseline (docs/frozen-core-v3.6.6.md)
  Verified: live hub + real tank ~6h + through a floor, zero missed packets.

---

Downloads (every variant for this firmware version)

Transmitter — ESP32-C3 SuperMini

• …-transmitter-lora-esp32c3-<tag>.bin — LoRa SKU (RYLR998 module)
• …-transmitter-lite-espnow-esp32c3-<tag>.bin — Lite SKU (ESP-NOW, built-in radio, no module)

Receiver / Hub

• …-receiver-esp32-<tag>.bin — ESP32 DevKit
• …-receiver-esp32s3-<tag>.bin — ESP32-S3 SuperMini

Each variant ships two images:

• plain .bin — OTA app image, flash at 0x10000, or use the one-click browser flasher / in-app OTA.
• …-full.bin — full-flash image for a fresh/blank board, flash at 0x0 with esptool: esptool.py write_flash 0x0 <file>-full.bin.

TankSync v3.6.5

Receiver fix: the WiFi setup hotspot (TankSync-XXXX) could be completely invisible on v3.6.4 — the setup AP had moved to WiFi channel 1, which does not radiate on some ESP32-S3 hub boards. The setup AP is back on channel 6 and appears within ~2 seconds.

If a hub on v3.6.4 shows the setup QR but the hotspot never appears: flash tanksync-receiver--v3.6.5-full.bin over USB, or update OTA while the hub is still connected to WiFi.

Transmitter: version bump only — no functional changes from v3.6.4.

---

Downloads (every variant for this firmware version)

Transmitter — ESP32-C3 SuperMini

• …-transmitter-lora-esp32c3-<tag>.bin — LoRa SKU (RYLR998 module)
• …-transmitter-lite-espnow-esp32c3-<tag>.bin — Lite SKU (ESP-NOW, built-in radio, no module)

Receiver / Hub

• …-receiver-esp32-<tag>.bin — ESP32 DevKit
• …-receiver-esp32s3-<tag>.bin — ESP32-S3 SuperMini

Each variant ships two images:

• plain .bin — OTA app image, flash at 0x10000, or use the one-click browser flasher / in-app OTA.
• …-full.bin — full-flash image for a fresh/blank board, flash at 0x0 with esptool: esptool.py write_flash 0x0 <file>-full.bin.

TankSync v3.6.4 — WiFi setup reliability + LoRa link self-healing

This release fixes two long-standing reliability problems: a setup Wi-Fi hotspot
that was slow to appear and hard to join, and a LoRa condition that could make a
transmitter silently miss readings for a long stretch. Both are now fixed and
bench-verified end to end.

── Hub (Receiver) ──────────────────────────────────────────────────────────────

• Setup Wi-Fi hotspot is now instant and reliable. The hub's "TankSync-XXXX"
setup network was intermittently invisible, slow to show, or wouldn't accept a
connection. Root cause: Wi-Fi modem power-save was on, so the radio slept
between beacons. It's now disabled (WIFI_PS_NONE) with a standard access-point
configuration — the hotspot appears within a second, stays visible, and the
setup page loads quickly. "Scan networks" and connecting to your home Wi-Fi
work reliably.

• Offline mode: run the hub on its own hotspot with no home Wi-Fi — pair tanks
and see levels locally; the setup QR is hidden and your tanks are shown on the
display instead.

• Round display (camera-module hubs): the screen framebuffer now lives in PSRAM,
freeing internal memory so Wi-Fi association is never starved (fixes a blank
screen / failed-join case on those units).

• LoRa self-healing: if the hub's radio ever gets stuck refusing to transmit
(acknowledgements would silently stop), it now auto-recovers over the wire —
full config rewrite, then a soft reset, then a factory reset if needed, each
verified by a real test transmission.

── Transmitter ────────────────────────────────────────────────────────────────

• LoRa self-healing (the big one). A transmitter's radio module could get into a
stuck state where every send was rejected — and nothing cleared it, so the
device could miss readings for 30 minutes to hours until it happened to reset.
The transmitter now detects that state and recovers automatically on the very
next wake: a full config rewrite, escalating to a soft reset and factory reset
if needed, each confirmed by a real test send. A stuck radio becomes one missed
cycle instead of hours of silence.

• Reliable wake. The command that returns the radio to transmit mode after sleep
could fail (a stray wake byte corrupted it), risking a missed cycle. The wake
sequence is now robust and guarantees transmit mode on every wake.

• Pairing verified end to end: pair in ~2 seconds, then normal
wake → measure → send → acknowledge → sleep cycles deliver reliably.

• Cleaner sleep power handling. The sensor's power gate is driven low on every
sleep entry (ultrasonic off) and high on wake (ultrasonic on) — the simple,
proven scheme — with the LoRa module sleeping via its own firmware sleep mode.
This removes the GPIO deep-sleep "hold" experiments that could leave the
sensor rail partially powered (flickering LED, wasted battery) on some units.

• Default transmit power is now 14 dBm (was 22). Bench links run with ~40 dB of
spare signal margin, and the full-power burst was the peak current draw that
could sag the battery rail and trigger a brown-out backoff (seen as readings
pausing for a stretch, then resuming). 14 dBm still comfortably covers
long-range installs; any individual transmitter can be raised back up from
the hub's settings (LoRa power) if a specific site needs it.

── Notes ───────────────────────────────────────────────────────────────────────

• Device identity uses each transmitter's factory-unique hardware ID, so the hub
always distinguishes and remembers its own transmitters — even across address
or network-ID changes.

• The earlier multi-network Wi-Fi roaming experiment (which caused the hotspot
to disappear) has been removed; the hub uses the proven single-network setup.

---

Downloads (every variant for this firmware version)

Transmitter — ESP32-C3 SuperMini

• …-transmitter-lora-esp32c3-<tag>.bin — LoRa SKU (RYLR998 module)
• …-transmitter-lite-espnow-esp32c3-<tag>.bin — Lite SKU (ESP-NOW, built-in radio, no module)

Receiver / Hub

• …-receiver-esp32-<tag>.bin — ESP32 DevKit
• …-receiver-esp32s3-<tag>.bin — ESP32-S3 SuperMini

Each variant ships two images:

• plain .bin — OTA app image, flash at 0x10000, or use the one-click browser flasher / in-app OTA.
• …-full.bin — full-flash image for a fresh/blank board, flash at 0x0 with esptool: esptool.py write_flash 0x0 <file>-full.bin.

# TankSync v3.6.3 — the range & reliability overhaul

This one took a full day of live A/B testing on real walls and real floors, and it was worth it. I traced "it worked at long range in June, now it misses for hours" down to three independent bugs — and fixed all three. A link that delivered zero packets through two concrete floors before this release measures ~80% delivery after it, on the same hardware in the same spots.

What was wrong, and what's fixed

1. Network IDs outside the radio's supported range.
Pairing used to assign LoRa network IDs the RYLR998 doesn't actually support (the datasheet allows 3–15 and 18). Out-of-range IDs put the radio into undefined sync behaviour: packets dropped regardless of signal strength, and ACKs vanished one-way. New pairs now draw only valid IDs, and a transmitter stuck on an old out-of-range ID logs a clear error telling you to re-pair.

2. The radio was assumed ready, not verified.
Since v3.3.0 the transmitter power-gates its radio to save battery — but gave it only 50 ms to wake before sending. A module that wasn't ready meant the whole report cycle vanished silently. The transmitter now probes the radio until it actually answers, verifies its configuration by query, and after any failed delivery checks whether the module is even alive — so the logs finally tell you where a loss happened.

3. ACKs that never left the hub.
The hub fired its ACK and never checked whether the radio accepted it. Under channel congestion the module refuses the send (+ERR) — and the transmitter burned its whole retry ladder waiting for an ACK that was never transmitted. The hub now verifies every ACK transmission, retries once, and logs loudly if its downlink is deaf.

Range and delivery improvements

• Maximum forward-error correction (coding rate 4/5 → 4/8) on both ends. My A/B through two concrete floors: 0% → ~75–80% delivery at −76…−94 dBm. Costs a little airtime; irrelevant at a 5-minute reporting cadence.
• Smarter retries, battery-aware. Five fast retries, then one late retry ~50 s later — because a single fade swallows all back-to-back attempts, but rarely survives a minute. The late retry only runs when energy is free (mains, solar charging, or battery ≥ 30%); a low battery banks the energy instead.
• Transmit power can never silently drop. Power values are validated on both ends (a stale byte could previously leave a radio at 0 dBm — hub hears you, you never hear the hub). Hub power overrides now genuinely reach the transmitter too.
• Radio flash wear eliminated. The RYLR998 persists every config write to flash rated 200K cycles — per-wake rewrites were burning ~1,400/day. Config is now verified by query and written only on real change.
• ~0.5 mA transmitter standby. The radio is hard-gated during deep sleep with its own sleep mode; the boot probe absorbs the cold start on every wake.
• Health you can see. lora_ok in the hub API and on the round display, a radio self-heal loop instead of a deaf-until-reboot hub, the firmware version echoed in every boot and every sleep line, and module error codes surfaced in plain text.

Upgrading

1. Update both the hub and your transmitters to v3.6.3 (OTA from the hub UI / app as usual). The new radio parameters propagate to the modules automatically.
2. Then remove and re-pair each transmitter once. That single re-pair migrates the pair onto a valid network ID — the core range fix. Until you re-pair, things keep working as they did before.
3. Fresh/blank boards: use the -full.bin image for your board at offset 0x0; the plain .bin is the OTA app image.

Placement tip from this test day: a large metal surface behind the hub (antenna clear of it) acts as a reflector and measurably extends range — my hub lives on an iron gate and that mounting was worth more than any setting.

---

Downloads (every variant for this firmware version)

Transmitter — ESP32-C3 SuperMini

• …-transmitter-lora-esp32c3-<tag>.bin — LoRa SKU (RYLR998 module)
• …-transmitter-lite-espnow-esp32c3-<tag>.bin — Lite SKU (ESP-NOW, built-in radio, no module)

Receiver / Hub

• …-receiver-esp32-<tag>.bin — ESP32 DevKit
• …-receiver-esp32s3-<tag>.bin — ESP32-S3 SuperMini

Each variant ships two images:

• plain .bin — OTA app image, flash at 0x10000, or use the one-click browser flasher / in-app OTA.
• …-full.bin — full-flash image for a fresh/blank board, flash at 0x0 with esptool: esptool.py write_flash 0x0 <file>-full.bin.

TankSync v3.6.2

Receiver (hub) reliability + UX. Transmitter unchanged (version bumped in lockstep).

Fixes

• Data-loss guard (important): the hub could publish an empty tank manifest after a failed storage read (SPIFFS/OOM/corruption at boot), which the cloud honored by deleting all of a user's tanks. The registry now distinguishes "couldn't read" from "genuinely empty" and withholds the manifest when a load fails — so a transient read error can never wipe your tanks. Legitimate empties (first boot, factory reset, removing your last tank) are unaffected.
• OTA ring animation now actually runs. The full-ring update animation was gated on a status flag that was never set, so it had never displayed on any hub. It now shows during updates.

New

• Whole-ring status animations on the LED ring/strip, each a distinct colour: hub update = orange comet, transmitter update = magenta comet, pairing = cyan comet, first-time setup = blue breathing. Normal tank gauges are unchanged.

Also

• Transmitter: sensor +5V power gate is deferred past boot so sensor inrush can no longer brown out the ESP on battery (carried from the prior fix).

---

Downloads (every variant for this firmware version)

Transmitter — ESP32-C3 SuperMini

• …-transmitter-lora-esp32c3-<tag>.bin — LoRa SKU (RYLR998 module)
• …-transmitter-lite-espnow-esp32c3-<tag>.bin — Lite SKU (ESP-NOW, built-in radio, no module)

Receiver / Hub

• …-receiver-esp32-<tag>.bin — ESP32 DevKit
• …-receiver-esp32s3-<tag>.bin — ESP32-S3 SuperMini

Each variant ships two images:

• plain .bin — OTA app image, flash at 0x10000, or use the one-click browser flasher / in-app OTA.
• …-full.bin — full-flash image for a fresh/blank board, flash at 0x0 with esptool: esptool.py write_flash 0x0 <file>-full.bin.

# TankSync v3.6.1 — steadier lights, steadier readings

A hardening release for every hub and sensor I put on the bench this week. No new features — just three classes of "it sometimes misbehaves" hunted down to root cause and fixed for good.

Receiver (hub)

S3 hubs: LED ring/strip moved from RMT to SPI. The ESP32-S3's RMT peripheral has a silicon-level conflict with WiFi softAP cache activity that could crash the hub while it was hosting its setup network — and cause the occasional color glitch during normal use. The WS2812 driver now runs over SPI with DMA on S3 boards: the entire crash class is gone, and dimmed colors no longer shift hue at low brightness. ESP32 DevKit hubs keep their proven RMT path, unchanged.

The setup access point no longer disappears. If your router went down, the hub's fallback setup AP could become invisible or refuse connections — background reconnect attempts were muting the AP's beacons. The hub now probes for your router passively (a scan every 10 minutes) and only leaves setup mode once the router is genuinely back — and it never interrupts you while your phone is connected to the AP.

Round-display hubs: the LED ring now mirrors the screen. The 24-LED ring gauges whichever tank the dial is showing — including through the info screen — instead of splitting into confusing per-tank arcs. The empty portion of the ring stays fully dark. Tank screens rotate every 5 seconds; a tank in alert holds the screen longer.

Transmitter (sensor unit)

JSN-SR04M-2 ultrasonic modules now read reliably. Two real bugs, both found with a live bench rig:

1. This sensor variant misses short trigger pulses — measured 17% response at the old 20 µs pulse vs 100% at longer pulses. The trigger is now 200 µs, which every supported sensor variant accepts.
2. The trigger line floated during early boot while the sensor was already powered, so electrical noise fired the transducer continuously from the moment of wake (the rapid clicking some of you may have heard). The trigger is now pinned low before the sensor receives power.

Validated the boring way: a 43-burst soak with zero errors, 20 consecutive real deep-sleep wake cycles verified clean at the hub, and physical move-tracking accurate to ±1–2 cm.

Coordinator ("HA stick")

The headless Home Assistant coordinator build now compiles out the LED driver entirely — one less peripheral, zero RMT usage on the stick.

Flashing

• Fresh/blank device: use the …-full.bin for your board at offset 0x0.
• Existing devices: update over the air from the hub web UI or the PWA as usual — OTA images are the non-full .bin assets.

---

Downloads (every variant for this firmware version)

Transmitter — ESP32-C3 SuperMini

• …-transmitter-lora-esp32c3-<tag>.bin — LoRa SKU (RYLR998 module)
• …-transmitter-lite-espnow-esp32c3-<tag>.bin — Lite SKU (ESP-NOW, built-in radio, no module)

Receiver / Hub

• …-receiver-esp32-<tag>.bin — ESP32 DevKit
• …-receiver-esp32s3-<tag>.bin — ESP32-S3 SuperMini

Each variant ships two images:

• plain .bin — OTA app image, flash at 0x10000, or use the one-click browser flasher / in-app OTA.
• …-full.bin — full-flash image for a fresh/blank board, flash at 0x0 with esptool: esptool.py write_flash 0x0 <file>-full.bin.

TankSync v3.6.0 — the HA coordinator arrives, plus major hub resilience fixes

New: Home Assistant coordinator firmware ("HA stick")

A new receiver SKU turns the S3 round-display hub board into a headless
Home Assistant coordinator — the Zigbee-stick model for the TankSync sensor
network. Plug it into the Home Assistant machine over its native USB port and
the sensor network appears locally: no WiFi, cloud account, or MQTT broker
required.

• Assets: tanksync-receiver-esp32s3-cam-ha-v3.6.0.bin (OTA) and
  …-full.bin (flash at 0x0). Flashing the -ha image onto an S3 CAM board
  makes it a coordinator; flashing the display image makes it a display hub
  again — same hardware, two products.
• Speaks an open NDJSON serial protocol (see docs/coordinator-serial-protocol.md
  in this repo): node discovery, live telemetry, pairing, rename, calibration,
  and pump control with hub-side safety automation keeping precedence.
• Pairs with SmartGhar Home Assistant integration v0.10.0 ("USB coordinator"
  connection type), verified end-to-end on a live install.
• Coordinator hubs update on their own OTA lane — a coordinator never pulls
  the display image and vice versa.
• The display build is unchanged and keeps its fast internal-RAM rendering.

Receiver (all hubs)

Fixed: hub could boot-loop while the home router was down

If the WiFi router went offline, the fallback path (setup access point +
captive portal) overflowed the system event task's stack, panicked, and
rebooted every ~13 seconds until the router returned. The event task stack is
now sized for the whole fallback chain, an mDNS startup failure degrades
gracefully instead of cascading, and the CAM moves mDNS to PSRAM entirely.

Improved: calm, reliable setup mode

Previously a hub that lost its router alternated its display between the
setup QR and "Connecting…" forever, and joining the setup AP could be
interrupted by background reconnect attempts. Fallback is now a steady state:
the setup AP and QR stay up, the hub quietly retries the saved network every
30 seconds, defers retries entirely while someone is connected to the setup
AP, and tears the AP down cleanly the moment the home network returns.

Improved: internal-memory robustness (the OOM class is closed)

The MQTT client's task memory is reserved at boot and handed over at start
(its startup can no longer lose the RAM race); every runtime task creation is
checked — reboot and factory-reset always execute, a failed OTA start reports
"reboot and retry" instead of silently doing nothing; and the hub now logs an
internal-RAM budget line at boot, warns when the pool runs low, and exposes
heap_internal_free / heap_internal_largest in /api/system for remote
diagnosis.

Transmitter

No functional changes since v3.5.3 (version moves in lockstep with the
combined release).

Assets

Per-variant OTA app images (…-v3.6.0.bin) and full-flash images
(…-v3.6.0-full.bin, flash at 0x0). Full-flash erases WiFi/pairing settings —
use the OTA image to update a provisioned device.

---

Downloads (every variant for this firmware version)

Transmitter — ESP32-C3 SuperMini

• …-transmitter-lora-esp32c3-<tag>.bin — LoRa SKU (RYLR998 module)
• …-transmitter-lite-espnow-esp32c3-<tag>.bin — Lite SKU (ESP-NOW, built-in radio, no module)

Receiver / Hub

• …-receiver-esp32-<tag>.bin — ESP32 DevKit
• …-receiver-esp32s3-<tag>.bin — ESP32-S3 SuperMini

Each variant ships two images:

• plain .bin — OTA app image, flash at 0x10000, or use the one-click browser flasher / in-app OTA.
• …-full.bin — full-flash image for a fresh/blank board, flash at 0x0 with esptool: esptool.py write_flash 0x0 <file>-full.bin.

TankSync v3.5.3 — hub self-provisioning reliability (S3 CAM) + TX battery-sense fix

Receiver (hub)

Fixed: round-display (S3 CAM) hubs could never link to the cloud

A fresh CAM hub added from the app would show as linked in the app but never
start publishing — it silently never fetched its cloud credentials. Root cause
was two back-to-back out-of-memory failures in internal RAM during startup,
both invisible in the logs:

• The cloud-credentials poll task failed to start (its 8 KB stack could not be
  allocated once WiFi + display were up) and the failure was swallowed, so the
  hub never asked the cloud for its broker credentials. The task stack is now
  reserved at link time (static), the create result is checked, and the poll is
  re-kicked on every WiFi connect and every 5 minutes until linked.
• Once credentials did arrive, the MQTT client's own task could fail to start
  the same way, leaving the hub stuck on "connecting" forever. A failed start
  now tears down cleanly and retries automatically.

The CAM build also frees ~12.8 KB of internal RAM (WiFi static TX buffers
16→8) so both tasks have real headroom. Verified on hardware: three
unlink→reboot→fresh-provision cycles, broker-connected within ~10 seconds of
boot each time, plus automatic recovery without a reboot.

Improved: provisioning is now diagnosable from /api/logs

The credentials poll logs its startup (with internal-heap numbers), every
"not claimed yet" poll, and any failure — a hub that won't link now says why.

Transmitter

Fixed: false battery-critical hibernation on mains/bench units

The battery-present threshold rises from 1000 mV to 2000 mV so noise-level
INA219 readings (~36 mV, or spurious ~1 V) on units running without a battery
no longer trigger battery-critical hibernation. Real LiPo packs (3.0-4.2 V)
are unaffected.

App (PWA 1.19.1, deploys separately)

• The "Open hub & connect" one-tap handoff now accepts the hub's IP address
  (shown on the hub's display) — Android phones cannot resolve the
  tanksync-xxxx.local fallback address, which made the button appear to do
  nothing.

Assets

Per-variant OTA app images (…-v3.5.3.bin) and full-flash images
(…-v3.5.3-full.bin, flash at 0x0). Full-flash erases WiFi/pairing settings —
use the OTA image to update a provisioned device.

---

Downloads (every variant for this firmware version)

Transmitter — ESP32-C3 SuperMini

• …-transmitter-lora-esp32c3-<tag>.bin — LoRa SKU (RYLR998 module)
• …-transmitter-lite-espnow-esp32c3-<tag>.bin — Lite SKU (ESP-NOW, built-in radio, no module)

Receiver / Hub

• …-receiver-esp32-<tag>.bin — ESP32 DevKit
• …-receiver-esp32s3-<tag>.bin — ESP32-S3 SuperMini

Each variant ships two images:

• plain .bin — OTA app image, flash at 0x10000, or use the one-click browser flasher / in-app OTA.
• …-full.bin — full-flash image for a fresh/blank board, flash at 0x0 with esptool: esptool.py write_flash 0x0 <file>-full.bin.

TankSync v3.5.2

Two receiver-side fixes on top of v3.5.1. Transmitter and receiver are versioned
together, so both are rebuilt.

What's fixed

• The hub's web server ran out of URI-handler slots (cap 60, but the full API
  surface is 62), so two buzzer endpoints failed to register at boot and buzzer
  web config/test didn't work. Raised the cap to 72 — all endpoints register now,
  with headroom to spare.
• The ESP32-S3 CAM hub now has its own over-the-air update channel. It shares the
  esp32s3 chip target with the S3 SuperMini, so it was asking for the SuperMini
  image on update — which has the wrong pins, PSRAM mode and partitions for the
  CAM. The CAM now pulls its own image (and the SuperMini still pulls its own),
  so each board self-updates to the correct firmware.

Assets — two images per board (OTA app + full-flash), same set as v3.5.1:
receiver-esp32 (DevKit), receiver-esp32s3 (SuperMini), receiver-esp32s3-cam
(round-display CAM), transmitter-lora-esp32c3, transmitter-lite-espnow-esp32c3.

Flashing a blank board:
esptool.py --chip <esp32|esp32s3> -p write_flash 0x0 <...-full.bin>

---

Downloads (every variant for this firmware version)

Transmitter — ESP32-C3 SuperMini

• …-transmitter-lora-esp32c3-<tag>.bin — LoRa SKU (RYLR998 module)
• …-transmitter-lite-espnow-esp32c3-<tag>.bin — Lite SKU (ESP-NOW, built-in radio, no module)

Receiver / Hub

• …-receiver-esp32-<tag>.bin — ESP32 DevKit
• …-receiver-esp32s3-<tag>.bin — ESP32-S3 SuperMini

Each variant ships two images:

• plain .bin — OTA app image, flash at 0x10000, or use the one-click browser flasher / in-app OTA.
• …-full.bin — full-flash image for a fresh/blank board, flash at 0x0 with esptool: esptool.py write_flash 0x0 <file>-full.bin.