System Preferences and Engineering Options

This page provides an overview of all configuration sections available in the SIWENOID v2 Settings menu. Every system setting is accessible from File → Settings. Menu items and their submenus are visible only to users with the appropriate permissions.

The Settings menu is the central configuration area for commissioning engineers. Most sections are used during initial system setup, but some settings can also be adjusted during live operation without interrupting system monitoring.

Three navigation buttons at the top of the Settings screen assist with navigation between sections:

• 1 — Back — returns to the previously viewed settings section.
• 2 — Forward — moves to the next settings section.
• 3 — Home — returns to the Settings home screen showing all available sections.

SIWENOID v2 can be reconfigured during operation without losing monitoring functionality. Changes take effect after saving within each section.

Prev ← Everyday Operation of SIWENOID v2 Next → Object Permissions V2

The General Settings section allows configuration of automatic login for a client workstation. When auto-login is configured, the SIWENOID v2 client starts and logs in automatically with the configured user account, bypassing the login screen entirely.

This is appropriate for dedicated operator workstations — for example, a security guard's dispatch desk where a single shared operator account is always in use. It eliminates the need for guards to log in at the start of each shift.

To switch to a different user account when auto-login is active (for example, to perform administrative tasks), select File → Switch User from the main menu. This presents the normal login screen without requiring a full application restart.

It is not recommended to configure auto-login with an administrator account. Auto-login accounts should have the minimum permissions required for normal operational duties.

Auto-login passwords are stored with 1024-bit encryption.

In multi-client installations (where multiple SIWENOID v2 client workstations are connected to the same server), the acknowledgement synchronisation mode determines how acknowledgements made on one client are reflected on other clients. Three modes are available:

• Acknowledge by clients — when an event is acknowledged on one client, it is shown as acknowledged (inverted background) on all other connected clients. This ensures no client misses any event regardless of which operator acknowledged it first.
• User-synchronised acknowledgement — acknowledgements are synchronised only between clients that are logged in with the same username. If two operators share a username, any acknowledgement by either is reflected on both. Clients logged in with different usernames are not affected.
• Synchronised acknowledgement — all clients, regardless of which user is logged in, always show the same signal log state. Any acknowledgement on any client is immediately reflected everywhere.

The appropriate mode depends on the site's operational procedures and staffing model.

The Appearance Settings section has three tabs: General Settings, Map Settings, and Datapoint Hierarchy. Each tab controls a different aspect of the client interface layout and display.

This tab contains three groups of settings:

Window Positions
The Reset Window States button resets all open windows and panels to their default positions. Use this when windows have been moved off-screen — for example, after removing a second monitor from a multi-monitor setup — and cannot be located or recovered by dragging.

Automatic map opening place selector
Selects which workspace panel is used when SIWENOID v2 automatically opens a map in response to an event (configured in Tasks). The selector displays a schematic of the SIWENOID workspace with radio buttons representing the available panel positions. Click the radio button that corresponds to the panel where automatic map displays should appear. This ensures maps triggered by alarms always open in a predictable, visible location on the operator screen rather than opening behind other panels.

Camera videos position
Selects which workspace panel is used when SIWENOID v2 automatically displays a camera video feed in response to an event. Uses the same panel position selector as the map opening selector above. Set this to a panel that is permanently visible on the operator's screen and does not overlap with the signal log.

Automatic intervention text opening place selector
Selects which workspace panel is used when SIWENOID v2 automatically displays an intervention text in response to an event. Uses the same panel position selector. Set this to a panel that is always visible to the operator so that intervention instructions are immediately readable when an event arrives.

Click Save after making changes to any setting on this tab.

This tab controls which information is displayed in the tooltip that appears when an operator hovers the mouse cursor over a datapoint icon on a map. Check each item that should be visible in the tooltip. Available options typically include: datapoint name, physical container name, current status, and datapoint type.

Configure the tooltip to show the information most useful to operators at this site — enough context to identify the datapoint and understand its current state without requiring navigation to the hierarchy screen.

