Bitaxe – AxeOS Web UI Freezes During Mining Session

Close every extra AxeOS tab across every laptop, phone, tablet, and 'I forgot it was open' browser window. The ESP32-S3's HTTP server pool is small (default 7 sockets); every open tab eats sockets and websocket budget. Keep one tab when you need it; close it when you don't. This single discipline change is the highest-leverage move on this page and cuts freeze frequency by an order of magnitude.

Hard-refresh the surviving tab with `Ctrl`+`Shift`+`R` on Windows/Linux or `Cmd`+`Shift`+`R` on macOS. Forces the browser to drop any stale websocket reference and any cached `app.js` chunks. Wait 30 seconds for telemetry to repopulate before clicking anywhere — the first reconnect on a starved task is the slowest one to come back online.

Power-cycle the Bitaxe for 30 full seconds at the barrel / XT30. Not 5 seconds, not a soft reboot from the (now-frozen) UI. Pull the connector, wait 30 seconds for the capacitors to drain and the ESP32 state to fully clear, then plug back in. Lets the heap defrag and clears any wedged HTTP / websocket task. Wait for OLED hashing to stabilize, then reopen AxeOS.

Use a single browser, one window, one tab. Pick a primary 'miner ops' browser — Firefox or Chrome — and bookmark the AxeOS URL there. Every time you need to tune, open that one tab. Close it when you're done. Treat AxeOS like a CLI session, not a dashboard you leave running. Multi-tab is the dominant cause of this entire failure class.

On phones, use the mobile viewport rather than 'request desktop site.' AxeOS has a responsive layout designed to reduce per-frame work; forcing desktop on a small screen amplifies renderer back-pressure and contributes to the freeze pattern on certain firmware builds. The mobile layout is purpose-built and cheaper for the ESP32 to keep alive.

Switch from the websocket dashboard to REST polling for long-term monitoring. `curl http://<miner-ip>/api/system/info` returns the same JSON the websocket streams — hashrate, temp, voltage, power, pool, worker. Schedule it once a minute from a single source: shell + cron, Home Assistant `rest` sensor, Prometheus scrape, Telegram bot. One poller, one miner, once a minute is light. Multiple browser tabs streaming websockets is heavy.

Pin a DHCP reservation for the Bitaxe in your router admin. Find the MAC on the OLED or in the DHCP table and bind it to a fixed IP. Stops the 'IP changed and now my poller is hitting a different device' failure that masquerades as a freeze. Two-minute setup, permanent payoff. Do it for every Bitaxe on your network.

Update firmware to current stable. Open the AxeOS dashboard, go to `Settings → System`, note the firmware version. Cross-check against `https://github.com/bitaxeorg/ESP-Miner/releases`. If you are more than one stable version behind, OTA-update from the dashboard (over strong WiFi, not weak) or flash via the USB-C web-flasher. Many freeze regressions documented in #199 / #1279 were addressed in newer builds.

Move the Bitaxe to a dedicated 2.4 GHz SSID with strong signal. The ESP32-S3 is 2.4 GHz only. Band-steered SSIDs push it to weak edge cells. Weak WiFi → packet loss → websocket retransmits → socket churn → freeze. A clean, dedicated 2.4 GHz SSID is one of the best things you can do for long-term Bitaxe stability across the whole ecosystem of issues, not just this one.

Throttle external pollers. If you run Home Assistant, Grafana, or a custom monitor, drop polling to once every 60 seconds (not once per second). The Bitaxe doesn't change state in interesting ways at one-second resolution; you're burning HTTP server cycles for a chart that updates more often than human eyes can notice.

Capture a serial log during the freeze. USB-C data cable, terminal at `115200` baud. Reproduce the freeze with the terminal open and capturing. When the dashboard wedges, search the rolling log for `httpd`, `Task watchdog`, `tcp_input`, `Out of sockets`, `mem_malloc`. Save the 60 seconds before and after the freeze. This is what you send to D-Central support or paste into a GitHub issue if you escalate.

Force a watchdog reset to clear the wedge remotely. If you can `curl` the API but the websocket is dead and you cannot reach the miner physically, hit `POST http://<miner-ip>/api/system/restart` from `curl`. Forces a clean ESP32 reboot — heap reset, sockets reset, freeze cleared, mining resumes within ~15 seconds. Faster than walking to the closet, when the closet is in another building.

Pin to a known-good firmware version if a specific release works for you and the next one introduces freezes. The Releases page keeps every signed `.bin`. Re-flash the previous stable via the USB-C web-flasher with the correct chip variant: `BM1366` = Ultra, `BM1368` = Supra, `BM1370` = Gamma & GT, `BM1397` = Max; Hex uses the multichip fork at `github.com/bitaxeorg/ESP-Miner-multichip`.

Erase NVS + reflash if freezes survive a clean firmware update. Web-flasher → 'Erase Flash' → reflash → reconfigure WiFi + pool from the `Bitaxe_xxxx` AP at `http://192.168.4.1/`. A corrupted `nvs` partition can carry stale settings forward across OTA flashes; full erase + reflash is the only way to know you're on a clean slate.

File a GitHub issue with serial log + version + reproduction steps if you've isolated a reproducible freeze. The Bitaxe project lives on community feedback — open an issue at `bitaxeorg/ESP-Miner/issues` with: variant, firmware version, exact reproduction (number of tabs, polling rate, uptime to freeze), and the serial log around the event. Maintainers triage these quickly.

Schedule a weekly cold-boot. Once a week, 30-second power-off, plug back in. Half a minute of downtime, fully refreshed heap, zero freezes for the next week. Cron the reminder if your memory is bad — your sats won't notice the 30 seconds, but the ESP32 heap definitely will.

Stop DIY when you have reflashed the correct `.bin` twice with `Erase Flash` between flashes and freezes still recur within an hour, the serial log shows hardware-level errors (`Flash read err`, brownout traps) rather than HTTP-task watchdog hits, or the ESP32 fails to enumerate over USB-C with BOOT held. Book D-Central Bitaxe Repair — bench-level diagnostics on the ESP32-S3, JTAG recovery, module replacement if silicon failure.

Ship to D-Central safely if escalating: anti-static bag, double-box with 3 cm+ foam every side. Include a note with: Bitaxe variant, firmware version where freezes started, your reproduction steps (tab count, polling rate, uptime to freeze), and a serial log excerpt if you have one. D-Central will JTAG-test the ESP32-S3, reflash via external USB-to-UART if the onboard USB is dead, replace the module if needed, and burn-in for 24 hours before return.