Everyday operation of Siwenoid v2

After starting the software we can see the default screen of Siwenoid (→ The starting screen of Siwenoid)
On everyday operation this screen is what we use most frequently.

On the top of the screen we can see all categories in which every signal from the subsystems are arranged into. The colors of the categories are matched to the colors of the Signal log.

• The bar of the event categories are not part of the Signal log but it makes the use of it easier.
• The event categories are always visible and cannot be hidden no mater what window arangement we use.
• Straight forward colors: On the maps, in the event and signal log we see the colors of the event categories. So we can know that every text with red background is about alarms.
  

1. Event categories

• All signals, events, alerts from the subsystems are arranged into these categories.
  
• “NORMAL” status is not shown in the bar of event categories since it is never shown in the signal log.
  
• Normal status is everything when the datapoint is operational and capable of communicating, like an activated smoke detector, an armed intrusion zone etc.
  

2. Hidden event category

• We can hide signals from a specific category by clicking on its name. On this case every signal from the selected category are hidden from the signal log.
• The background of the hidden categories are transparent.
• We cannot hide the “ALARM” category.
• When servicing a fire alarm unit many detectors can be “Excluded”. This can interfere the visibility of the signal log.
  

3. Bulk acknowledge button

• By clicking on this button every new event in this category is “acknowledged” in the software.
• The button doesn't send commands to the subsystems but only registers in the software that the events were noticed by the user.
• Many detectors of one connected system can signal simultaneously, for example all detectors of a deactivated zone. In the software these can be acknowledged by one click.

4. Acknowledge / Not acknowledged events

• Indicating number that shows how many events we have in the category and how many of them are acknowledged.
• The “0/1” Fault in the example are showing us that we have one event which already have been acknowledged in the software.

The signal log is the main indication unit of the software where the alerts and disorders are shown from the subsystems.
We rarely can see an empty signal log (shown on he picture) since a bigger site always have some disabled detectors for example.

Parts of the signal log

The signal log shows every signal coming from the integrated datapoints. All indications are color coded with the represented event's color as in the event categories. This is the primary indication interface for the users.

• Alarms (red background by default) are always shown on top of the screen so they never get lost among the list of disabled sensors.
• If the category of the event is hidden then the signals from that category aren't shown in the signal log (but they can be acknowledged from the event category buttons).
  

1) Icon of the category: The default icon of the category of the event.
2) Timestamp: The time of receiving the event.
3) Physical container: From which physical container is the signal coming from.
4) Datapoint's name: The name of the signaling datapoint
5) Description of the error: The caouse of signaling (In the example the licenced client application is not connected to the server, so the status is “CLIENT DISCONNECTED”.)
6) Status of the signal: The fresh, not yet acknowledged signals backgound is blinking.

The status of hte signal can be:

• New event (blinking line)
• Acknowledged event (not blinking line)
• Deleted event (black background, inverted text color)
  

Buttons:

7) Default command: The command we most likely want to send to the system in case of this signal.

• If by the event's type it's not clear what command should be sent then the button is disabled. Even though by right-clicking on the disabled button we can see the list of possible commands what we can send to the datapoint.
• The default command is predefined in the software based on the integrated subsystem and the type of the datapoint.

8) Show on map: If the signaling datapoint is placed on a map (green backgound on hte button shows that) we can open the corresponding map and see the datapoint by pressing the button. Tha datapoint's backgound blinks for a few times with the color of the signaling event's category.
9) Intervention text: Every datapoint can be assigned with an Intervention text what pops up every time the datapoint is signaling an event. This helps the end-users to help in the typical methods of solving events.(For example “The zone can't be re-set while the windows are open.” )
10) Write a comment: We can write comments to the events if it is necessary to document the events.(For example “Cause of disabling: maintenance”.)
11) Show in tree: If we click on this button the datapoint will be selected in the datapoint hierarchy tree.

The signals with black background can be acknowledged / hide from the signal log by one click. These are statuses what are not present by the time of viewing it in the software. So the users won't miss any events even if they had been acknowledged on a secondary client, or on the connected unit.

When can we see signals with inverted background?

• For example we don't have to send command to the fire alarm unit if the event were acknowledged on the unit itself.
• If someone on a different Siwenoid client is acknowledged the signal. (And acknowledgement by clients is setupped in Siwenoid)
  

As we seen before all events from the datapoints are shown in thesignal log. We can see a fresh alarm on the picture. The backgound of new events are blinking (and making sound signal based on settings) in the signal log.

Acknowledging alarms and signals!
The backgound of new events are blinking and the events making sound signal (based on settings).

Click on the event in the signal log!
The event is acknowledged in the software and the blinking terminates.

• If we use the bulk acknowledge button oin the event category line we can acknowledge multiple events by categories (→ The event categories)
• By this time no command is sent to the alarming central unit / sibsystem.
  

Resolve the alarm / signal
Check and resolve the event based on your job description.

Other possibilities before resetting an alarm
Before we send a reset (or other) command to the subsystem, we can:

• Show the alarm on a map.
• Write a comment to the event.
• We can check the intervention text assigned to the datapoint.
  

Sending a command to the subsystem
After we acknowledged the alarm, wrote comment to it etc. we can reset the subsystem.

• By pressing the (1) button we can send the most possibly needed command to the subsystem. This “default” command is based on the datapoin's type.
• Right clicking on the mouse we can see all possible commands what can be sent to the datapoint.
  

