Problem statement
Design the object model and control APIs for a smart thermostat that regulates one home's heating and cooling from a wall unit, driven by a temperature sensor and a weekly schedule.
Operating context. One thermostat drives one HVAC unit that can heat, cool, or run its fan. A temperature (and optional humidity) sensor reports a reading every few seconds. The user programs a weekly schedule of setpoints (for example, 'weekdays 6am, target 21 degrees') plus temporary 'hold' overrides that expire. The controller compares the latest reading against the active setpoint and decides whether to call for heat, cool, or idle, applying a hysteresis dead-band so the compressor does not short-cycle. A minimum runtime and minimum off-time protect the equipment. Everything runs in-process on the device.
Out of scope. Cloud sync and mobile-app endpoints, the wireless radio and pairing stack, multi-zone whole-house systems, machine-learning 'auto-away' prediction, and the physical relay-driver electronics.
What to produce. The class hierarchy (thermostat, sensor, schedule, setpoint, HVAC actuator, controller), the public API each class exposes, and the state transitions for the HVAC mode. Be explicit about: how the dead-band and min-runtime rules prevent short-cycling, how the control policy is pluggable (swap simple hysteresis for a PID-style strategy) without touching the schedule code, and how a temporary hold coexists with the recurring schedule.
Must do 5
Functional requirements
- Resolve the active setpoint from the weekly schedule, or from an unexpired temporary hold when one is set, for the current time.
- Decide the HVAC action (heat, cool, or idle) by comparing the latest sensor reading against the active setpoint within a hysteresis dead-band.
- Enforce equipment protection by honouring a minimum runtime and a minimum off-time before switching the HVAC mode.
- Let the user program, edit, and query weekly schedule entries and place or clear a temporary hold.