Everyday operation of Siwenoid: Difference between revisions

From Siwenoid Wiki
Jump to navigation Jump to search
(Created page with "{{Languages|Everyday operation of Siwenoid}} = Everyday operation of Siwenoid = After starting the software we can see the default screen of Siwenoid (→ The starting scr...")
 
No edit summary
 
(4 intermediate revisions by the same user not shown)
Line 10: Line 10:


=== 1) The event categories bar ===
=== 1) The event categories bar ===


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.
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.
Line 17: Line 16:
*The event categories are always visible and cannot be hidden no mater what window arangement we use.
*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.
*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.
<br style="clear: both" />
 
[[Image:Event_Category_1.jpeg|left|thumb|800px]]  
[[Image:Event_Category_1.jpeg|left|thumb|800px]]  
<br style="clear: both" />
<br style="clear: both" />


* ''' 1; Event categories'''   
* ''' 1; Event categories'''   
Line 42: Line 40:




* ''' 3; Bulk acknowledge button '''
-By clicking on this button every new event in this category is "acknowledged" in the software.
<br style="clear: both" />


->The button doesn't send commands to the subsystems but only registers in the software that the events were noticed by the user.
<br style="clear: both" />


* ''' 3; Currently selected datapoint. '''  - Shown in its place of the hierarchy.
-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; Acknowledged / Not acknowledged events '''
-Indicating number that shows how many events we have in the category and how many of them are acknowledged.


* ''' 4; Commands '''  - The commands what can be send to the datapoint are shown here. You can send commands directly to the system by clicking on the command's icon.
-The "1/1" in the example are showing us that we have one event which already have been acknowledged in the software.




=== 2) Parts, details and usage of the Signal log ===


* ''' 5; Commands '''  - All events from the last 24 hours for the selected datapoint are shown here. (This is a filtered extract of the event log and only contain events for the one selected datapoint.)
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.


[[Image:Empty_log_1_1.jpeg|left|thumb|800px]]
<br style="clear: both" />
''' 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).


<br style="clear: both" />
[[Image:Signal_log_1_1.jpeg|left|thumb|800px]]
<br style="clear: both" />


=== 2) Parts of the main screen ===
'''1; Icon of the category: '''    The default icon of the category of the event.
<br style="clear: both" />
'''2; Timestamp: '''              The time of receiving the event.
<br style="clear: both" />
'''3; Physical container: '''      From which physical container is the signal coming from.
<br style="clear: both" />
'''4; Datapoint's name: '''        The name of the signaling datapoint
<br style="clear: both" />
'''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".)
<br style="clear: both" />
'''6; Status of the signal: '''    The fresh, not yet acknowledged signals backgound is blinking.
<br style="clear: both" />
 
The status of hte signal can be:


* '''Attention!''' In Siwenoid every displayed item and view is bound to permissions. A user with fewer permissions can see fewer option than we show here in the manual.
*New event (blinking line)
*Although the signal log and especially the alarms cannot be hidden from any user.
*Acknowledged event (not blinking line)
*Deleted event (black background, inverted text color)


                                                  Parts of the main Screen!
 
 
'''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.
<br style="clear: both" />
'''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."
)
<br style="clear: both" />
'''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".)
<br style="clear: both" />
'''11; Show in tree: ''' If we click on this button the datapoint will be selected in the datapoint hierarchy tree.
<br style="clear: both" />
 
 
=== 3) Deleted events: events with black background ===
 
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.
 
[[Image:Jelzesnaplo_elemei_inverz.jpeg|left|thumb|800px]]
<br style="clear: both" />
'''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)
<br style="clear: both" />
=== 4) Detecting and handling alarms from central units and datapoints ===
 
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.
<br style="clear: both" />
<br style="clear: both" />
[[Image:Installer_v2_telepitesvege11.jpeg|left|thumb|800px]]  
[[Image:Alarm_03.jpeg|left|thumb|600px]]
<br style="clear: both" />
<br style="clear: both" />


* ''' 1; Main menu '''                         - The settings of the system can be accessed here.
'''Acknowledging alarms and signals!'''
 
 
The backgound of new events are blinking and the events making sound signal (based on settings).
 


* ''' 2; Event categories '''                 - The signals and alerts from the connected subsystems all fall into one of these categories. (More in the chapter "Setting up")
'''Click on the event in the signal log!'''


* ''' 3; Main windows '''                      - Under the main tabs we can find the signal log, the datapoint structure and the event log. We also can define our own tabs with maps (for example).
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.


  Default tabs:
    ->Signal log - the alerts and other events are shown here.
    ->Datapoint hierarchy - here we can oversee the connected systems in a multi-level tree view
    ->Event log - the software logs every alert and action. We can check and search in the previous events here.


* ''' 4; Parts of the signal log '''           - The most important view of the software since all signals, events and alerts are shown here what the transmitters ("datapoints") of the connected subsystems are sending.
'''Resolve the alarm / signal'''  


We can see every datapoint's status here where the status is different from "normal" (alarms, exclusions, line erros etc).
Check and resolve the event based on your job description.


* ''' 5; Bulk acknowledge buttons '''          - With these we can acknowledge every alert in the corresponding category (This is ackknowledgement in the software only, no commands are sent to the security systems).


'''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'''


=== 3) The workplaces of the main screen ===
After we acknowledged the alarm, wrote comment to it etc. we can reset the subsystem.
<br style="clear: both" />
*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.
[[Image:Ablakok_helyei_%27.jpeg|left|thumb|800px]]
*Right clicking on the mouse we can see all possible commands what can be sent to the datapoint.


<br style="clear: both" />


We can arrange 4 workspace on the main screen by dragging their side. On these workplaces we can arrange views of the application as we like.
'''Showing the intervention text'''


''' Tabs what can be shown on the workplaces '''
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.


Onto these 4 place we can open different application views with the "+" button on top.


'''Writing comment to the event'''


These can be:
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.


-Signal log
<br style="clear: both" />
<br style="clear: both" />
-Datapoint hierarchy screen
[[Image:Alarm_note_1.jpeg|left|thumb|600px]]
<br style="clear: both" />
<br style="clear: both" />
-Event log
'''1; Timestamp column: '''          Time and date of the existing comments.
<br style="clear: both" />
<br style="clear: both" />
-Any map
'''2; User: '''                      The user wrote the comment.
<br style="clear: both" />
<br style="clear: both" />
-Logical containers (Sub-trees of the datapoint hierarchy)
'''3; Comment: '''                  The actual comment to the event.
<br style="clear: both" />
'''4; Text area: '''                Here we can write our comment to the event.
<br style="clear: both" />
'''5; Send button: '''              The text written in the textarea (4) will be saved to the event.
<br style="clear: both" />
*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.
<br style="clear: both" />
[[Image:Alarm_03_1.jpeg|left|thumb|600px]]
<br style="clear: both" />
*If the datapoint isn't represented on any map then the button is not clickable and its background is gray.


The intervention texts for events also opened on the workplace prevoiusly setupped for it.


'''Checking datapoint, other commands


 
By pressing button marked (5) we can open the datapoint hierarchy screen with the signaling datapoint selected.
=== 4) Overview of the datapoint hierarchy screen ===
 
 
== 5) Usage of the event log ==
 
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.
<br style="clear: both" />
[[Image:Eventlog_filter_1.jpeg|left|thumb|800px]]
<br style="clear: both" />
<br style="clear: both" />
The Datapoint hierarchy scree shows the physical and logical containers of datapoints in a hierarchical tree view. All important details (→1,2,4,5) of the currently selected datapoint (→3) are shown.


