Detector

The detectors of the signalling system are components which communicate via the KNX/EIB, which monitor a part of a building and signal a break-in or attempted break-in on the panel.

Commonly used detector types supported by the panel include magnetic contacts, glass break detectors and motion detectors. Special detectors can also be sabotage detectors, allowing sabotage or fault contacts of alarm encoders or switching devices (e.g. keyswitches) to be in-tegrated in the signalling system. Also, lock monitors, such as bolt switch contacts, are detect-ors permitting a positive drive. This means that, for example, an area can only be armed when the front door is closed, i.e. the bolt switch contact is not active.

A triggered detector allocated to a security area is immediately evaluated in the signalling sys-tem and, when armed, immediately leads to an alarm. When armed, all the detectors of a secur-ity area are evaluated after a delay after triggering, if an alarm delay time was configured (see chapter 4.2.4.12.4. Alarms). When the system is unarmed, triggered detectors - such as an open window - prevent active arming of the affected detector areas.

When the system is unarmed, a triggered sabotage detector causes a fault display and thus prevent arming of the system. When armed, an active sabotage detector immediately triggers a sabotage alarm.

The detector type (contact, movement, glass break) is defined for detectors of a security area and configured separately in the ETS plug-in for each detector (see next section). The type

"sabotage detector" is specified automatically by the use of a separate communication object, independently of the security areas.

Creating detectors and detector communication

During project planning of the signalling system, detectors are added in the form of detector in-puts in the ETS plug-in by clicking the right mousebutton on the parameter node "Interior secur-ity area" or "External skin secursecur-ity area". A total of 40 detectors can be allocated to each of the two security areas in this way.

Each newly created detector can be assigned a detector text in the corresponding parameter node, which then clearly identifies the detector. This text may be a maximum of 14 characters long (e.g. "Kitchen window", "Garage door") and later, during system operation, if there is activ-ity on the part of the detector, an alarm or a fault, is either displayed in the detector list on the panel screen or in the event memory. Optionally, if there is an alarm, the detector text can be transmitted to the bus using separate 14 byte communication objects.

The detector type of a detector (contact, movement, glass break) is specified by the parameter of the same name in the parameter node of the detector input. The configured type only spe-cifies the text display in the detector list (see next section) and has no further effect on the be-haviour of a detector.

Each detector input has its own 1 bit communication object. Usually, the detectors are connec-ted to the bus using suitable KNX/EIB components (such as binary inputs, button interfaces, etc.) and are thus connected to the detector system. The connection is made between the de-tector object of the panel and the object of the bus device to which the dede-tector is connected with one group address each. For reasons of clarity and detector monitoring, only one single de-tector may be connected to each dede-tector object of the panel (Dede-tector -> Dede-tector text -> Se-curity area).

In the ETS plug-in, each detector input can be configured to different telegram polarities, i.e. in-dividual detectors can be active with a "1" telegram or a "0" telegram. The polarities configured in the signalling system must agree the flank parameters of the other bus subscribers. The fol-lowing table clarifies the relationship between telegram polarity and flank evaluation in the bus device of the detector.

Detector contact type / Status

Flank reaction in the de-tector bus device

Table 11: flank evaluation and telegram polarity of a detector telegram

Example: with the setting "Input active on 1" in the detector system, a glass break sensor may only trigger when there is a glass break and, in this case, the binary input, to which the glass break sensor is connected, transmits a "1" telegram to the bus.

The sabotage detector must not be created specially. The sabotage input is created independ-ently of the security areas in the "Signalling system" parameter node as standard and can be connected to a group address. A fault triggered by a sabotage input has a global effect on all the areas of the signalling system and requires special acknowledgement (see chapter 4.2.4.12.5. Fault). In addition, the telegram polarity of the sabotage detector input is perman-ently predefined and cannot be set. The sabotage input of the signalling system triggers when a

"1" telegram is received via the "Sabotage" object.

