All chapters
Core concepts
Huntress has few concepts, and they compose. Learn these and every page of the product reads the same way.
Organisations and roles#
An organisation owns all its data: places, sensors, people, rules, incidents. Organisations are isolated from each other in every query and every listener. A person signs in to one organisation at a time.
| Role | Can do |
|---|---|
| Owner | Everything an Admin can, and also removes Admins. Whoever creates an organisation is its Owner; the Owner cannot be removed, and a new member cannot be made an Owner. |
| Admin | Changes configuration (places, sensors and cameras, people, alarm panels, rules, schedules, devices), adds members as Admin or Viewer, removes Viewers, manages API keys, and operates sensitive outputs such as locks and sirens. |
| Viewer | Reads everything and does incident triage: resolve, add notes and set the external reference. Cannot change configuration and cannot operate sensitive outputs. |
Owners and Admins of one organisation, named by System:AdminTenantId (the first one by default), also administer the installation itself: they approve server updates.
Places and zones#
A place is a physical location. It holds sensors, outputs, alarm panels, zones, geofences, rules and incidents, and has a page with a live overview, 24-hour charts and tabs for each of those.
A zone is a named area inside a place: a floor, a yard, a perimeter. Zones nest, can have a boundary drawn on a map, and sensors and outputs are assigned to them. A zone's heading offers bulk All on / All off for the outputs inside it.
A place can also be armed for intruder detection: you group its door, window and motion sensors into profiles and arm them, by hand or from a rule. See Arming.
Sensors#
A sensor is anything that reports to Huntress: a contact, a thermometer, a camera, a panel zone, a light switch. Each has one of 116 types in 13 categories (see Sensors), a secret token for ingestion, a status, a last-seen time and optional limits and uptime monitoring.
Outputs are sensors of the Control category: things Huntress can operate as well as read. Cameras are sensors that carry pictures.
Events and the ontology#
Whatever arrives is normalised into an event with five facts: a domain (Intrusion, Fire, Medical, Panic, Access control, Environmental, System, Automation, Video, Open/close, Person, Unknown), a category, an event type (BurglaryAlarm, MotionDetected, ThresholdExceeded, ObjectDetected …), a nature (Alarm, Restore, Trouble, Bypass, Test, Status, Command, Open/close) and a severity (Critical, High, Medium, Low, Info).
This is what lets one rule treat a glass-break detector, a panel's burglary zone and a camera's person detection as the same kind of thing. Every event is stored with the raw request that produced it. See Event reference.
Rules and schedules#
A rule reads as a sentence: WHEN something happens, IF conditions hold, THEN actions run, OTHERWISE other actions run. Rules are evaluated as events arrive and, for conditions about time passing, every 30 seconds. A schedule is a named definition of when something is active (business hours, a maintenance window, a closure) that many rules can share. See Rules and Schedules.
Incidents#
An incident is what asks for a person's attention. A rule opens one (or adds the event to the one already ongoing for the same source and domain), it carries a severity and a confidence from C1 Unconfirmed to C5 Verified, and it keeps a timeline of events and notes until it is resolved. See Incidents.
People and Pulse#
A person is a mobile asset, tracked by Pulse, a web app on their phone that sends heartbeats with location and a panic alarm. A person can be watched for silence and tested against geofences by the same rules as a sensor. See People & Pulse.
Alarm panels#
An alarm panel is a conventional intruder or fire control panel that reports over IP using SIA DC-09 or Contact ID. Huntress identifies it by its account code, maps its zones to sensors and normalises its event codes. See Alarm panels.
Devices and commands#
An output receives commands (on, lock, open, sound the siren …) from the interface or from a rule. Every command is validated, permission-checked, recorded, delivered over MQTT, Zigbee or HTTP, and followed until the device confirms it. See Devices.
Edges#
A Huntress Edge is the same program started with --edge on a small computer at a remote site. It dials out to your server, so cameras, Zigbee dongles and devices on a private network become reachable without opening anything inbound. See Deployment.
Tokens and API keys#
Two kinds of secret exist, for two jobs. A token (a GUID in the URL) lets one device report as one sensor, person or panel. An API key (hnt_…) lets a script manage places, sensors, people and panels through the REST API. Neither is shared with the other. See Security.