Bitaxe – Accidental Factory Reset via Web Interface

Connect your phone or laptop to the Bitaxe SoftAP. After the reset the miner broadcasts a `Bitaxe_xxxx` open WiFi network. Join it, browse to `http://192.168.4.1/`, and the AxeOS captive portal renders. Enter your home WiFi SSID + password, save. The Bitaxe reboots, joins your LAN, and pulls a new DHCP lease — note the IP from your router admin.

Re-enter pool URL, port, and worker. Browse to the new LAN IP, open `Settings → Pool`. Type your pool URL (`public-pool.io`, `solo.ckpool.org`, `pool.ocean.xyz`), the correct port for that pool, and worker — Bitcoin address with a worker suffix like `bc1q...your-address.bitaxe-livingroom`. Save. The stratum client reconnects within 30 seconds and shares should start landing immediately.

Re-enter custom voltage and frequency from your tuning notes or memory. Defaults are conservative; if you previously had a tuned curve, restore it. `Settings → ASIC` → enter Voltage (mV) + Frequency (MHz) for your variant. Apply your known-good values for *this specific chip* — silicon lottery means even two Gamma boards may not run identical curves. Watch `HW%` for 5 minutes after save; if it crosses 1%, drop voltage or frequency and retest.

Re-enter the hostname. `Settings → System → Hostname`. Set to whatever you used previously — `bitaxe-livingroom`, `bitaxe-garage-1`, `bitaxe-PROD-DO-NOT-RESET-pleb-rig`. Useful for DHCP reservation, mDNS resolution, and Home Assistant integration. Save and reboot for the hostname to propagate through DHCP and mDNS.

Re-enter the fallback pool if you used one. `Settings → Pool → Fallback`. If the primary pool fails, this is where the stratum client retries. Common pairing: primary `solo.ckpool.org` (lottery solo), fallback `public-pool.io` (also solo, different operator). Save.

Verify on the pool dashboard. Browse to your pool's stats page (`solo.ckpool.org/users/<address>`, `public-pool.io/app/p/<address>`, `pool.ocean.xyz/stats/<address>`). Confirm the worker is online and shares are landing within 5 minutes. If the worker doesn't appear, you mistyped the address or worker suffix — fix and resave.

Export `settings.json` immediately after recovery. From a terminal: `curl http://<miner-ip>/api/system/info > bitaxe-backup-<hostname>-$(date +%Y%m%d).json`. This snapshots the live config — hostname, ASIC variant, pool URL, port, user, frequency, voltage, fan settings, most of what a future reset will wipe. Save the file to durable storage, not just a Downloads folder. This step is the difference between 'next reset is 90 seconds' and 'next reset is an hour'.

Save the backup somewhere durable. Cloud-sync folder, password manager attachment, encrypted USB, or a private git repo. Don't trust a single laptop's local disk. If you operate multiple Bitaxes, name files `bitaxe-<hostname>-YYYYMMDD.json` and keep one directory per miner. Re-export after every tuning change or firmware update.

Pin a single browser tab. AxeOS isn't designed for multi-tab use across devices. Pick one browser on one machine as your 'miner ops' surface, bookmark the Bitaxe IP there, close every other AxeOS tab. Reduces both freeze risk (websocket pressure on the ESP32) and misclick risk (fewer windows = fewer wrong clicks).

Set a DHCP reservation for the Bitaxe in your router admin. Find the MAC on the OLED at boot or in `/api/system/info`, bind it to a fixed IP. Two-minute setup. After the next reset, the miner gets the same IP back — bookmarks, Home Assistant rest sensors, Prometheus scrapes, and `curl` scripts all keep working without intervention.

Add a procedural confirmation step to your own workflow. Until upstream ships a confirmation modal at issue #1633, *you* are the modal. Whenever you're about to click anything in `Settings`, narrate it: 'I am about to click Save / Restart / Reset'. Sounds silly. Stops the tablet-thumb-misclick scenario cold. Especially important at 2 AM after long debug sessions.

Lock the dashboard to ops-only network reach. AxeOS has no auth — anyone on your LAN can hit the IP and click anything. Move the Bitaxe to a guest-isolated VLAN if your router supports it; at minimum don't share the IP with curious household members. A separate WiFi SSID for miners is a clean solution.

Reflash known-good firmware after recovery if you suspect a firmware bug. Web-flasher at `bitaxeorg.github.io/bitaxe-web-flasher/` requires Chrome / Edge (Web Serial API only on Chromium-family browsers). Pick the correct `.bin` for your chip variant: `BM1366` Ultra, `BM1368` Supra, `BM1370` Gamma & GT, multichip fork at `bitaxeorg/ESP-Miner-multichip` for Hex. USB-C data cable required (charge-only cables won't enumerate). Use 'Erase Flash' between attempts if reflashing twice.

Set a hostname that reflects ops importance. Instead of `bitaxe-livingroom`, use `bitaxe-PROD-DO-NOT-RESET-livingroom` or similar. Every dashboard view reminds you what's at stake. Cheap psychological barrier, real effect on click discipline. Update the DHCP reservation to match.

Run a swarm with explicit peer config in your backup workflow. If you operate a Bitaxe swarm, the peer config is wiped on the affected unit during a reset. Document the swarm peer list in your `settings.json` backup — every miner exports its config, and the directory of `bitaxe-*.json` files is your swarm-recovery doc. After resetting one miner, recover its swarm peer list from the file, not by re-discovering peers manually.

Build a one-line restore script. With a `settings.json` backup, you can `PATCH` most fields back via `curl -X PATCH http://<miner-ip>/api/system -d @bitaxe-backup-<hostname>.json -H 'Content-Type: application/json'`. Note: payload structure depends on firmware version — the GET `info` and PATCH `system` shapes may not match exactly, so VERIFY against current firmware and possibly transform fields. Test on a non-production Bitaxe first.

File or upvote `bitaxeorg/ESP-Miner` issue #1633. The fix is upstream-side: add a confirmation modal between click and execution. Open-source means your voice counts. Add a comment with your specific misclick scenario, +1 the issue, watch the Releases page for the build that ships the modal. When it lands, this entire failure class disappears for the global Bitaxe operator base.

You almost certainly do not need Tier 4 for this error. A factory reset is software-level with no hardware consequence. The only reason to ship a Bitaxe to D-Central after an 'accidental reset' is if the symptom you observed was *not actually* a clean reset — boot loop, OLED hardware errors, reflash failure. In that case the reset was coincidental and the underlying issue is hardware. Ship in anti-static bag, double-box with foam, include a note describing exactly what you clicked and what symptom followed — book at `d-central.tech/services/asic-repair/`.