A freezer warms briefly during restocking and sends repeated alerts. Later, a genuine high-temperature incident disappears from the dashboard when someone clicks Acknowledge, even though the cabinet is still warm. Both failures can start with the same shortcut: one threshold comparison controls detection, notification, and closure.
A temperature alarm needs three separate answers: Has the abnormal condition persisted long enough to require action? Has someone taken responsibility? Has the equipment recovered? Thresholds and delays answer the first question, acknowledgement answers the second, and fresh device evidence answers the third.
High temperature, a failed probe, a door left open, and power loss need different evidence. Start with the lifecycle of one event, then define the rules and response for each fault type.
Follow one alarm from detection to recovery
Suppose a cabinet temperature keeps rising. The system first enters pending, allowing time for a temporary disturbance to clear. If the configured delay expires while the condition continues, it creates an active event and notifies the responsible person.
An operator's acknowledgement changes the event to acknowledged, while the display continues to show the actual temperature. The event becomes recovered only after valid readings enter the recovery range and remain there for the required hold. A separate closed state can record a completed work order or loss investigation.
The recovery-observation step emphasizes the waiting period. If the fault returns during that period, continue the same event and retain its acknowledgement and response history. An implementation can use a separate state or a recovery timer; a change in the displayed state must not erase ownership.
Technical recovery and administrative closure serve different purposes. A stable temperature establishes recovery. Whether goods were damaged or a repair was completed needs another record. A routine door event can close automatically after a stable closure, while a damaging temperature incident may need an owner's review.
Set temperature thresholds and delays from cabinet behavior
A short excursion does not establish a refrigeration fault
Restocking, defrost, and loading warmer goods can all create temporary peaks. Six samples collected ten seconds apart cover roughly a minute. That is weak evidence of failure if the cabinet normally needs longer to return to its operating range.
Read the curve alongside door and control activity. A rise during restocking may be explainable. A continuing rise with the door shut, defrost finished, and compressor running deserves closer inspection of airflow, seals, or refrigeration capacity.
Triggering and recovering each need two settings
| Setting | What it controls | A poor setting can cause |
|---|---|---|
| Entry threshold | When temperature starts an abnormal-condition observation | Routine operation repeatedly enters pending |
| Persistence delay | How long the excursion must last before an alarm | Nuisance alerts if too short; late intervention if too long |
| Recovery threshold | When the system begins checking for recovery | Repeated state changes if too close to the entry threshold |
| Recovery hold | How long healthy conditions must remain stable | Premature recovery after one good sample |
Separating the entry and recovery thresholds creates hysteresis. It reduces repeated switching near a boundary, but an excessive gap can keep a stable cabinet in alarm. Choose it with the normal operating range and probe uncertainty in mind.
Persistence and recovery hold also do different jobs. One decides when intervention is warranted; the other establishes stability afterward. Neither a single high reading nor a single healthy reading should decide the entire incident lifecycle.
Use measured operating curves to choose a delay
Record normal operation, restocking, defrost, and startup recovery, with door and compressor states attached. Establish the size and duration of acceptable disturbances, then compare them with allowable exposure and the time staff need to respond.
If the delay needed to filter normal disturbances would exceed the business response window, increasing it further is a poor solution. Investigate probe placement, equipment capacity, or operating procedures. A local reminder followed by a later escalation may also fit the workflow better.
Special operating windows need a defined start, end, and maximum duration. An indefinite maintenance flag must not suppress a persistent fault. Re-evaluate temperature after the permitted window ends, and attach a configuration version to each change in thresholds or timing.
Prometheus provides for to delay alert firing and keep_firing_for to retain firing after a condition disappears. These help explain timing semantics. A temperature controller still needs its own hysteresis, data-validity checks, and operating-state logic; software-monitoring settings are not cabinet parameters.
Handle invalid probe data before temperature evaluation
A failed input must not create a second temperature incident
An open or shorted probe can decode as an extreme temperature. If the platform continues evaluating that value, operators may see both a temperature alarm and a probe alarm and mistake one data-source failure for two independent faults.
Check input quality before temperature. Once the input is invalid, stop deriving new high- or low-temperature judgments from it and expose the sensor fault. An existing high-temperature event must not recover just because its probe failed: the system has lost reliable observation, not established healthy conditions.
Local outputs need a corresponding failure policy. Options include disabling hazardous outputs, using a qualified backup probe, or applying a restricted fallback. The appropriate action depends on the equipment and load; turning every output off is not universally safe.
The refrigeration-control simulation referenced here prioritizes probe invalidity over cooling and defrost and disables its selected outputs. That shows the sequence is testable. It does not establish hardware safety for a production controller.
Recovery needs valid samples with advancing timestamps
A single communication-check error, sampling transient, or bus retry may not warrant an incident. Persistent invalidity, an out-of-range input, or an exceeded freshness window can. This delay depends on acquisition behavior, rather than the cabinet's thermal inertia.
For recovery, check that samples remain valid and their timestamps advance. A plausible number can come from a stuck probe or a repeatedly uploaded cache entry. Range checking alone can turn missing telemetry into a deceptively flat temperature chart.
Store value, quality, sample_time, and platform receipt time separately. Show the last update time in the interface so staff can distinguish a stable temperature from the absence of new measurements.
Design door-open and power-loss rules separately
Escalate a door event around the operating process
Product retrieval, extended restocking, and a door that will not close deserve different responses. A local reminder can come first, followed by a platform event after persistence and escalation if nobody takes ownership or the impact grows. Derive the intervals from actual operating procedures.
Contact bounce and reopening must not create an incident per transition. Start a recovery timer when the door closes. If it reopens before the hold completes, continue the original event. A new prolonged opening receives a new event identifier only after the previous occurrence has recovered.
Repeated long openings are useful maintenance evidence even when each eventually clears. They can prompt inspection of hinges, seals, or restocking practice. Immediate messages help people respond; retained event history helps them find a recurring cause.
An offline device does not confirm power loss
A controller that loses power may be unable to send a final message. An offline status, MQTT will, or communication timeout establishes a connection or visibility problem. Network loss, gateway failure, and a power outage can produce similar observations.
Confirmed power loss needs additional evidence, such as independent supply monitoring or an input on a backed-up gateway. Without it, show “Device offline; power status unconfirmed” and retain the last sample time. This prevents the interface from steering technicians toward an unproven electrical diagnosis.
If the entire site disappears, surface a site-level incident and relate affected devices. Sending the same message for every controller can obscure the useful information and make one gateway fault look like many simultaneous equipment failures.
Reconnection only begins recovery. Configuration may still be loading, probes may be settling, or compressor protection may be delaying startup. Verify critical inputs, a fresh snapshot, and the applied configuration before starting the recovery hold.
After acknowledgement, keep ownership and risk visible
Taking responsibility does not end the fault
Acknowledgement records that a person or team has accepted the incident. It can stop repeating the same reminder to that person, while temperature, door, and probe conditions continue to be evaluated. The dashboard should support “Acknowledged” and “Fault continuing” at the same time.
No acknowledgement and no recovery after acknowledgement are different escalation reasons. The first addresses an unanswered notification; the second addresses an unresolved condition. Define separate timing origins, recipients, and actions so the acknowledgement button cannot silently cancel both paths.
For example, continued temperature rise after acceptance may require a regional owner. If a work order exists, later messages should include its identifier, the current peak, and elapsed duration. That gives the next responder usable context instead of another isolated “Temperature abnormal” message.
Preserve enough history to explain a slow response
Connect first detection, activation, delivery attempts, acknowledgement identity and time, recovery start, recovery completion, and corrective action. Those records distinguish slow equipment recovery from late human response or a message that never arrived.
Where loss tracking matters, acknowledgement and closure permissions can differ. On-site staff accept the incident, maintenance records the work, and an owner confirms the outcome. A smaller operation can simplify the roles while still retaining who did what in searchable records.
Prevent repeated messages for the same fault
Join samples, notifications, and work orders with an event ID
Each temperature upload must not create another incident. Event identity includes site, device, and fault type, with tenant and channel identifiers where applicable. While one occurrence continues, subsequent samples update its peak, duration, and context.
An identifier must also distinguish separate occurrences. A high-temperature incident today and another tomorrow cannot share one permanent event ID, or deduplication may hide the second one. After stable recovery, a new trigger needs a new occurrence sequence linked to the same device history.
SMS, app notifications, email, and work orders reference that event. Delivery retries use channel-specific idempotency keys. This prevents duplicate work orders while preserving outcomes such as one failed SMS and one successful push attempt.
Reduce interruptions without erasing different causes
Probe invalidity can suppress derived temperature evaluation. A long-open door and rising temperature can remain separate, related events: closing the door is an immediate action, while temperature recovery still needs observation afterward.
One generic equipment alarm conceals the next action. Completely unrelated incidents can generate competing work orders. Group messages where that reduces interruption, but retain information that changes how the technician should respond.
Persist the event before notifying asynchronously. A provider timeout, email bounce, or failed push changes delivery status, not equipment status. The operator console reads the event record instead of inferring health from the last send result.
Divide work between controller, gateway, and platform
| Component | Main responsibility | What it should retain during disconnection |
|---|---|---|
| Local controller | Probe-fault response, protected outputs, local buzzer, door input | Local protection and critical event records |
| Gateway, where used | Protocol conversion, buffering, event time and sequence transfer | Events not yet acknowledged by platform storage |
| Platform | Fleet history, ownership, escalation, work orders, trends | Stored events, delivery outcomes, and operator actions |
Check offline protection first when selecting hardware. Compressor timing and invalid-probe behavior cannot wait for a cloud round trip. The controller reference used here includes NTC inputs, relay outputs, and local alarms, but the selected model and firmware still need feature-by-feature verification.
A gateway that retains only the latest temperature loses faults that occur and recover during an outage. Buffer event time and sequence, clear records only after platform storage acknowledges them, and deduplicate replay by event identifier.
These capabilities must exist in the selected products. Drawing a gateway in an architecture does not give it persistent storage. If the controller lacks nonvolatile event memory and the gateway can also lose power, accept the history gap explicitly or budget for backup power and persistent storage.
When distributing thresholds, retain both desired and applied policy versions. If some devices miss an update, show that difference. Otherwise, the operator sees an intended setting while incident analysis cannot recover the rule the controller actually ran.
Check the lifecycle with deterministic simulations
Walk through one complete temperature event
The following times are synthetic inputs, not suggested cabinet settings. With a ten-minute persistence delay and a five-minute recovery hold, the example follows this sequence:
- Minute 0: a high reading starts pending; no notification is sent.
- Minute 10: continuing high temperature creates
high-001and sends one notification. - Minute 11: an operator acknowledges; the event remains unresolved.
- Minute 20: temperature enters the recovery range and starts the hold.
- Minute 25: the completed hold establishes recovery.
This checks that acknowledgement does not end the incident. A separate path keeps temperature high after acknowledgement and escalates once at its configured fifteen-minute limit. Repeated samples and another acknowledgement do not create duplicate escalation messages.
The hold can also be interrupted. A door that reopens before stable closure resets the recovery timer without changing the event ID. After completed recovery, a new prolonged opening receives the next occurrence identifier.
Separate tested rules from field acceptance
| Simulated input | Result checked by the local example |
|---|---|
| Three-minute temperature excursion | Returns to normal without a formal notification |
| Persistent heat, acknowledgement, stable cooling | Retains the event until the recovery hold completes |
| Persistent heat after acknowledgement | Escalates once at the post-acknowledgement limit |
| Long-open door, repeated samples, brief closure and reopening | Deduplicates within one event; a new recovered occurrence gets a new ID |
| Invalid probe, stale temperature, permitted defrost window | Does not create a high-temperature event from those inputs; stale healthy readings cannot clear an active event |
| Confirmed power loss, incomplete boot, fresh recovery data | Retains the fault until readiness, freshness, and recovery hold are satisfied |
The accompanying script executes 32 assertions, counted from successful assertion calls. It uses in-memory state and explicitly advanced time. These results establish behavior under the listed inputs, not real-cabinet performance or notification-provider reliability.
The power test explicitly supplies power=false, assuming trustworthy external power evidence is already available. It does not test diagnosis of a power outage from network loss, persistence across service restarts, clock changes, administrative closure, or multi-level escalation.
This is an AI-generated illustration, not a field-test photograph or measurement result. Acceptance requires actual device data, event records, and operator actions to be compared on the same timeline.
Verify failure paths before rollout
| Test situation | Expected behavior to verify |
|---|---|
| Excursion clears within the delay | No formal event or unnecessary notification |
| Fault returns during recovery observation | Continues the original event and retains acknowledgement history |
| Fault persists after acknowledgement | Uses the agreed post-acknowledgement escalation policy |
| SMS timeout or push failure | Keeps the fault visible, records each channel, and avoids duplicate work orders |
| Device power loss or site-wide disconnection | Distinguishes confirmed power failure from lost visibility |
| Service restart or buffered gateway replay | Preserves event identity and timing and reconstructs occurrence order |
| Threshold change or failed configuration delivery | Retains the original rule context and shows the applied device version |
Prioritize paths that can cause missed alarms, false recovery, or lost history. Then verify message presentation and reminder frequency. A useful acceptance record connects the input, event ID, state changes, and delivery outcome; one message on a phone is insufficient evidence.
Service restart needs its own test. In-memory events and timers can disappear, causing a fresh waiting period or a duplicate event for the same fault. Persist the necessary state and define how disconnected intervals and clock changes affect elapsed time.
Policy changes also need a declared effect on active incidents. Existing events can retain their creation-time snapshot while new events use the new version. If an urgent change must affect an ongoing event, record the actor, version, and reason instead of silently rewriting its basis.
When a full event platform earns its cost
One low-consequence asset in a continuously staffed location may be adequately served by a local buzzer, probe-fault protection, high/low alarms, and clear recovery indication. Escalation, detailed permissions, and work-order integration add configuration and maintenance that may not yet pay off.
A platform becomes more useful when equipment spans sites, incidents require handoffs, or the organization needs to establish who handled a fault and when. Separate detection, ownership, and recovery first, then add workflow features for actual coordination needs.
Medical storage, food traceability, and laboratory projects also need their own decisions about calibration, retention, and permissions. The alarm logic described here does not establish industry compliance or replace equipment and field validation.
For a retrofit discussion, collect the controller model, available temperature and door data, examples of nuisance alarms, and the people responsible for response. This helps locate the problem in the equipment, settings, connectivity, or workflow and define the scope of local changes and platform development.
For the connectivity decision, see remote monitoring and alerts for freezer temperature controllers. For local protection sequences, continue with the cold-storage controller control-logic guide.