i If a detector input has been created in a security area in the ETS plug-in, but has not been linked to a group address, the plug-in will generate an information message before the pan-el is programmed ("Download" command). After the panpan-el is commissioned, detector inputs without linked group addresses or without a communication partner would cause a fault in the signalling system, as the detector monitoring would detect a faulty detector input (see

"Detector monitoring" section below).

To prevent function faults in system operation, all the detector inputs created in the plug-in should also be linked with group addresses and possess a communication partner in the bus.

Detector list

All the active detectors are displayed in the detector list. The display is opened by pressing the

"Detector list" button on the system page of the signalling system (see picture 36). This allows easy detection of which detectors are preventing system arming, for example. In addition, it is easy to see at any time which windows and doors are open in the building.

In addition, missing detectors and a triggered sabotage detector are entered in the detector list, allowing identification of the cause of a fault.

The following events are shown summarised in the detector list...

- All the active detectors of the two security areas

(Entry "<Detector name> + <Identification of the detector type>"

Example: "Front door opened", "Glass break, kitchen window", "Movement in corridor"), - An active sabotage detector ("Sabotage" entry),

- All the missing detectors (Entry "<Detector name> + <Text, detector missing>"

Example: "front door detector missing").

An entry only remains visible in the detector list until the appropriate detector is inactive again or has been detected as present.

If there are a number of active or missing detectors, the detector list may consist of several screen pages. It is possible to navigate between the pages using the function buttons shown at the edge of the screen.

Detector monitoring

Within a configurable monitoring period, the signalling system checks that the detectors created in the security areas exist, i.e. that they are still connected to the KNX/EIB and are functioning.

For this, the panel cyclically sends a read telegram, via the group address connected to the de-tector input, to the bus subscriber to be tested, e.g. to the transmitting object of the binary input.

This bus subscriber must then immediate send a response telegram back to the panel. This re-sponse must have reached the panel within a timeframe of 2 seconds.

Should a contacted detector not respond or respond after a delay, then the signalling system will check the appropriate detector a second and - if again no response is received - a third time within a short period. If, after the third query, the detector has still not responded, a fault (in the

"Unarmed" status) or in alarm (in the "Armed" status) is triggered without further delay, depend-ing on the system status.

If a missing detector causes an alarm, additional missing detectors can trigger subsequent alarms.

Each detector of a security area created in the ETS plug-in is monitored in the manner de-scribed. The "Detector poll interval", which can be set in the parameter node of the signalling system, defines the time between two read telegrams, i.e. the time between two detector tests.

The signalling system polls all the created detector inputs in turn in this way.

Example: poll interval: 10 s, 40 detectors have been created. -> A detector is polled every 10 s.

After approx. 400 s, all the detectors have been tested. After this, the cycle test is continued again with the first detector.

The signalling system tests detectors considered missing cyclically at brief intervals, in order to be able to detect quickly whether or not the detector has reconnected. This is important for re-setting a fault.

i Detector monitoring does not take the sabotage input into account or the inputs for arming/

unarming the security areas.

i After switching on the power supply of the panel, or after a programming operation, the sig-nalling system quickly tests all the created detectors during device initialisation for their ex-istence and, during the responses, evaluates the transmitted detector statuses (active / in-active). To avoid faults in the signalling system, during panel commissioning all the detect-ors should have been commissioned properly and function.

In addition, the detector poll may cause a delay of maximum 40 s before the signalling sys-tem is ready for arming after a device reset (precondition: all the detectors are inactive).

i It should always be ensured that each detector input created in the ETS plug-in is also linked to a group address and that there is a communication partner in the bus. For detect-or monitdetect-oring to function, the "Read" flags must be set on the objects to be transmitted by the bus devices of the detectors.

For each detector to be monitored, it is also important that the group addresses of the de-tectors to be transmitted are clear, i.e. are not connected to any other transmitting bus sub-scriber. Each messages must have an independent connection to its own detector input on the signalling system. Only then can it be ensured that only the contacted detector re-sponds and that detector monitoring is clear.