When the data itself is unreliable

Sensor faults are usually obvious once you know the catalog. The four patterns to recognize: (a) stuck-at-rail, where a channel sits at exactly zero or exactly its maximum for an extended period (offline or saturated); (b) sudden step change, where a value jumps to a new level without any real-world cause (a reset, a move, a firmware update); (c) impossible value, like negative humidity, 200°C temperature, RH sustained above 100%, or pressure outside the BMP390L's 300-1250 hPa range; (d) uncorrelated drift, where one channel slowly walks away from everything else over hours with no environmental driver. Terrestream checks for one of these on its own: a reading that stays frozen for hours where it would normally move.

When that happens, Terrestream holds air-quality alerts based on the affected reading until it recovers, and tells you the readings look unreliable instead of going silent; the suggested first step is to check the device connection and placement. The other three patterns are worth recognizing yourself. See how anomaly detection works for the related (but distinct) case where the data is real but the pattern is unfamiliar.

When a reading looks wrong, the checks on your side are short. Reality check: is the room actually different right now in a way that would explain the value, or does the air feel normal? Placement check: has the device been moved, bumped, or power-cycled in the last hour? Restart and give it time: a restart resolves most transient faults. The VOC index needs about an hour and the NO_x index about six hours of operation to meet specification. For CO₂ there is nothing to trigger by hand: the sensor's automatic self-calibration needs fresh air (around 400 ppm) at least once a week, and the CO₂ reading meets its accuracy specification after about two days of operation that include fresh air. Contact support if a fault repeats after a clean restart, or if a channel stays stuck for more than an hour.

Terrestream follows one rule when a reading looks stuck: it does not recommend an intervention based on that reading. The distinction between a real spike and a glitch comes down to shape and corroboration: real events have a rise, a peak, and a decay that match a known pattern, and they usually move more than one channel (cooking moves PM and VOC together; a shower moves RH and temperature together); glitches are vertical, single-channel, and have no plausible driver. See where the numbers come from for how each value on the dashboard is produced.