The short version: stop tuning your miner to a fixed hashrate and start tuning it to a number of watts — then wire that watt-budget to your battery’s state of charge (SoC). When the battery is full and the sun is up, mine the surplus; as SoC drops, dial the watt-target down; near empty, curtail to idle and wake back up in seconds when the charge recovers. This is the operating layer that sits on top of all the solar-sizing and economics math you’ve already done.
Most off-grid mining writeups stop at the shopping list: panels, an inverter, a battery bank, a charge controller. That’s the hardware. What almost nobody writes down is the control loop — the moment-to-moment logic that decides how hard the miner runs based on how much energy you can actually spare right now. That’s the gap this guide fills. If you still need to size the array itself, start with our off-grid solar sizing calculator and the broader economics in our look at battery storage and Bitcoin. This post assumes the panels are on the roof and asks: now what makes the miner behave?
The conceptual flip: target watts, not hashrate
An ASIC miner left to its own devices wants to run flat-out at a fixed clock, drawing whatever wattage that demands. On the grid that’s fine. On a battery, it’s a recipe for a dead bank by sunset.
The better mental model — and the one that makes everything downstream possible — is watt-anchored targeting. Instead of telling the miner “produce X terahash,” you tell it “draw no more than Y watts, and extract the most hashrate you can inside that budget.” This is a real, documented capability of modern autotuning firmware: a tuner’s target can be configured as hashrate, watts, or efficiency in joules per terahash. Under a watt target, the tuner redistributes frequency across the chips to maximize hashrate within the power budget, throttling the worst-performing (highest J/TH) chips first.
Why does this matter for solar? Because your available power is a moving number. A cloud passes, a watt-budget loop adjusts; the sun comes back, it climbs again. A hashrate-anchored miner can’t track that — it knows one speed. A watt-anchored miner follows the surplus.
How a miner actually “follows” a number
The mechanism underneath is a control loop. In a watt-targeting design, a PID-style controller samples measured power every few seconds, computes the error between the target watts and the measured watts, and converts that error into a small frequency adjustment, redistributed across the chips by their silicon-quality score. That’s what lets a miner chase a surplus figure smoothly rather than slamming between on and off.
One accuracy note worth burning into memory: on a multi-chip ASIC, voltage optimization is per-domain, not per-chip. Roughly ten chips share a single DC-DC converter, and that group is one “voltage domain.” An S19 XP hashboard, for instance, groups its 110 chips into eleven voltage domains of ten chips each — the tuner sets voltage at that domain granularity while still nudging each chip’s frequency individually. Anyone who tells you a miner does true “per-chip voltage control” is mistaken; the rail simply isn’t wired that way.
The data path: inverter → automation → miner
State-of-charge-driven mining is three boxes connected by a wire (usually a network cable):
- The inverter / battery system reports SoC. The Victron Energy ecosystem is the common reference here — a Cerbo GX running Venus OS, with the VRM portal — and it exposes battery SoC over standard surfaces like Modbus-TCP, MQTT, and Node-RED. Plenty of other hybrid-inverter platforms expose the same telemetry; the point is that SoC is a readable number, not a guess. Credit where it’s due: the inverter ecosystem did the hard work of making that data accessible.
- An automation brain reads SoC and decides. Home Assistant is the usual choice — it ingests the SoC sensor and runs automations against thresholds. This is the layer where your policy lives.
- The miner accepts a watt-target command. The automation sends a new power-target to the miner’s API, and the autotuner does the rest.
None of these three pieces is exotic, and importantly, D-Central didn’t invent any of them. We’re standing on the shoulders of the Victron and hybrid-inverter communities, the Home Assistant project, and the open-source mining-control work below.
An illustrative SoC-threshold ladder
Here’s the heart of it: a ladder that maps battery SoC bands to miner behavior. Every number here is an illustrative estimate — your bank chemistry, depth-of-discharge tolerance, loads, and climate will move these. Treat it as a shape to copy, not a spec to obey.
- Above ~85% SoC (battery full, surplus available): set the watt-target to your full available surplus. You’re soaking up energy that would otherwise be clipped.
- ~50–85% SoC (comfortable, but watch it): modulate the watt-target downward as SoC falls, letting the PID loop walk the miner’s draw down to match. The miner keeps hashing, just leaner.
- Below ~40% SoC (protect the bank): curtail to idle. Hashboards de-energize; the control board stays alive and listening.
- On the way back up: as SoC climbs back through your bands, step the watt-target up again. Because the miner is recovering to a previously used target, it can resume fast (more on that next).
Adding hysteresis — say, requiring SoC to climb a few points above a threshold before stepping back up — keeps the miner from flapping on and off around a boundary. That’s a detail the hardware will thank you for.
Why curtailing is cheap, and waking is fast
Two things make this practical. First, curtailing a miner to idle is a designed operation, not abuse of the hardware. Fleet-control tooling exposes explicit curtail and un-curtail commands for exactly this purpose, and curtailment-capable firmware can drop and restore power through a single API call — some implementations in well under five seconds. You’re not “damaging” anything by parking the machine when the bank runs low.
Second, coming back online is quick when you return to a known target. Autotuning profiles can be cached and indexed by power target, so requesting a target you’ve used before reloads near-instantly instead of re-converging from scratch. A small low-power miner can ramp its frequency back up in roughly seven seconds (an estimate from open ESP-Miner behavior on Bitaxe-class hardware). The honest caveat: a first-ever tune from a cold start is a different animal — full convergence can take on the order of ten to fifteen minutes. So “sub-minute wake” describes resuming a cached watt-target, not discovering one for the first time. Don’t conflate the two.
As a rough estimate for a full ASIC running this way, expect the idle floor to sit in the tens of watts — the control board and networking stay powered while the hashboards rest. The DCENT_OS “solar-aware” example targets a behavior in the neighborhood of ~25 W idle with a sub-minute wake back to a cached target. That ~25 W figure is an estimate, not a Bible-measured full-ASIC number — your mileage will vary by model.
Curtailment as a proven concept
SoC-driven throttling is one instance of a more general idea: programmatic curtailment of mining load. You don’t have to take our word that it’s sound — it already exists in the open. Block’s open-source proto-fleet project (alongside the 256 Foundation‘s Apache-2.0 asic-rs control work) defines a CurtailmentService with explicit modes — among them a fixed-kilowatt cap, a fixed device count, a demand-response trigger, a site power cap, and a thermal limit — with a clean lifecycle: preview the impact, start, staggered restore, stop, and a maximum-duration safeguard.
Two of those modes map almost perfectly onto solar work. A site power cap is exactly “hold the fleet under the surplus I have right now.” A price-breakeven mode (mine only above your breakeven) is in the same family — though in proto-fleet that one is currently reserved and not shipped, so treat it as a concept, not a feature you can flip on today. The staggered-restore detail matters too: bringing machines back gradually avoids slamming your inverter with a wall of inrush.
We’re describing this as the proven concept it is. D-Central didn’t build proto-fleet or asic-rs; the credit belongs to Block and the 256 Foundation (asic-rs is the work of Brett Rowan and contributors), and the broader open-source curtailment community.
Where DCENT_OS fits — one open example
Our own DCENT_OS includes a solar-aware behavior that implements this loop: read an SoC signal, hold a watt-target, curtail to a low idle on low charge, and resume from a cached target on recovery. It’s a source-available project (GPL-3.0, public on GitHub) and still in beta, with public beta planned for summer 2026. We mention it as one open example in a credited ecosystem — not as the answer, and with no promise it’ll do more than it does. The same control loop is achievable today with a watt-targeting firmware, an inverter that publishes SoC, and Home Assistant gluing them together.
If you’d rather run lean and learn the loop on cheap hardware first, an open-source low-power miner is a great teacher — the Bitaxe, created by Skot (Skot9000) and developed in the open by the Open Source Miners United community, ramps and curtails fast enough that you can watch the whole control loop breathe in real time.
Beyond solar: the same loop pays off twice
The watt-anchored control loop you build for SoC is the same machinery you’d use for two other revenue and efficiency angles. If your utility runs paid curtailment events, the demand-response trigger is the identical pattern pointed at a grid signal instead of a battery — see our guide to demand response and curtailment programs for miners. And because a curtailed-to-idle miner stops producing heat, anyone using their miner for space or water heating needs to think about how throttling interacts with their thermal load — our heat-reuse compatibility matrix is the place to reconcile “mine on surplus” with “keep the room warm.” For the storage side of the equation, our primer on integrating battery systems with home mining and the green approach to solar-powered home mining round out the picture.
The takeaway
Off-grid mining isn’t really a hardware problem once the panels are up — it’s a control problem. The unlock is one mental flip: target watts, tie that number to your battery’s state of charge, and let an autotuner and a few automations do the rest. Read SoC from the inverter, decide policy in Home Assistant, push a watt-target to the miner, and let it follow your surplus up and down — curtailing cheaply when the bank runs low and waking in seconds when the sun returns. The pieces are open, proven, and creditable to the communities that built them. Your job is to wire them into a loop that respects your battery.
All wattage, SoC percentage, timing, and kWh figures in this guide are illustrative estimates. Size your own thresholds against your battery chemistry, depth-of-discharge limits, and local conditions before relying on them.
