Temperature probes fail. A lead goes open-circuit, a sensor is unplugged, a packet decodes as nonsense — and the device keeps transmitting, so what arrives looks like a reading rather than a failure.
QTRACA checks every reading for physical plausibility before it is used. An implausible value is recorded as a probe fault instead of being treated as a temperature, so it cannot satisfy a check, silence an alert, or distort a chart.
What counts as implausible
A reading is rejected when it falls outside −80 °C to 400 °C, or when no value arrives at all.
That range is deliberately wide. It is a physical sanity gate — is this a temperature at all? — not a process limit. Any real blast freezer or oven probe sits comfortably inside it. What it catches is hardware nonsense: the open-circuit sentinel values a probe emits when its lead fails, and the garbage produced when a non-temperature packet is decoded as a temperature.
Your CCP limits still do the process job. This gate only removes values that are not temperatures. A reading of 8 °C on a chiller is plausible but out of specification — that is an alert, not a fault.
Per-device ranges were considered and deliberately not used: a mis-set range would silently discard good data, which is the same failure this exists to prevent, pointed the other way.
Fault reasons
| Reason | Meaning |
|---|---|
| Probe fault | A value arrived but is not physically possible — typically a failed probe or lead. |
| No reading | The device reported, but with no temperature in it. |
What happens when a probe faults
- The reading is stored with its fault reason rather than discarded. You can see that the device reported and what it sent.
- The device is marked in fault, recording when the episode began.
- An email goes out to notify you.
- Alert rules are suppressed for that device while it is in fault — see below.
- The value is not usable as a temperature anywhere in the system.
The fault episode
A fault is recorded as an episode, not as a series of events. The start time is when the probe first failed and it stays put — so a probe dead for a week reports as having failed a week ago, not as having just failed on its latest transmission.
The episode ends when a plausible reading arrives, and the device clears itself.
Email, at most once an hour
You get one fault email per device per hour, however often the probe flaps in between. A probe cycling faster than that is one event to a person, not twelve.
Why alerts are suppressed during a fault
A failed probe frequently reports an extreme value. Left alone, that would fire your temperature alerts — and you would be chasing a freezer excursion that never happened while the actual problem, a broken probe, went unmentioned.
So while a device is in fault, its alert rules are held and you are told about the fault instead. One true alarm rather than a stream of false ones.
Faults and CCP checks
An implausible reading can never satisfy a CCP target. A monitoring point waiting on a temperature stays unsatisfied when what arrives is a fault — because a broken probe has not demonstrated anything about your process. The check remains outstanding until a real reading arrives or someone records one another way.
Faults on charts
Charts show fault periods rather than hiding them, and readings with no value are skipped rather than plotted as zero.
A gap on a chart therefore means what it appears to mean — no usable data for that period — instead of a line dropping to zero and implying a temperature that was never recorded.
Packets that are not readings
Devices send more than measurements: join requests, status frames and other housekeeping traffic. These arrive on different ports and are not decoded as temperatures, which removes a whole class of nonsense values at the source rather than catching them later.
What to do about a fault
- Check the probe and its lead at the device. Open-circuit values almost always mean a physical fault.
- Check the readings for the device to see when the episode began.
- Cover the gap. While a probe is faulty, monitoring for that point has to be recorded another way — a manual check on a form — because the automatic route is not producing usable data.
- Once repaired, the next plausible reading clears the fault automatically. Nothing needs resetting.
Things to know
- A fault is not an offline device. A faulty probe is transmitting but sending unusable values; an offline device has stopped transmitting. They are reported separately.
- Faulted readings are kept, so the record shows what the device actually sent.
- The bounds are fixed, not configurable per device, on purpose.