Summary

Today Edge Mining treats heat as a by-product of mining: the system decides when to mine based on energy availability, forecasts and user policies, while the thermal energy released by the ASICs is simply dissipated. There is a growing class of use cases where heat is the primary objective and electricity production (or surplus consumption) is the means: heating a room, a workshop, a greenhouse or a water tank by deliberately running miners.

To support these scenarios we need a first-class way to manage heat as an asset, organised around the physical spaces we want to keep warm and driven by a desired temperature.

Motivation

• A miner is, thermodynamically, a ~100% efficient electric heater that also produces sats. When the goal is warming a space, running it is not "wasted" energy.
• Users want to define which space they care about (a room/zone), monitor its actual temperature, and have the optimization engine keep that space at a target temperature, mining when it makes sense (e.g. solar surplus available and room below target) and stopping once the target is reached.
• This requires the optimizer to be aware of the thermal state of the environment, which it currently is not.

What is missing today

1. No concept of a climate zone (a room/area to be heated) in the domain.
2. No way to read the current temperature of a zone from a real sensor (e.g. via Home Assistant) or a dummy source for testing.
3. No notion of a target temperature per zone, nor scheduling it over the day (e.g. warmer in the morning/evening, cooler at night).
4. No hysteresis handling, so naive on/off rules would cause the miner to flap around the setpoint.
5. The decision engine (policies/rules) has no access to the thermal context, so users cannot express rules such as "start mining when the room is below target and there is solar surplus, stop when the target is reached".

Proposed scope

Introduce heat management as a new capability, centred on three concepts:

• Climate Zone — a room/area to be kept warm, with an area, an associated temperature sensor, a target temperature (with an optional daily schedule) and a hysteresis band.
• Climate Monitor — an adapter that provides the current temperature/humidity reading of a zone (real source such as Home Assistant, plus a dummy for testing).
• Thermal awareness in optimization — expose the per-zone readings and the resolved target temperature to the decisional context so that policies/rules can compare current vs. target temperature and drive mining accordingly.

Acceptance criteria

• A user can define one or more climate zones and assign a temperature sensor to each.
• A zone exposes its current temperature and a target temperature, where the target can vary over the day via a schedule, falling back to a default.
• A hysteresis band prevents rapid on/off cycling around the target.
• Climate zones can be attached to an optimization unit so that their state is collected on every optimization run.
• Policies/rules can reference the thermal state (current temperature, target temperature per zone) to start/stop mining, including comparing a field against another field (e.g. temperature < target_temperature).
• The current thermal state of each zone is visible in the UI (monitoring/dashboard).
• Graceful degradation: if a sensor/monitor is unavailable, the optimization run continues without crashing and the thermal conditions simply do not trigger.

Out of scope (for now)

• Direct actuation of valves/relays for hydronic heating; here we drive mining, not external heating actuators.
• Multi-target optimization trade-offs (e.g. balancing payout vs. comfort) beyond what user-defined rules already express.