Test Mode

Test mode is how planned testing avoids waking the central station: an installation (or a subset of zones) goes into test, its signals are recorded without becoming operator alarms, and when the work is done it comes out — restored, or not at all. The Insert Test tab puts installations in; the Test Queue tab watches everything that is in, and is where a forgotten installation gets noticed. Both live in Service/Data Entry (#559).

How the module progresses

1. Put an installation into test — and know where its signals go.
2. Watch the Test Queue.
3. Bring an installation out of test — the restore rule.
4. Change an installation's monitoring status.

1. Put an installation into test — and know where its signals go

Task: insert an installation's zones into test with a scheduled end, and predict where its signals will and will not appear.

Two modes. Test says: we are testing, ignore the alarms. Runaway says: a device is misbehaving and being worked on. Toggle Queue Mode [F4] switches which queue the entry targets; the Queue Mode field shows the current one (Test is the default on entry).

The insert. Insert Record [F6] opens the insert sublevel: tick Insert in Test (or Runaway Queue), set the date and time the installation is scheduled to come out, choose the scope (below), and Save. A confirmation follows, and the inserting user's branch profile is checked — the wrong profile is refused and nothing goes into test. Continue [F9] keeps the CID and lets you insert the next entry in a batch.

Three scopes — the whole installation, one zone, or a monitoring group. What you leave blank or fill in the Insert Zone window decides how much goes into test:

1. Whole installation — leave Zone and the group fields blank: every zone on the CID is in test.
2. One zone — enter its Zone number (with its Area and Code where the zone carries them): only that zone's signals are diverted; the rest of the installation stays live. A zone number in test also catches the signals a template answers for that number.
3. A monitoring group — pick it in Monitoring Group: every zone sharing that Group code (the Zones module) goes into test together, on this installation only. The list offers the installation's own groups; Include/Exclude Templates adds the groups of an attached zone template.

Zone and group are one or the other, never both. The Test Group / Subgroup / Multi Group fields serve maintenance rounds across many installations at once — awareness level here; the Insert Test reference covers them.

Where the signals go. While in test, incoming alarms are logged and routed to the test queue — they do not appear in the Alarm Queue. In the Alarm Log they wear the test colours (yellow signal-in-test, dark red alarm-in-test — the Alarm Log module), and the zone's logical status shows T (the Zones module). The insert itself is logged too: time in, zones in.

Worked example (Branch TRAIN): put your residential installation into test until the top of the next hour; raise a signal on it (Simulate Alarm, the Dispatch module) and find the signal in the Alarm Log and the test queue — and confirm the Alarm Queue stayed quiet.

Guided practice: explain test vs runaway to a technician in two sentences each, and state which one you would use for a smoke head that will not stop sending trouble signals overnight. Then give your two perimeter zones the same monitoring Group code on the Zones tab, insert that group into test, and prove the split: a simulated signal on a perimeter zone lands in the test queue, one on the smoke zone reaches the Alarm Queue.

Independent practice: a technician's insert is refused. Name the gate that refused it, and then insert only the two zones being serviced — leaving the rest of the installation live — and prove the split with one simulated signal on each side.

2. Watch the Test Queue

Task: read everything currently in test or runaway, and act on an entry directly from the queue.

A log of the test and runaway queues. The Test Queue tab's parameters choose the view — Test, Runaway, or both combined — and the grid lists what is in: who put it there (terminal), the zone or group, and when it is scheduled out. SQL Refresh [F11] re-reads the queue; multi-page queues page like the Alarm Log.

Acting from the queue. Get Installation [F2] loads the selected entry's installation into Data Entry. Get Selected Alarm from Queue [F3] hands the entry's alarm to Dispatch for treatment — if another operator already has it, you take it over, and if it was never acknowledged, the get records the acknowledgement.

Worked example (Branch TRAIN): with your installation in test from section 1, find it in the Test Queue, read its row aloud — mode, zones, scheduled out, terminal — then Get Installation and confirm the installation.

Guided practice: switch the view Test → Runaway → combined and say what each view is for; then state what [F3] would do to your in-test alarm right now, acknowledgement included.

Independent practice: the morning shift wants a habit: "every day, find what was left in test overnight." Describe the exact Test Queue routine — view, column to scan, and the two possible actions per stale row.

3. Bring an installation out of test — the restore rule

Task: take an installation out of test on time — or on purpose — and handle the zone that never restored.

Two ways out. The scheduled date and time remove the installation automatically. Remove from Test [F8] removes it now, after a confirmation — and the Insert Test list refreshes itself.

The restore rule. A restore is required before an installation comes out of test: a zone that alarmed during testing and never restored blocks a clean removal. That is deliberate — a test that ends with an unrestored zone is a premises with a tripped detector and nobody watching. The manual restore for a restore that will never arrive is the Zone Status Change window (the Zones module).

Worked example (Branch TRAIN): with your in-test alarm from section 1 unresolved, remove the installation from test — deal with the restore requirement first (restore signal, or a manual zone-status restore with a reason you can defend).

Guided practice: predict what would have happened at the scheduled end time if you had walked away with the zone unrestored — and where the reminder surfaces.

Independent practice: a technician finished at 15:00 but the installation is in test until 18:00. Decide: remove now or let it run out — then defend your answer for the opposite case, a test that overran its window.

4. Change an installation's monitoring status

Task: change the monitoring status from the Insert Test tab and know where the change is recorded.

Change Monitoring Status [F7] opens the status dialog: pick the new status, save, confirm. Every status change lands in the Alarm Log — monitoring status decides whether the installation's signals are processed at all (active statuses process; a blank Type on the status definition means active, anything else inactive — the same rule the Zones tab's Active view uses).

Worked example (Branch TRAIN): read your installation's current monitoring status, change it to a log-only status, and find the change in the Alarm Log — then change it back.

Guided practice: name the difference between an installation in test and an installation on an inactive monitoring status — duration, visibility, and who is expected to undo it.

Independent practice: a customer cancels service at month's end but the panel keeps sending. Choose the mechanism — test, runaway, or a status — and defend it against the other two.

5. Quick reference

One-liners: test = planned testing, runaway = misbehaving device · in-test alarms are logged and go to the test queue, never the Alarm Queue · zone or group per insert, not both · the branch-profile gate can refuse an insert · a restore is required before removal from test · getting an untreated test alarm records the acknowledgement · monitoring-status changes are always in the Alarm Log.