Treatment Editing

This page describes how to view and edit Treatment definitions in SIWENOID v2. Treatments are one of the most fundamental configuration elements in the system — they define how SIWENOID v2 interprets and categorises every signal received from every connected subsystem.

When a connected subsystem (such as a fire alarm panel or intrusion panel) sends a signal to SIWENOID v2, the signal carries a raw status code from the hardware. A treatment is the SIWENOID v2 configuration record that maps this raw status code to a meaningful, human-readable state with defined visual and operational behaviour.

Each treatment definition specifies:

• The status name — the label displayed to operators in the signal log, event log, and datapoint hierarchy (for example: “Alarm”, “Fault”, “Pre-alarm”, “Excluded”, “Normal”).
• The event category — which category this status belongs to, which determines its colour coding, icon style, and how it is counted in the category bar on the main screen.
• Map visibility — whether a datapoint with this status should be highlighted on maps, and if so, with which icon and colour.
• The effect mask — which incoming signal bits or status codes from the subsystem protocol cause the datapoint to enter this treatment state.

Treatments are defined per datapoint type within each handler type (subsystem driver). Different device types have different possible treatments because different hardware reports different status conditions.

Important: Treatment editing is a low-level engineering operation that directly affects how SIWENOID v2 interprets signals from physical security systems. Incorrect treatment configuration can cause alarms to be misclassified, missed, or displayed incorrectly. Treatment editing should only be performed by experienced commissioning engineers who understand the protocol of the connected subsystem. Commands within treatments can only be configured in accordance with the subsystem communication protocol specification.

—

Prev ← Logical Containers Next → Creating Categories

The first way to access treatment editing is through the main settings menu. Navigate to File → Settings → Treatment Types.

The Treatment Types settings screen is organised into three selection panels:

• Handlertypes / Containers — the top-level list showing all configured subsystem drivers. Each entry corresponds to a connected subsystem type, such as a specific fire panel model or intrusion panel driver. Select the handler type whose treatments you want to inspect or edit.
• Datapoint types — after selecting a handler type, this panel shows all datapoint types that exist within that handler (for example: Panel, Zone, Detector, Output, Loop). Select the datapoint type whose treatments you want to edit.
• Treatments / Commands — after selecting a datapoint type, this panel lists all treatment definitions for that datapoint type. Select a treatment to open its editor on the right side of the screen.

This method is recommended when reviewing or editing treatments across multiple datapoint types within the same subsystem, or when performing a systematic review of all treatment definitions for a handler.

The second way to access treatment editing is directly from the Datapoint Hierarchy screen. This method is faster when you want to edit the treatment of a specific datapoint you have already located in the tree.

1. Open the Datapoint Hierarchy tab.
2. Navigate to the datapoint whose treatment you want to edit.
3. In the Treatments panel on the right side, right-click the treatment row you want to edit.
4. Select Edit treatment from the context menu. The other available option is Simulate, which triggers that treatment state on the datapoint for testing purposes without a real signal from the panel.

The same treatment editor screen opens as in Method 1, but with the handler type, datapoint type, and treatment already pre-selected based on the datapoint you right-clicked. This saves the navigation steps required in Method 1.

The treatment editor displays all configurable properties of a treatment. The main fields are described below.

Name fields (English name, Hungarian name, and other languages)
SIWENOID v2 supports multilingual status names. Each language has its own name field — English name, Hungarian name, Czech name, Russian name, Bulgarian name, and Romanian name. The name entered in the active interface language is the one displayed to operators in the signal log, event log, and datapoint hierarchy. Enter the status label that operators will see in the relevant language field. For example, the default English name “Fault” could be changed to “Technical fault” or “Line error” for clarity.

Category
The event category that this treatment belongs to. The category determines the colour, icon, and priority level used to represent this status throughout the entire SIWENOID v2 interface — signal log colour coding, category bar counts, map icon highlighting, and audio behaviour. The available categories are NORMAL, ALARM, PREALARM, WARNING, FAULT, EXCLUSION, DISORDER, and INFORMATION.

Additional behaviour settings
The editor also contains a set of checkboxes and options that control how the treatment behaves in the interface:

• Show on Map — whether the datapoint's map icon changes when this treatment is active.
• Show in Signal Log — whether events with this treatment appear in the signal log.
• Bring Client window — whether an active event with this treatment brings the SIWENOID client window to the foreground automatically.
• Loggable — whether events with this treatment are recorded in the event log.
• Removable — whether the event can leave the signal log once the condition clears.
• Blinking — whether the map icon blinks when this treatment is active.
• Acknowledge automatically — whether the event is acknowledged automatically without operator action.
• Default Command — the command pre-assigned as the default action for this treatment.

Effect mask
The effect mask defines which raw signal bits or status codes received from the subsystem protocol cause a datapoint to enter this treatment state. Only the bits that should trigger this specific treatment should be ticked. The effect mask must be configured strictly according to the communication protocol specification of the connected subsystem. Do not modify the effect mask without referring to the protocol documentation for the specific subsystem driver being configured.

1. Open the treatment editor using either method described above.
2. Locate the name field for the relevant language — for example English name.
3. Clear the existing name and type the new name.
4. Click Save.

The new name takes effect immediately across the entire interface. Existing historical events in the event log are not renamed retroactively.

Changing a treatment's category reclassifies that signal condition system-wide. All future events of this type will appear under the new category with its colour, priority, and audio behaviour.

1. Locate the datapoint in the Datapoint Hierarchy.
2. In the Treatments panel on the right, right-click the treatment row you want to reclassify.
3. Select Edit treatment. The treatment editor opens with this treatment pre-selected.
4. Click the Category dropdown and select the new category.
5. Click Save.

Example: A manual call point switched to OFF generates a SUPERVISORY signal, which by default belongs to the EXCLUSION category. If the site's security policy requires that a manually excluded call point receives higher operator attention, the engineer can reclassify this treatment to WARNING. After saving, the next time a manual call point is switched OFF, its event will appear in the signal log under WARNING — with the WARNING colour, icon, and audio behaviour — instead of EXCLUSION.

After making category changes, always verify the result by generating a test signal from the affected datapoint and confirming that the event appears in the correct category in the signal log. Remember to undo test changes if they were made only for verification purposes.

Treatment editing is typically needed in the following situations:

• Renaming statuses — to use site-specific or operator-familiar terminology instead of the default technical status names from the driver.
• Reclassifying a status to a different category — for example, escalating a tamper condition from “Fault” category to “Alarm” category to ensure it receives the same operator attention as a real alarm.
• Enabling or disabling map display — to control which statuses cause visual changes on maps.
• Correcting a misconfigured effect mask — if signals from a subsystem are being misinterpreted, the effect mask of the relevant treatment may need adjustment in consultation with the subsystem protocol specification.

Treatment definitions are part of the SIWENOID v2 database and are included in database backups. After modifying treatments, it is recommended to test the changes by generating test signals from the connected subsystem and verifying that SIWENOID v2 responds with the correct status classifications.

—

Prev ← Logical Containers Next → Creating Categories