The datapoint hierarchy screen have 4 different sections. The left side shows the logical and physical tree of the datapoints.
'''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)
<br style="clear: both" />
'''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)
<br style="clear: both" />
'''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)
<br style="clear: both" />
'''6, Load saved filter: '''                      If we saved a filtering option-set we can call them out from here.
<br style="clear: both" />
'''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).


The right side of the panel if split into 3 sections.
*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.
<br style="clear: both" />
'''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)
<br style="clear: both" />
'''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).
<br style="clear: both" />
'''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.
<br style="clear: both" />
'''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.
<br style="clear: both" />
<br style="clear: both" />


[[Image:Hierarchy_v2.jpeg|left|thumb|800px]]
=== 6) Special filtering options (AND / OR search) ===
<br style="clear: both" />
 


* ''' 1; Datapoint informations '''     - The tecnical name (what is inherited from its physical container), the type and the name of the physical container of the datapoint is shown here.(These informations are necessery since the datapoints can be renamed in the software and can be moved to logical containers.)
''' Broader search / "OR" search '''


* ''' 2; Treatments (statuses) '''    - The possible statuses of the selected datapoints can be seen here. The current status of the datapoint is highlighted (except "Normal").
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.)


* ''' 3; Currently selected datapoint. '''  - Shown in its place of the hierarchy.


* ''' 4; Commands '''   - The commands what can be send to the datapoint are shown here. You can send commands directly to the system by clicking on the command's icon.
'''Narrow search / "AND" search'''


* ''' 5; Commands '''  - All events from the last 24 hours for the selected datapoint are shown here. (This is a filtered extract of the event log and only contain events for the one selected datapoint.)
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)


=== 7) Exporting the event list to XLSX, CSV or interactive HTML file ===


=== 5) The event log ===
*On clicking the button number (11) on the previous picture we can select what format we would like to export (CSV, XLSX or HTML).
[[Image:Export_v2_01.jpeg|left|thumb|800px]]
<br style="clear: both" />
<br style="clear: both" />
Every incoming and outgoing events, signals and commands are logged in Siwenoid with one second accuracy. So every event can be traced back, can be filtered and can be exported.


[[Image:123.jpeg|left|thumb|800px]]
''' Select an option suits our needs.'''
<br style="clear: both" />
 
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.
 


* '''1;''' Every events are shown by the color of its event category. The time, status and the corresponding datapoint is shown.


* '''2;''' Filtering options. We can search and filter the event log by date and time interval, plus we can search for phrases and names with the input fields under the columns.


* '''3;''' Exporter buttons. The filtered event log of the Siwenoid software can be printed or exported in .XLSX, .CSV and interactive HTML format.


* '''4;''' Frequent searches (like a specific door's signals or often alerting smoke detector) can be saved for quick access. These can be loaded instantly from the dropdown menu (fast search).
<br style="clear: both" />
<br style="clear: both" />
<br style="clear: both" />
<br style="clear: both" />
<br style="clear: both" />
<br style="clear: both" />

Latest revision as of 11:36, 31 July 2018

Language: English


Everyday operation of Siwenoid

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.

1) The event categories bar

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; Acknowledged / Not acknowledged events

-Indicating number that shows how many events we have in the category and how many of them are acknowledged.

-The "1/1" in the example are showing us that we have one event which already have been acknowledged in the software.


2) Parts, details and usage of the Signal log

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.


3) Deleted events: events with black background

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)


4) Detecting and handling alarms from central units and datapoints

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.


5) Usage of the event log

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.

6) Special filtering options (AND / OR search)

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)

7) Exporting the event list to XLSX, CSV or interactive HTML file

  • 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.






Retrieved from "https://wiki.siwenoid.com/index.php?title=Everyday_operation_of_Siwenoid&oldid=3235"