Keep four values separate

Keep four values separate: reference table
ValueMeaningCommon mistake
Actual RPMThe latest readable physical fan speedTreating one sample as instantaneous proof of a fault
Target RPMThe speed currently requested by the active controllerAssuming the fan has already reached it
MinimumThe firmware-reported lower bound for that fanAssuming every Mac can intentionally stop its fans
MaximumThe firmware-reported upper bound for that fanCopying another model's RPM as a universal maximum

Why actual RPM may differ from target

A fan has inertia and takes time to accelerate or settle. Polling also samples a continuous physical process at intervals. During a transition, Actual can reasonably trail Target. Firmware can additionally choose a safer, higher response than a requested lower target.

  • Compare a short series of fresh samples, not one frame.
  • Confirm which controller owns the fan while comparing values.
  • Use each fan's own bounds; multi-fan Macs can expose different readings.
  • Investigate a persistent substantial miss, not normal settling noise.

How a fan-curve percentage becomes RPM

A curve point expressed as a percentage should map into the discovered range between that fan's firmware minimum and maximum; it is not a percentage of zero. This lets one response shape scale across the individual fans in an already qualified topology without inventing fixed RPM numbers.

NoteOne percent does not equal one acoustic step

Perceived noise, airflow, and cooling do not rise linearly with the displayed percentage. Tune from measured workload behavior and your noise preference rather than assuming a geometric curve is physically universal.

Zero, missing, and unavailable mean different things

Zero, missing, and unavailable mean different things: reference table
Display stateInterpretationSafe response
Fanless modelNo built-in fan exists to measure or controlShow monitoring only; never create a synthetic fan row
Fan present, valid 0 RPMPossible only where that exact hardware and state support itInterpret against firmware bounds and controller state
Fan count unavailableThe app did not establish topologyFail closed; do not assume a count or target
Stale readbackThe sample cannot prove current behaviorReturn to or verify System before another write

What a useful RPM investigation looks like

  1. Record exact model, fan count, each fan's reported range, and current controller.
  2. Reproduce a stable workload and watch actual RPM over time.
  3. On qualified hardware only, use a bounded timed target and allow it to settle.
  4. Return to System and verify ownership from fresh readback.
  5. Report persistent non-response, irregular noise, or failed handoff with diagnostics.

WarningDo not try to force fan control where it is unavailable

If Smart Breeze keeps your Mac in System, that is an intentional safety boundary, not an RPM troubleshooting step to bypass. Control appears only where a complete fan topology was discovered.

How Smart Breeze presents RPM honestly

Smart Breeze's fan rows separate Actual, Target, and Control. Targets are clamped to firmware-reported bounds and written targets are read back. A failed write requests an all-fan rollback; an interrupted helper path places macOS in control while Smart Breeze verifies fresh state.

That distinction is deliberate: a requested number is not proof of physical behavior, and a System button is not proof of ownership until the hardware state verifies it.

Sources

Related docs: Understand verified writes and rollback, Troubleshoot Actual versus Target

Smart Breeze separates the live speed, requested target, firmware bounds, and verified controller for every discovered fan. Download Smart Breeze