Click Save after making changes.

This tab controls the appearance of text lines in the Datapoint Hierarchy panel, including font size and display density. Adjust these settings to match the screen resolution and viewing distance of the operator workstations.

Click Save after making changes.

The Security Settings section controls access restrictions for critical server operations. The most important setting here is the option to require administrator credentials before the SIWENOID v2 server can be shut down or restarted.

Enabling this option is strongly recommended for production installations. It prevents unauthorised or accidental server shutdowns by operators who have physical access to the server machine but do not hold administrator accounts in SIWENOID v2.

SIWENOID v2 plays audio alerts on client workstations when new unacknowledged events arrive. Sound alerts require a functioning sound card and connected speakers on the client computer. Sound settings are configured per client.

• 1 — Main volume — the master volume level for all SIWENOID v2 sounds relative to the operating system's volume. All individual category volumes are proportional to this master setting. If the main volume is set to zero, all sounds are muted regardless of individual category settings.
• 2 — Enable sounds — master on/off toggle for all sounds in the software. Disabling sounds is not recommended for operational installations as it removes all audio alerting.
• 3 — Volume per event category — each event category has its own volume slider. Different categories can use different volume levels — for example, fire alarm sounds can be set louder than fault sounds.
• 4 — Mute per event category — individual categories can be muted without affecting others. For example, the Exclusion category can be muted during maintenance periods when many detectors are excluded and the constant audio alert would be disruptive. Alarm categories should never be muted.
• 5 — Loop — when enabled, the sound alert for a category repeats continuously until the event is acknowledged. When disabled, the sound plays once per event. Loop mode is strongly recommended for alarm categories to ensure operators cannot miss an alarm even if they are briefly away from the workstation.
• 6 — Preview — plays the configured sound for the selected category so the engineer can verify the audio before saving.

The Map Settings section is the central management screen for all maps in the system.

• 1 — Datapoint assignments — shows all datapoints assigned to the currently selected map. Unchecking a datapoint removes its assignment from the map — it will no longer appear on that map or trigger that map to open automatically on alarm.
• 2 — Map list — lists all maps in the system, organised by map groups if groups have been created. Right-click a map name to rename it.
• 3 — Add / delete map or map group — use the + button to create a new map or map group. Use the - button to delete the selected map.
• 4 — Save button — saves all changes made in the Map Settings screen.

Map groups organise maps by location or building for easier navigation in installations with many maps.

1. Click the + button and select Create new map group.
2. Right-click the new group item and select Rename group.
3. Type the desired name and press Enter.

Note: map groups can only be created from the Map Settings menu, not from the main workspace.

New maps can be created from the main workspace (click + in any panel and select Map → New map) or from the Map Settings menu. The procedure is the same in both cases.

1. 1 — Drag the map image file (JPEG, JPG, or PNG) from the computer onto the map canvas area.
2. 2 — Enter a name for the map (for example: “First Floor Blueprint”, “Parking Level B1”).
3. 3 — Optionally select a map group to organise this map.
4. 4 — Click Save. The Save button becomes active only when both a name and an image file have been provided.
5. 5 — The map is only editable when the Editable checkbox is checked. Always enable this before placing datapoints, and disable it after editing is complete.

Open the Datapoint Hierarchy in one workspace panel and the target map (in edit mode) in an adjacent panel. Drag the datapoint from the hierarchy tree and drop it onto the correct position on the map canvas. Click Save after placing all datapoints. Changes are lost if the map is closed without saving.

1. Open File → Settings → Map Settings.
2. Select the map to be deleted from the map list.
3. Click the - button in the lower left corner.
4. Confirm deletion in the confirmation dialog by clicking OK, or click Cancel to abort.

The Physical Structure section is where all connected security subsystems are configured. Each subsystem entry represents one physical control panel that SIWENOID v2 communicates with — for example, a SIEMENS fire alarm panel, a Bosch intrusion panel, or a Honeywell access control system. These are called physical containers.

