Sensors

A sensor is the unit of everything Huntress measures or controls. Huntress ships 116 sensor types in 13 categories. The type decides how a reading is understood: which event it becomes, how severe it is and how it is drawn.

What a type decides#

• On/off sensors report 1 (triggered, open, active) or 0 (clear, closed, inactive). The type decides which event a 1 stands for: a door contact opening is not a smoke detector going off.
• Numeric sensors report a measurement with a unit: temperature, humidity, air pressure, power draw, strain. Huntress keeps the number, draws it as a line and lets you set limits on it.
• Picture sensors (the Video / Optical category) take images instead of values. Any sensor can also attach a snapshot to a reading.
• Outputs (the Control category) are sensors Huntress can also operate. See Devices.
• The Pulse tracker is the sensor type behind a person. See People & Pulse.

The catalogue#

Every type below can be added to a place; outputs (the Control category) are added from the place's Outputs tab. A numeric type is marked with a small 123 symbol; all others report on/off or pictures. Concentration types (gases, radiation, dust) report on/off until you give them a limit, then measure.

Status, last seen and uptime monitoring#

A sensor is Online, Offline or Unknown: Unknown is a sensor that has not reported yet, or one without uptime monitoring a little while after its last report. Every reading, state report and picture refreshes its last seen time, which is also shown on its place.

Under Uptime monitoring in the sensor's settings, switch on Monitor uptime / heartbeat and choose how many minutes of silence are tolerated (1 to 10,080). A sensor that stays quiet longer is marked offline. A rule can react to it with the Sensor offline for condition, and a rule can resolve its incident when the sensor returns. Huntress does not blame sensors for a gap in its own availability: after a server restart it waits before judging.

Limits and hysteresis#

A measuring sensor can have a high and a low limit, set on the Thresholds tab of its page (Owners and Admins). A reading that crosses one becomes a Threshold exceeded event (Alarm, Medium) and the first reading back inside is its Restore. A rule can then react without any value check of its own: the trigger offers Only when a sensor's own limit is crossed.

• Only the crossing is an event. Further readings on the same side are ordinary readings, so the incident that the crossing opened stays open and a rule is not fired every second.
• Hysteresis is how far inside a limit a reading must come back before it counts as restored. With a high limit of 30 and a hysteresis of 2, the sensor is restored at 28 or below, and a sensor hovering around 30 raises one crossing, not one per wobble. It never delays a crossing.
• The settings page shows what the sensor usually reports over the last day, 7, 30 and 90 days (lowest, 5th percentile, average, 95th percentile, highest) and warns when a limit lies inside the usual range, where it would be crossed all the time.
• A concentration type (carbon monoxide, carbon dioxide, methane, propane, hydrogen, radiation, ammonia, hydrogen sulfide, oxygen deficiency, industrial chemical, dust) with a limit becomes a measuring sensor, drawn as a number instead of Triggered / Clear.
• A reading that carries a different unit than the sensor's is not compared with the limits.

History and charts#

The place page shows a 24-hour chart for every sensor: an on/off timeline for binary sensors, a line for numeric ones (dotted across quiet periods, so a gap does not look like a flat value) and, for cameras, a bar per hour of pictures that opens to the pictures themselves. A sensor's own page adds recent events, its incidents and, for outputs, the command history. Readings are kept for the period set by Retention:EventDays (90 days by default).

Event codes#

A reading can name the event it means with the eventCode field, for example a vibration sensor that reports GlassBreak. Each type accepts its own list of codes. GET /hunt/meta/event-codes/{token} returns the list for a sensor; an invalid code is ignored and the type's own classification is used. See Sending data.

Tokens#

Each sensor has a Hunt Token, a GUID that is part of the URL a device posts to. It is the only credential a device needs, so treat it as a secret. Copy it from the Integration panel of the sensor's settings. The interface shows it read-only; if one leaks, add a replacement sensor, point the device at it and delete the old one.