“Normal” averages can hide short-lived spikes and local gradients. Condensation risk depends on dew point vs the coldest surface, not only on a single RH number. Common causes include sensor placement in a warm airflow, a too-short sampling window, missing persistence (time qualification), and door-open humidity bursts that settle quickly.

• Check sensor_snapshot history (min/max and rate-of-change), not only the latest value.
• Validate the dew-risk window and persistence (e.g., require sustained risk before escalating).
• Log sync_state and rack_zone so “when/where” is auditable.

The most common three are: (1) alignment/mechanics (gap changes, latch not fully seated), (2) wiring intermittency (hinge strain, loose terminals, oxidation), and (3) filtering mismatch (debounce/persistence too weak for real bounce/noise). A fast proof is to compare raw edges to filtered events and see where the first inconsistency appears.

• Inspect raw input edges (before debounce) vs event output (after debounce).
• Look for correlation with vibration/door slam and cable movement near the hinge.
• Record integrity_state, bounce counters, and boot_counter around the event.

Distinguish by time signature and context evidence. Dust contamination often raises baseline slowly and increases sensitivity to small disturbances. Airflow bursts create sharp spikes that drop quickly (especially after door open/close). Maintenance should be explicit: a maintenance flag suppresses ticketing but keeps full event logs for later correlation.

• Use persistence and cooldown to prevent single spikes from becoming tickets.
• Correlate spikes with door events and fan/airflow state (as a context flag, not fan-control logic).
• Log maintenance_flag + a snapshot so false alarms can be classified.

Design as “store-and-forward with proof.” Events must be written locally first, then sent with a monotonic seq and stable event_id. The server acks the last committed sequence; the device retries until acked. Dedup must be conservative: remove true duplicates without deleting new events that share the same type.

• Verify queue depth growth during outage and orderly drain after recovery.
• Use last_ack_seq checkpoints and replay on reconnect.
• Persist critical events using robust storage (e.g., FRAM like FM24CL64B) when power loss is realistic.

Storm control works best as a layered funnel. First, reduce noise at the source (debounce/persistence/rate limit) so uplink bandwidth is not wasted. Next, aggregate at the reporting layer (batching and dedup) to protect ingestion. Finally, apply business rules at the platform/NOC layer (merge/suppress/escalate) so tickets remain actionable and explainable.

• Track the funnel: raw events → filtered events → alerts → tickets.
• Enforce cooldown windows for repetitive alerts.
• Keep evidence snapshots even when ticketing is suppressed.

“Online” only proves connectivity, not integrity. A magnet can spoof a reed/Hall contact, and a short/open can force a constant electrical state. Detection requires tamper inputs plus loop integrity (EOL concept) so the system can distinguish NORMAL vs SHORT vs OPEN and raise an integrity-grade alert. Bypass events must be logged with snapshots for non-repudiation.

• Implement and log integrity_state transitions (NORMAL/SHORT/OPEN).
• Correlate with tamper switch and configuration-change audit (config_hash).
• Escalate persistent integrity faults to CRITICAL with a clear remediation step.

Treat time as a quality-tagged signal. Use wall-clock time when synced, but always preserve ordering with monotonic seq and boot_counter. When time is not synced, mark sync_state explicitly so the audit trail never looks “precise but wrong.” On reconnect, reconcile by sequence continuity and ack checkpoints rather than trusting timestamps alone.

• Store ts + sync_state + seq for every event.
• Use RTC (e.g., MCP79410) when frequent outages are expected.
• Verify server-side ordering and gap explanations after recovery.

Separate “must-react-now” from “can-batch-later.” Door/tamper/integrity faults should wake the MCU via hardware interrupts and trigger minimal on-device actions (log + local alarm). Slow-changing sensors (Temp/RH) can be sampled periodically with longer intervals. The correct balance is validated by measuring wake latency and confirming critical events never miss their persistence windows.

• Use interrupt wake sources for door/tamper; use RTC for periodic sampling.
• Keep a minimal, power-safe “critical event commit” path for outages.
• Prove latency by test cases (open door during sleep → event logged + alert generated).

Use a window that matches the site’s real disturbance pattern. Door-open bursts may last seconds to minutes; HVAC cycling may be longer. The safe pattern is: compute risk on a sliding window, require persistence before escalating, and apply hysteresis/cooldown for recovery. Store the window parameters (as configuration) so audits can explain why an alert was raised.

• Prefer “risk must persist for T” rather than “instant threshold crossing.”
• Use rate-of-change as supporting evidence, not as a sole trigger.
• Log configuration revisions (config_hash) with every rule change.

Minimal disruption comes from a controlled maintenance mode plus evidence-first adjustments. Record baseline trends, perform a limited verification (not a full teardown), then adjust thresholds or apply calibration offsets with a versioned change log. The key is that recalibration is a configuration change: it must be auditable and correlated with improved false-alarm rates, otherwise drift returns as hidden operational risk.

• Enter maintenance mode: suppress tickets, keep full event logs.
• Compare before/after trends using the same window and placement.
• Audit changes with config_hash, fw_version, and an operator/source tag.

The first failures are often mechanical and interconnect, not the MCU. Door hardware alignment changes, connectors oxidize, hinge wiring becomes intermittent, and particle/smoke chambers accumulate contamination. Condensation accelerates corrosion and creates intermittent contact noise that looks like random access events. Reliability improves most from sealing discipline, strain relief, integrity-loop verification, and maintenance-ready alert policies that preserve evidence.

• Prioritize connectors/hinge wiring, door hardware, and sensor chamber maintenance.
• Use deployment checklists and periodic integrity-state tests (OPEN/SHORT).
• Keep power-loss evidence consistent (commit markers + boot counters).

Use a minimum test-case library with pass/fail rules and reconciliation. Run mandatory scenarios (door bounce, integrity OPEN/SHORT, sustained smoke/particle threshold, link outage replay, immediate power cut). For each, verify the funnel (raw→filtered→alert→ticket) and confirm audit continuity using seq, last_ack, and boot_counter. The workflow is complete only when every critical scenario leaves an explainable evidence trail.

• Define FP targets and “must-detect” FN scenarios before tuning thresholds.
• Prove offline buffering and ordered replay by ack/seq continuity.
• Verify power-loss behavior: no partial records; reboot trace is explicit.