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.
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.
- Expose current status: current mode, latest reading, active setpoint, and time remaining on any active hold.
Non-functional requirements
- A single sensor update resolves the control decision in O(1); schedule lookup is at most O(log N) in the number of entries.
- The control policy is pluggable so swapping hysteresis for a PID strategy does not touch schedule or actuator code.
- The HVAC state machine is thread-safe: concurrent sensor updates and user edits never leave the actuator in an illegal mode.
- The design is unit-testable without real hardware or wall-clock time, with sensor, clock, and actuator injected.
- Adding a new mode such as emergency-heat, or a humidity-driven rule, is a localised change behind the existing interfaces.
Topics
- System Design LLD
- Oop Solid
- Patterns Strategy
- Patterns State-Machine
- Iot Control-Loop