Showing the intervention text
The software can be set to show intervention texts automatically (if there are texts assigned to the datapoint) on specific kinds of events (like alarms, disorders etc.) If no automatical displaying setupped we can show the intervention text by clicking on button (3).

• The button is not clickable and its background is grey If there are no intervention text assigned to the datapoint.
  

Writing comment to the event
By pressing the button (4) we can write a comment to the selected event. This can be useful when reconstructing an event. Any user (with the right permissions) can write any number of comments to a single event.

1) Timestamp column: Time and date of the existing comments.
2) User: The user wrote the comment.
3) Comment: The actual comment to the event.
4) Text area: Here we can write our comment to the event.
5) Send button: The text written in the textarea (4) will be saved to the event.

• We can write more comment to a single event.
  
• The comments will be displayed by date.
  

Showing alarms on maps
Siwenoid can be setupped to display maps on case of alarms and other events. If there are no automatic display setupped we can press the button marked (2) to open the corresponding map.

If the datapoint isn't represented on any map then the button is not clickable and its background is gray.

Checking datapoint, other commands
By pressing button marked (5) we can open the datapoint hierarchy screen with the signaling datapoint selected.

The event log undeletably holds every event from the software. The content of the event log can be printed or exported in .XLSX, .CSV and interactive HTML format. We can search in the event log variously.

Search and filter in the event log
In the footer of the event log windows we can find the inputs for filtering the log. On the upper picture we can see the details.

1) Start date: The date when from we search in the event log. All events from the time 00:00:00 of the selected date will be displayed. No previous events will be displayed.(in the example its 2017.06.08, 00:00:00)
2) Ending date: The date till we search in the event log. All events till the time 23:59:59 of the selected date will be displayed. No further events will be displayed.(In the example its 2017.06.08, 23:59:59)
3) Starting time: Events what happened later than this time will be displayed (regardless of date)

• If we haven't setupped starting or ending date then all events from every day will be displayed what happened later than the set time.

4) Ending time: The time till we search in the event log. All events till this time will be displayed (regardless of the date).

• The exapmple shows events from the date 2017-06-08 and between 10:00 and 15:00 o'clock.
• If we don't setup dates just times, then we will get a filtered result from every day between the set times.
  

5) Event type: We can search for the type of the event(In the example we searched for “alar” so we got all “ALARM” type events. (in the previously set time interval)
6) Load saved filter: If we saved a filtering option-set we can call them out from here.
7) Saving the actual filtering options: If we regularly want to check the filters we just setupped we can save the options by this button (6).

• If we click on this button a confirmation window will pop up asking us to name the filter. After we set the name we shoul press enter to save it.
• For example we can save a filtering for all “ALARM” type events in every day from 06:00 to 09:00 as “alarms in the morning”.
  

8) Deleting saved filter: The button is clickable if we already loaded a previously saved filter with the pulldown menu of button (6). By pressing the button we are deleting the selected filter.
9) Datapoints: Here we can search by the names of the signaling datapoints (sensors etc.). In the example by the search term “p” we got 2 datapoints: “PIR 1” and “Panic Button” (with all other filtering options setupped previously)
10) Event: The events can be various even if they are in the same event category (5). Here we can search for the type of the events like “Communication disabled”, “Client connected” or “Alarm” etc.

• Thease are the treatments (statuses) what can obtained by the datapoints. (→ Datapoint hierarchy / signal statuses → Preferences menu / types)

11) Exporting the filtered list: The (filtered) list shown on the screen can be exported by pressing this button. We can export the list to CSV, XLSX and (interactive, filterable) HTML format.

• The list only can be exported when there are start and finish dates are set (1), (2).
• This is necessery because on a bigger system the event log can be consist of multiple million lines. Please consider the environment before printing out the log.

12) Printing the filtered list: The (filtered) list shown on the screen can be printed onto the default printer (setupped in the menu → preferences / printers).
13) Resetting filters: By pressing he button all filtering will return to default (empty) state. After clicking the button the event log will be fully displayed, without any filtering.
14) Example: In the example we can see all events at 2016-06-08 between 10:00 and 15:00 o'clock which contains the characters “alar” from all datapoints with name containing “p”. We found 2 events like that.

Broader search / “OR” search
If we write more words into the search fields (separated by space) then all events will be displayed what consists the one OR the other word. (For example if we search for the text “Alarm Normal” then we will see all alarm OR normal status in the filtered results.)

Narrow search / “AND” search
If we search for multiple words but we divide them with the symbol “&” then only those events will be displayed wich are containing BOTH the keywords. (If we augment the previous search to “Alarm & Normal” then we will get an empty result list because its hardly possible to find events what are in normal AND in alarm status at the same time)

On clicking the button number (11) on the previous picture we can select what format we would like to export (CSV, XLSX or HTML).

Select an option suits our needs.
After clicking the button we can select the name and place of the file. Click on the “save” button to save the exported list.
If we changed our mind we can cancel the saving by pressing the “cancel” button.

• Attention! The filtered list only can be exported (the button is only clickable) if there are starting and ending date set (1) and (2). It is necessery becouse on a bigger system the event log can be several million lines.
  

Printing the event log
With the button (12) we can print out the filtered event log.

• To print the event log it is also necessary to setup a default printer in the preferences menu.
• Attention! The filtered list only can be printed (the button is only clickable) if there are starting and ending date set (1) and (2). It is necessery becouse on a bigger system the event log can be several million lines.
• Always consider the environment before printing out the event log.
  

Previous → Creating Module

Next → System preferences and engineering options v2