When a physical container is created, the engineer sets the communication parameters required to reach that panel: IP address, port number, protocol version, and any other handler-specific connection settings. SIWENOID v2 then communicates with the panel using those parameters.

Datapoint import: The datapoints configured inside the physical panel are not entered manually into SIWENOID v2. Instead, they are imported via an export file produced by the panel vendor's own configuration tool. Depending on the panel manufacturer, this export file may be in XML, CSV, or TXT format. When the file is imported, SIWENOID v2 builds a tree structure of nodes under the physical container — mirroring the panel's internal organisation of zones, detectors, outputs, and other datapoint types.

Once the import is complete and communication is enabled, SIWENOID v2 operates in text mode with that panel: signals from the panel appear in the signal log, and commands can be sent back to the panel from the SIWENOID v2 interface.

Physical vs logical structure: The physical container and its imported tree represent the hardware reality — the actual panel and its datapoints as the manufacturer defined them. This structure should not be manually reorganised. Logical containers (configured separately) allow the engineer to create a user-defined reorganisation of datapoints across one or more physical containers — for example, grouping all detectors on the second floor regardless of which panel they belong to. See Logical Containers for details.

• 1 — Add button — adds a new physical container (subsystem) to the physical structure. After clicking, select the handler type for the subsystem from the dropdown and fill in the communication parameters.
• 2 — Delete button — removes the selected physical container from SIWENOID v2. This removes all associated datapoints, map assignments, event history references, and task triggers. Use with caution — this action cannot be undone without restoring from backup.
• 3 — List of physical containers — lists all configured subsystems. Click a subsystem name to view or edit its settings.
• 4 — General settings panel — displays the configuration fields for the selected physical container. The available fields depend on the handler type — each subsystem driver has its own specific communication parameters (IP address, port, COM port, baud rate, protocol version, etc.).
• 5 — Communication toggle — enables or disables live communication with the selected subsystem. When disabled, SIWENOID v2 stops sending and receiving data to and from that panel. Use this during maintenance to temporarily disconnect a subsystem without removing its configuration. Communication must be enabled on all subsystems for a fully operational installation.
• 6 — Save button — saves changes to the subsystem configuration.

The second tab in the physical structure window shows which maps the selected datapoint is assigned to. Check or uncheck maps to add or remove assignments.

A datapoint can be assigned to a map without being visually placed on its canvas — this causes the map to open automatically when the datapoint generates an alert, even if the datapoint icon is not visible on the map. This is useful for overview maps where individual datapoints are not individually represented but a high-level area map should open on any alert from that area.

The third tab in the physical structure window lists all intervention texts defined in the system. Check the intervention texts to be assigned to the selected datapoint. Multiple intervention texts can be assigned to a single datapoint, and the same intervention text can be assigned to multiple datapoints.

Intervention texts are defined in File → Settings → Intervention. Assignment to datapoints is done here in the Physical Structure section.

The Types menu provides access to the low-level treatment and command definitions for all subsystem drivers. It is organised as a four-level hierarchy:

Handler type → Datapoint types → Treatments and commands → Editor panel

• 1 — Handler types — lists all subsystem drivers registered in the system.
• 2 — Datapoint types — lists all datapoint types for the selected handler (for example: Panel, Zone, Detector, Output).
• 3 — Treatments and commands — lists all treatments (status definitions) and commands for the selected datapoint type.
• 4 — Editor panel — displays the editable properties of the selected treatment or command.
• 5 — Add handler — registers a new subsystem driver type in the system.
• 6 — Delete handler — removes the selected handler type.
• 7 — Add datapoint type — manually adds a new datapoint type to the selected handler.
• 8 — Delete datapoint type — removes the selected datapoint type.
• 9 — Add treatment or command — creates a new treatment or command definition for the selected datapoint type.
• 10 — Delete treatment or command — removes the selected treatment or command.

