Heat management: drive mining toward a target room temperature (climate domain)

[markoceri]

Introduction

This work stems from a talk given at the Bitcare Forum 2026, where we explored at length how the heat produced by Bitcoin mining can be put to good use. The idea: treat heat not as a by-product of mining but as the primary asset, with the explicit goal of heating a room.

Edge Mining already decides when to mine based on energy availability, forecasts and user policies. This PR makes the system aware of the thermal state of the environment, so it can deliberately run miners to keep a space at a desired temperature, using the waste heat of the ASICs.

Closes #44.

How it was implemented

A new Climate domain modelling heat management around three concepts:

• Climate Zone — a room/area to keep warm: area, an associated temperature sensor, a target temperature (with an optional daily schedule and a default fallback) and a hysteresis band to avoid on/off flapping around the setpoint.
• Climate Monitor — an adapter that reads the current temperature/humidity of a zone. Two adapters: Home Assistant API (real source) and Dummy (testing).
• Thermal awareness in optimization — climate zones can be attached to an optimization unit. On every run the OptimizationService builds a ClimateStateSnapshot for the unit's zones, injecting the resolved target temperature/hysteresis into each reading, and exposes it to the rule engine via DecisionalContext.climate (graceful degradation if a monitor is unavailable).

Supporting changes:

• Domain (core/edge_mining/domain/climate/): ClimateZone / ClimateMonitor entities, TemperatureSlot / ClimateZoneReading / ClimateStateSnapshot value objects (cross-midnight aware schedule, min/max/avg aggregates, name-indexed zones map), ports, events and exceptions.
• Adapters: FastAPI router + Pydantic schemas, SQLAlchemy tables/repositories, Alembic migrations (add_climate_tables, add_temperature_schedule).
• Rule engine value_ref: conditions can compare a field against another field (e.g. temperature_celsius vs. target_temperature), enabling target-driven heating rules.
• Example policy: Solar Surplus Room Heating — heats the room with miner waste heat when solar/battery surplus is available and the zone is below target.
• Frontend: climate zones/monitors settings views and forms (incl. temperature schedule editor), a Climate Dashboard view and zone card, plus climate zone selection in the Optimization Unit form.

Test plan

• Unit tests for climate entities, value objects, repositories, temperature scheduling and value_ref resolution.
• Climate state snapshot integration into the optimization run.
• Manual check: configure a Home Assistant climate monitor, define a zone with a schedule, attach it to an optimization unit and verify the heating policy starts/stops mining around the target temperature.