Bitcoin Mining Automation: The Home Miner's Hands-Off, Sovereign Stack

The five layers of mining automation

1. Monitoring & dashboards — know hashrate, temps, power, and pool status at a glance, and log it.
2. Firmware-level control & autotuning — let the miner find its own efficient operating point.
3. Energy scheduling — mine hard when power is cheap or abundant, throttle or pause when it isn’t.
4. Thermal, fan & noise automation — hold temperature and noise targets without manual fan tweaking.
5. Alerting & self-healing — get notified and auto-recover before a dead miner costs you a week of uptime.

Layer 1 — Monitoring & dashboards

You cannot automate what you cannot measure. The first layer turns every miner into a stream of telemetry — hashrate, accepted/rejected shares, chip temperatures, fan RPM, wall power, and pool connection state — and puts it where automations can act on it.

• DCENT Toolbox — D-Central’s own open-source miner management tooling. Self-hosted, no account, no cloud dependency — the sovereign default for managing a mixed fleet.
• Home Assistant integration — pull miner metrics into a self-hosted automation engine you already trust for the rest of your home.
• awesome-miner / Foreman-style fleet managers — useful at scale, but weigh any cloud component against the sovereignty cost; prefer the self-hosted path.

Log the data to a local time-series store (Prometheus, InfluxDB) and the rest of this guide becomes possible. Telemetry that lives only on a vendor’s server is telemetry you don’t own.

Layer 2 — Firmware-level control & autotuning

The biggest efficiency gains are automated at the firmware layer, not in a spreadsheet. Modern mining firmware will hold a target efficiency (J/TH) and tune per-board voltage and frequency continuously as silicon and ambient conditions drift.

• DCENT_OS — D-Central’s GPL-3.0-target Antminer firmware in honest public beta (its own page states plainly it can brick hardware). Autotuning, Basic Heat Mode thermal control, and Stratum V2 are on the beta track; the design target is 0% mandatory dev fee by default. Automation that doesn’t quietly tax your hashrate.
• AxeOS — the open Bitaxe firmware, scriptable over its HTTP API for per-chip frequency automation.
• Braiins OS+ — autotuning Antminer firmware with open-source roots.

Choosing between them is its own decision — see the full mining firmware comparison. The automation principle holds regardless: set an efficiency target, expose an API, and let the firmware do the minute-by-minute work.

Layer 3 — Energy & time-of-use scheduling

For most home miners the single highest-ROI automation is making the rig power-aware. On a time-of-use tariff — common across Canadian provinces — automatically dropping to low-power mode or pausing during peak-price windows can swing a marginal setup into profit. The same logic runs solar/battery rigs: mine the surplus, back off when the battery is feeding the house.

Drive it from your monitoring layer: a Home Assistant automation or a cron job that reads the tariff schedule (or a real-time price/solar signal) and calls the miner’s firmware API to switch power profiles. We cover the strategy in depth in Time-of-Use Bitcoin Mining.

Layer 4 — Thermal, fan & noise automation

Manual fan settings are a compromise between noise and safety that is wrong most of the time. Automate it instead: a PID loop (Basic Heat Mode in DCENT_OS, beta track) holds a target chip temperature with the minimum fan speed required, and a scheduled “quiet hours” profile caps RPM overnight while widening the thermal band. The result is a rig that is as quiet as physics allows whenever it can be, and only loud when it must be.

Pair temperature automation with sound design — ducting, intake/exhaust balance, and placement — covered in the Mining Ventilation Guide and the ASIC Noise Reduction Guide. Automation and acoustics compound.

Layer 5 — Alerting & self-healing

Unattended uptime is the whole point. The final layer watches the telemetry and acts before you lose days of hashrate:

• Alerts — hashrate drop, board offline, over-temp, or pool disconnect pushed to a self-hosted webhook, Telegram, or Discord. No third party between you and your own rig.
• Watchdogs — auto-reboot a hung miner, fail over to a backup pool, or cut power on a thermal runaway via a smart plug your automation engine controls.
• Reachability — manage it over your own VPN or Tailscale, not a vendor cloud portal. Remote control without remote dependence.

What this looks like in practice

A worked time-of-use example. On a typical Canadian time-of-use tariff the peak-to-off-peak spread is often roughly 2–3×: off-peak power frequently sits in the single-digit cents-per-kWh range while on-peak is materially higher, with the expensive window usually a 4–6 hour weekday block. Mining revenue per kWh is roughly constant; your cost per kWh is not. An automation that drops a ~3 kW rig to low-power mode or pauses it during only that peak window strips out your most expensive kilowatt-hours first — frequently the difference between a setup that loses money and one that clears profit, with zero hardware spend. Run it against your own rate card in the profitability calculator.

A concrete Home Assistant pattern. The shape is identical whatever tool you use: a trigger — a time-of-use price sensor crossing a threshold, a solar-surplus sensor, or a plain input_datetime schedule — fires an action that calls the miner’s firmware API to switch power profile. In Home Assistant that is a rest_command aimed at the firmware’s local API endpoint, invoked by an automation whose trigger is your electricity-rate helper. The rate signal, the decision logic, and the API call all run on hardware you own — no vendor portal sits in the loop, so no vendor outage or account action can take your scheduling offline.

Tune to an efficiency target, not a clock. When you hand autotuning firmware a J/TH (joules-per-terahash) goal instead of a fixed frequency, it continuously finds the voltage/frequency point that holds that efficiency as silicon ages and ambient temperature drifts. Production SHA-256 ASICs run roughly from the high-teens to the mid-30s J/TH depending on generation and how hard they are pushed; for a home rig paying residential power, automating toward the efficient end of your hardware’s range — rather than maximum hashrate — is almost always the right policy. Set the target once; let the firmware defend it.

The sovereign automation stack

Put together, the Mining Hacker stack looks like this: open firmware (DCENT_OS / AxeOS) exposing an API, scraped into a self-hosted time-series database, visualized and acted on by a self-hosted automation engine (Home Assistant or DCENT Toolbox), reachable over your own VPN, alerting to a channel you control. Every layer is open-source and runs on hardware you own. No cloud account is a single point of failure, a data leak, or a kill switch. That is the difference between automating your mining and renting someone else’s automation.

Frequently asked questions