• 1 — Language settings — the treatment status name can be defined in each language supported by the system. The name displayed to operators matches their configured interface language.
• 2 — Event category — assigns this treatment to an event category. This determines colour coding, icon, sound, and priority throughout the interface. Example: the SPC Panel “Tamper” treatment is assigned to the “Alarm” category.
• 3 — Custom colour — optionally overrides the category colour for this specific treatment. The treatment remains in its assigned category; only the background colour in the signal and event log changes. Use sparingly — applying non-standard colours to treatments can cause operator confusion.
• 4 — Viewable on map — when checked, datapoints displaying this treatment are highlighted on maps. When unchecked, the datapoint icon does not change on maps when this treatment is active.

• 5 — Loggable — when checked, events with this treatment are recorded in the event log. It is strongly recommended not to change this setting.
• 6 — Removable — when checked, events with this treatment can be deleted from the event log. It is strongly recommended not to change this setting.
• 7 — Default command — the command automatically offered as the default action button in the signal log for events of this treatment type.
• 8 — Protocol settings — low-level bit mask and protocol fields that must be configured strictly in accordance with the subsystem communication protocol specification. Do not modify without the protocol documentation.
• 12 — Save button — saves all changes to the treatment definition.

• 1 — Icon and name — the visual icon and display name of the command.
• 2 — Language settings — the command name in each supported interface language.
• 3 — Type — the command type classification.
• 4 — Protocol settings — the low-level protocol parameters for this command. Must be configured according to the subsystem protocol specification.
• 7 — Save button — saves changes to the command definition.

See the Creating Categories page for full details. This screen is the same categories editor accessible from the main Settings menu. Key elements:

• 1 — Category list — all event categories in the system. The selected category is highlighted.
• 2 — Add / remove category — the + button creates a new category. The - button deletes the selected category. Default system categories cannot be deleted.
• 3 — Icon — the icon displayed in the signal log for this category. Click to replace with a PNG file. The system resizes the image automatically.
• 4 — Assigned sound file — the WAV file played when a new event of this category arrives.
• 5 — Select sound file — opens a file picker to select a WAV file for this category.
• 6 — Preview — plays the selected sound file for verification.
• 7 — Category name — the display name in all supported interface languages.
• 8 — Category colour — the background colour used for this category throughout the interface.
• 9 — Can be hidden — when checked, operators can hide this category from the signal log by clicking its name in the categories bar.
• 10 — Dedicated to workspace — when set, events of this category are displayed in a dedicated workspace panel rather than the main signal log.
• 11 — Save button — saves all changes.

Object restrictions allow specific datapoints, treatments, and commands to be hidden from users on a per-object basis. Once a datapoint, treatment, or command is added to any restriction rule, it becomes visible and accessible only to the users or groups explicitly listed in that rule.

This makes the operator interface cleaner and more focused for security guards and monitoring staff who should not have access to engineering-level commands or datapoints outside their area of responsibility. See the Object Permissions V2 page for full configuration details.

Forced actions are mandatory operator tasks that must be completed before an event can be acknowledged. When a configured event arrives in the signal log, the operator is presented with a form they must fill in before the acknowledgement is accepted.

Example: a fire alarm event can be configured to require the operator to select what action was taken (checked area, called fire brigade, false alarm) before the event can be acknowledged. The completed form is saved in the event log.

See the Creating Forced Actions page for full configuration details.

Intervention texts are predefined instructions or procedures that appear automatically (or on demand) when a datapoint signals an event. They guide operators through the correct response procedure for that specific datapoint or event type.

