All chapters
Arming
A place can be armed for intruder detection. You group the place's door, window and motion sensors into profiles (“Night”, “Away”, “Perimeter”), and a user or a rule arms a profile. Huntress refuses to arm while one of its sensors is open, and rules can read the armed state and react when a sensor trips: the response is a rule you write, so it can be an incident, an e-mail or a siren.
Profiles#
- A profile belongs to one place and holds that place's open/closed or triggered/clear sensors: doors, windows, motion, glass break and the like. Outputs, analogue sensors and a gas sensor that has a limit are not offered. A sensor can be in several profiles.
- Several profiles can be armed at the same time, for example a perimeter profile outside and an inside profile while you are at home. The place counts as armed while any of its profiles is.
- Profiles are created, changed and deleted on the Arming tab of the place by an Owner or Admin. Viewers see them.
- Deleting a sensor, or moving it to another place, takes it out of its profiles. A place has at most 50 profiles and a profile at most 500 sensors.
Arming and disarming#
Any member of the organisation can arm and disarm on the Arming tab, like operating an ordinary output. A rule arms as itself, and the timeline records who or what did it. A badge on the place's cards, on the dashboard and on the place page shows what is armed.
An open sensor blocks arming#
Arming is refused while any sensor of the profile is open or triggered, or a linked alarm-panel zone is active. The message names the sensors, and the refusal is recorded in the timeline. Close them and arm again.
- A sensor that is offline, or has never reported a value, does not block: its last value cannot be trusted either way. It is listed as not reporting in the arming event. A profile whose sensors are all offline can therefore be armed. A sensor that has merely been quiet for a while is not offline: without uptime monitoring its last value, such as an open door, still counts.
- A profile with no sensors cannot be armed.
- The check reads the stored readings, which can be a fraction of a second behind: a door that opened a moment ago may not block the arm.
Arming anyway#
A profile has the switch Allow arming with open sensors. When it is on, a user who arms with open sensors is asked to confirm, and the open sensors are bypassed until the profile is disarmed: they do not count as guarded, so rules do not treat them as armed, and the arming event names them. A rule arms without being asked, so the switch decides for everyone. A bypass lasts for the whole arming, not until the sensor closes.
Arming an armed profile, or disarming a disarmed one, changes nothing and records nothing. A rule arms or disarms a given profile at most once every 10 seconds.
In rules#
| Piece | What it does |
|---|---|
| Arm place and Disarm place (actions) | Arm or disarm a chosen profile. The profile names its place, so it works in any rule, a schedule trigger included. A refusal is not an error of the rule. |
| Profile armed (condition) | True while a profile is armed, or while it is not. With no profile chosen it asks about the sensor that fired: is it in an armed profile that did not bypass it? A sensor in no profile, such as a camera, asks whether any profile of the place is armed. |
| Arming change (trigger) | Starts when a profile is armed, disarmed, or cannot be armed. Choose the profiles and the changes, or leave them open for all. |
A missing profile, one of another organisation, or none chosen makes the condition false either way, and the action does nothing; Huntress never guesses.
Arm at night, disarm in the morning#
Start a rule on a schedule that switches on at 22:00 and give it the action Arm place for the Night profile. Start another when the schedule ends with Disarm place.
Raise an incident when an armed door opens#
Trigger on the door contacts, add the conditions Value threshold above 0 and Profile armed with no profile chosen, and the action Create incident. The value condition matters: an open door reports 1 and a closing door reports 0 from the same sensor, so without it closing the door would start the rule too. Do not filter on the event nature: door and window contacts report the same open/close nature for both. While the profile is disarmed an open door is just a door.
Be told when a scheduled arm did not happen#
The schedule's rule does not retry when a window was open at 22:00. Add a rule with the trigger Arming change, the change Cannot be armed, and Send e-mail: the refusal is an event that rules can hear. The rule that armed is never started by its own change, but other rules are.
In the timeline#
| Event | Recorded when |
|---|---|
| ProfileArmed | A profile was armed, by whom, which open sensors were bypassed and which were not reporting. |
| ProfileDisarmed | A profile was disarmed, or deleted while it was armed. |
| ArmRefused | Arming was refused: open sensors, no sensors, or a rule that could not arm. |
They appear in the place's events and in All Events, in the Automation domain.
Behaviour worth knowing#
- A refused scheduled arm is not retried when the sensor closes.
- The Profile armed condition reads the arming as it is now; the editor's Test tab replays old events against the current arming.
- Huntress does not raise an alarm by itself, and has no entry or exit delay: both are rules you build from the pieces above.
- A rule that is started by an arming change cannot also read an incoming event (a threshold or a sensor type), because there is none.