The core of a refrigeration controller is not the rule “turn on the compressor when temperature is high.” It is a priority-ordered state machine with explicit interlocks and recovery paths. A practical base order is: sensor and safety faults override defrost; defrost overrides drain and post-defrost recovery; normal cooling is evaluated only after those states have cleared. The compressor, evaporator fan, and electric heater each need their own permit conditions.
This order makes behavior explainable. If door handling, compressor delays, defrost, and sensor errors live in independent callbacks, contradictory commands become possible. A heater may be active while a rising cabinet temperature requests cooling. A fan may restart while the evaporator is still warm and wet. A failed probe may leave the system acting on its last plausible value. A state machine turns these risks into invariants that can be tested at exact time boundaries.
1. Define output permits before temperature rules
A representative electric-defrost cabinet has a cabinet-temperature probe, an evaporator probe, and a door input. Its outputs include the compressor, evaporator fan, defrost heater, and alarm. A more capable controller may also operate lighting, a condenser fan, a solenoid valve, or energy metering. The current ZedIoT refrigeration-controller product material describes up to three inputs, five relay outputs, configurable hysteresis, compressor delay, timed defrost, and remote connectivity. That establishes a credible I/O surface, but it does not make one parameter set valid for every refrigeration system.
Start implementation with permits. A compressor permit should require valid critical sensors, no active electric-defrost or drain state, expiration of the minimum-off timer, and absence of a protection fault that locks cooling. A heater permit should require the explicit defrost state, a compressor inhibit, an evaporator temperature below the termination threshold, and a defrost elapsed time below the maximum. A fan permit should distinguish ordinary cooling from recovery: during normal cooling it may follow the compressor and door policy; after defrost it should wait for both a time delay and an evaporator-temperature condition.
The controller should retain the reason for every denied or granted permit. A remote operator who sees fan=false needs to know whether the cause was an open door, active defrost, a warm evaporator, a pending delay, a disabled output, or a fault. Exposing a reason such as minimum_off_hold or post_defrost_fan_hold is useful to unit tests, service tools, and fleet operations. A relay bit alone is not an adequate control explanation.
2. Use priority to prevent competing timers
A compact state set can include FAULT, DEFROST, DRAIN, RECOVERY, COOLING, and IDLE. The names are less important than the precedence. On every sample or timer event, validate sensors and hard faults first. Then continue any active defrost, drain, or recovery sequence. Only after the higher-priority sequence is complete should the controller calculate ordinary cooling demand.
Each state must also own its exit conditions. A rising cabinet temperature cannot end DEFROST; only the evaporator termination temperature, maximum duration, manual cancellation, or a safety fault can do so. Likewise, expiration of the heater timer should not jump directly to cooling. The system must pass through drain and recovery. Centralizing exits prevents a low-priority temperature event from bypassing a protection sequence.
This model also gives remote commands a safe role. A cloud service can request a setpoint, cooling demand, or maintenance action, but the embedded controller makes the final permit decision. “Force compressor on” should never mean “ignore minimum-off time, sensor validity, and defrost interlocks.” If a service function truly bypasses a protection, it should be a physically controlled maintenance mode with explicit time limits and audit evidence, not an ordinary API flag.
3. Combine hysteresis with compressor time protection
With a -18°C setpoint and a 2 K differential, cooling demand can latch on when cabinet temperature reaches -16°C and clear when it falls to -18°C. Between those values, the previous demand remains. This memory is hysteresis. It prevents sensor resolution, noise, and local airflow from toggling a relay whenever the measurement crosses one exact number.
Hysteresis is not an anti-short-cycle timer. After the compressor stops, a warm measurement may request cooling, but the output still waits for the minimum-off interval. After start, a minimum-on interval may keep the compressor running briefly even when temperature reaches the stop threshold. Copeland application guidance associates excessive short cycling with lubrication, oil return, motor, and contactor concerns. The specific limits must come from the compressor and refrigeration-system design; the 180-second minimum-off and 120-second minimum-on values in this article are only deterministic test inputs.
Power restoration needs the same discipline. Unless the controller can prove how long the compressor has been off, a conservative implementation starts a complete minimum-off delay. A site with many cabinets can also apply bounded start staggering to reduce coincident inrush. Persist only the state needed to restore safely: blindly restoring a pre-power-loss relay command can restart into a different thermal and fault condition.
Timekeeping details matter. Use a monotonic timer for operational intervals, not wall-clock time that can jump during synchronization. Define whether a setting change restarts or preserves a pending delay. Test one second before, at, and one second after each boundary. Most timing defects are not visible in a long steady-state run; they appear at equality comparisons, reboots, and transitions between counters.
4. Treat the evaporator fan as a controlled output
During ordinary refrigeration, the evaporator fan often follows the compressor, but door behavior, continuous-circulation requirements, and condensation targets can change that relationship. Stopping the fan on a door-open input can reduce cold-air loss and humid-air ingestion. Some display cases, however, use a different circulation policy. The implementation requirement is not one universal door delay; it is an explicit rule that combines current mode, door state, configured delay, and an observable decision reason.
Post-defrost fan behavior has a separate purpose. Electric defrost leaves the evaporator and drain area warm and wet. Restarting the fan immediately can move heat and moisture back into the cabinet, producing a temperature excursion, condensation, or rapid refreezing. A defensible recovery chain turns off the heater, waits through a drain interval, then requires both a minimum fan delay and an evaporator temperature below a restart threshold. Danfoss controller documentation exposes fan behavior during defrost, fan delay after defrost, and fan start temperature as separate controls, which is consistent with this layered permit design.
Commanded fan state is not proof of physical rotation. If the hardware supports tachometer or current feedback, compare it with the command. Without direct feedback, temperature gradients, cooling-cycle changes, or current signatures can indicate a possible failure, but the platform must label that inference accurately. “Fan command on” and “fan verified running” are different data contracts.
Door-switch bounce deserves its own input filter. A rapidly toggling contact should not create a storm of state changes or repeatedly reset the fan delay. Debounce the physical input, retain the raw diagnostic count, and apply an independent “door open too long” alarm timer. The alarm timer should not be used as the fan-control timer because they answer different operational questions.
5. Implement defrost as a lifecycle
A periodic trigger answers only when a defrost attempt begins. A complete electric-defrost lifecycle defines entry conditions, compressor and fan interlocks, heater control, evaporator termination temperature, maximum duration, drain time, post-defrost fan delay, recovery, and abnormal completion. A rule such as “heat for 20 minutes every six hours” gives the same output for light frost, heavy frost, a displaced probe, and a failed heater. It may waste energy in one cabinet and leave another blocked with ice.
Use temperature or maximum time, whichever comes first, to terminate heater output. Reaching the evaporator stop temperature can represent normal completion. Reaching maximum time is a safety and diagnosability limit; it should stop heating but record defrost_max_timeout rather than pretending the cycle succeeded. Service teams can then inspect probe placement, heater current, drainage, airflow, and environmental loading.
The trigger can eventually evolve beyond a fixed calendar. Compressor accumulated runtime, door events, evaporator behavior, or a frost proxy may reduce unnecessary cycles. Adaptive logic, however, creates a new false-positive and false-negative responsibility. When field evidence is limited, a fixed schedule with temperature termination and a hard maximum is usually easier to validate. Move to an adaptive trigger only after telemetry can detect both missed defrost and excessive defrost.
This article assumes an electric heater and therefore prohibits simultaneous heater and compressor operation. Hot-gas defrost, multiple evaporators, pump-down arrangements, electronic expansion valves, and parallel compressors require different permits and sequences. The state-machine approach remains useful, but copying the output table would be unsafe.
6. Separate calibration from sensor trust
A calibration offset compensates for a measured, stable bias. Open circuit, short circuit, out-of-range data, implausible rate of change, or a value stuck for an abnormal period are trust faults. Treating a trust fault as a larger calibration problem can hide wiring, installation, or probe damage behind an ever-growing offset.
The safest fallback for an invalid cabinet probe depends on the stored product and system risk. The deterministic example inhibits compressor, fan, and heater and raises an alarm. Some food cabinets may use a validated duty-cycle fallback to avoid immediate warming, while medical or laboratory storage may require load transfer and a formal excursion process. The design team must compare the loss caused by continuing versus stopping and document the fallback. Firmware should not invent the policy during implementation.
An invalid evaporator probe has a different effect. Ordinary cabinet-temperature control may remain possible, but temperature-terminated defrost and temperature-qualified fan recovery are no longer trustworthy. Options include disabling automatic electric defrost or using a strictly bounded time fallback with a higher-severity alarm. Averaging two disagreeing probes is not automatically safe: one may be attached to the evaporator while the other hangs in air, making the average physically meaningless.
Store raw value, calibrated value, quality state, and quality reason separately. This enables the platform to show whether a displayed temperature is directly measured, offset-corrected, substituted, stale, or invalid. It also prevents a remote UI from presenting a fallback estimate as a healthy sensor.
7. Verify event traces, not one steady-state temperature
This validation uses a deterministic Python policy probe. It uses a -18°C setpoint, 2 K differential, 180-second minimum-off time, 120-second minimum-on time, 8°C defrost termination, 1,200-second maximum defrost, 60-second drain interval, 90-second fan delay, and -5°C fan restart temperature. These values make transitions unambiguous; they are not recommended settings for production equipment.
Fourteen assertions cover warm power-up during the minimum-off interval, allowed compressor start, door-open fan inhibit, minimum-on hold, normal stop, defrost entry, active defrost, temperature termination, drain, recovery entry, fan hold on a warm evaporator, recovery completion, cabinet-probe failure, and maximum-defrost timeout. All 14 assertions passed using a fixed input sequence and step-by-step state assertions that make the transition order and interlocks reproducible.
The evidence proves only that this policy produces the expected states and interlocked outputs for those inputs. It does not contain a thermodynamic plant model. It cannot prove pull-down time, refrigerant behavior, compressor sizing, heater power, relay life, electrical safety, or energy consumption. Hardware-in-the-loop testing should inject real probe resistances, relay feedback, door bounce, power loss, clock changes, and communications outages. A physical cabinet test must then verify the temperature and frost behavior under target ambient conditions, loading, and door usage.
Boundary testing is particularly valuable. For a 180-second minimum-off setting, assert inhibit at 179 seconds and permission at 180. For a 1,200-second maximum defrost, assert continued heater permission at 1,199 and termination with an alarm at 1,200. Repeat after reboot and after configuration updates. These tests find counter origin, persistence, and comparison errors that a long normal cycle often misses.
Failure injection should distinguish command, feedback, and physical result. For example, test a compressor command with no current response, normal current with no cabinet cooling, a heater command with no evaporator rise, and a fan command with no tachometer. Each failure belongs to a different diagnostic layer and should not collapse into one generic “temperature alarm.”
8. Make remote parameters, observability, and rollback part of control
Once the controller connects to an IoT platform, setpoint, hysteresis, timers, and defrost schedule become remote configuration. The platform should preserve configuration version, requester, old values, target values, device acknowledgement, activation time, and rollback result. “Sent” is not “active” when the device is offline. The loop closes only when the device reports the active version and validation result.
Not every raw sample needs high-frequency cloud storage, but state transitions do. Useful fields include mode, cabinet and evaporator temperatures, raw and calibrated values, sensor quality, compressor/fan/heater commands, permit-denial reasons, state-entered time, accumulated compressor runtime, previous defrost trigger, and termination reason. These fields distinguish “temperature high while minimum-off protection is active” from “compressor commanded on but no physical cooling occurs.”
Validate configuration statically before deployment. Reject impossible or unsafe combinations such as a zero minimum-off interval, an out-of-product setpoint, an excessively small differential, a contradictory defrost stop/maximum combination, or a mode that assigns one relay to incompatible loads. Then roll out to a small cohort and compare cycle frequency, temperature excursions, defrost timeouts, and energy patterns against a baseline.
Rollback must be an owned path, not a technician manually restoring many fields. Devices should retain a previously confirmed configuration, switch versions atomically, and report the result. A rollback threshold might be a rise in defrost timeouts, compressor starts per hour, temperature-excursion minutes, or failure to acknowledge the new version. The threshold should be established before the rollout, not after the first incident.
For a connected controller such as EchoNet-FZ5, the durable value is not merely an app switch. It is the connection between local protection, versioned remote configuration, event evidence, and safe rollback. For the product and platform surfaces, see the smart refrigeration controller and ZedIoT platform. Those pages describe capabilities; they do not replace equipment-level qualification.
9. Know where this reference design does not apply
Do not copy this output sequence into hot-gas defrost, variable-speed compressor, parallel-compressor, multi-evaporator, electronic-expansion-valve, or regulated storage systems without a new control review. Medical, vaccine, laboratory, and high-value cold-chain systems also need independent monitoring, data integrity, alarm acknowledgement, backup power, and excursion handling. A healthy local controller does not prove stored material remains acceptable.
Even a conventional commercial cabinet requires parameters validated against the target compressor, evaporator, condenser conditions, loading, probe mounting, door frequency, and ambient range. Software tests can prove that the controller does not issue mutually incompatible commands. They cannot replace refrigeration-system matching, electrical safety, EMC, lifecycle, and field testing.
Conclusion
Reliable refrigeration control is built from priority, invariants, and recovery. Reject untrusted inputs first, complete defrost and post-defrost recovery next, and only then evaluate cooling demand with hysteresis and compressor timing. Give every output an explicit permit and denial reason, and never let a cloud request bypass local protection.
A minimum shippable implementation includes boundary-event tests, state-transition telemetry, configuration versions, and rollback—not just a steady cabinet temperature demonstration. If the team can explain why every output was permitted, when it must stop, and how the system recovers after failure, the controller has become verifiable engineering instead of a collection of timers that happens to run.
FAQ
Does a larger differential always protect the compressor better?
It may reduce switching near the threshold, but it does not replace minimum-off and minimum-on protection. A large differential also increases cabinet-temperature variation and must be validated against storage requirements.
Is an evaporator probe mandatory for defrost?
A controller can use time-only defrost, but its termination and energy boundaries are less precise. An evaporator probe supports temperature termination and fan recovery; a maximum-duration limit and sensor-fault policy are still required.
Can the cloud force a compressor to start?
The cloud can request cooling or a maintenance action. The local controller should still enforce sensor validity, defrost state, minimum-off time, and hard faults. An ordinary remote command should not be a protection bypass.