• 1 — List of intervention texts — all defined intervention texts. Click to select and display the text in the editor.
• 2 — Add new text — creates a new intervention text entry.
• 3 — Delete selected — deletes the selected intervention text. Any datapoint assignments for this text are also removed.
• 4 — Text editor tab — the tab where the content of the intervention text is written or imported.
• 5 — Datapoint assignment tab — shows which datapoints have this intervention text assigned.
• 6 — Name — the internal name of the intervention text. Use clear, descriptive names so engineers can identify texts without reading their content.
• 7 — Import from file — imports the text content from a TXT or HTML file on the local computer.
• 8 — Import from URL — fetches the text content from a URL. SIWENOID v2 stores the text locally and checks for updates when the URL is accessible. This allows centrally managed intervention texts on a local web server. Note: SIWENOID v2 often operates on closed networks where internet URLs are not reachable. Local intranet web servers are fully supported.
• 9 — WYSIWYG text editor — a formatted text editor for writing intervention texts directly, with support for headers, fonts, and basic formatting.
• 10 — Editing area — the content editing canvas.
• 11 — Save button — saves changes.

The datapoint assignment tab shows which datapoints currently have this intervention text assigned. New datapoints can be assigned by dragging them from the Datapoint Hierarchy panel onto this tab.

To remove a datapoint assignment, uncheck the mark next to the datapoint name and click Save.

The Safety Backup section provides manual backup functionality for the SIWENOID v2 client and server applications and their databases.

• 1 — Select components to back up — check the client and server components to include in the backup. In a standard single-machine installation, both should always be backed up together.
• 2 — Browse — select the destination folder and filename for the backup archive.
• 3 — Start — begins the backup process. Progress bars indicate the current state.

Important backup guidelines:

• SIWENOID v2 remains fully operational during the backup process. Monitoring is not interrupted.
• On larger installations (several thousand datapoints, months of event log history), the backup process can take several hours. Schedule backups during periods of expected low activity.
• The backup file size depends on the number of datapoints and the length of the event log. Installations with thousands of datapoints and months of history can produce backups of several gigabytes.
• Never store backups on the same physical machine as the SIWENOID v2 installation. A hardware failure that affects the server will also destroy locally stored backups. Store backups on a separate machine, network share, or removable storage.
• Create a backup before connecting any new subsystem and before making any significant configuration changes.
• Back up after any software or hardware error has been resolved and the system is restored to normal operation.

• 1 — Acknowledgement logging — when enabled, SIWENOID v2 logs every acknowledgement action in the event log in addition to the events themselves. This provides a complete audit trail of operator actions. Note: on large busy installations, enabling acknowledgement logging significantly increases the size of the event log database over time.
• 2 — Special colours — configures the background colours used in the event log for entry types that are not generated by datapoint status changes:
  • Colour 1 — commands sent to subsystems.
  • Colour 2 — user-generated events.
  • Colour 3 — comments added to events.
  • Colour 4 — acknowledgement log entries (when acknowledgement logging is enabled).

The Tasks section is where automatic actions are configured. Tasks execute automatically when defined event categories receive new events. Supported automatic actions include: automatic map opening, SMS sending, email sending, and intervention text display.

To create a task:

1. Click the + button to create a new task entry.
2. Select the action type from the dropdown menu (for example: Open map, Send SMS, Send email).
3. Select the event categories that will trigger this task.
4. Click Save.

See the Creating Tasks page for full configuration details.

The Users and Groups section is where operator and engineer accounts are created and managed. From this screen, new users can be added, existing users edited, and language and permission settings configured for each account.

Each user account has a General tab for basic account information and a Permissions tab for fine-grained access control. The permissions tab allows individual functions to be granted, denied, or inherited from a group for the selected user. Users can be restricted to prevent unauthorised changes to system configuration.

If the administrator option is enabled for a user, that account has full access to all settings and configuration screens.

See the User Permissions V2 page for full configuration details.

The Logical Containers section lists all logical containers defined in the system and allows them to be created, renamed, and deleted. See the Logical Containers page for full details.

The Modules section is where communication modules for outgoing notifications are configured. Modules enable SIWENOID v2 to send SMS messages (via a connected GSM modem) and emails (via an SMTP server) in response to events. A valid SIM card in a connected GSM device is required for SMS notifications.

See the Creating Module page for full configuration details.

Prev ← Everyday Operation of SIWENOID v2 Next → Object Permissions V2