Log
Last updated
Last updated
With the Log widget, you have the possibility to configure non-read-only fields/columns in a table. This way you can add different information to an event. Use Cases could be e.g. to log maintenance actions or to document the acknowledgment of an alarm. But as always with Senseforce - there are no limits to your creativity!
Adding information in this context means, there will be an additional database entry with the enriched data - this makes it possible to create a history of changes. The Metadata of the editor will automatically be saved and can also be displayed in the history.
To define the attributes you want to log with your log widget, you need to create a log event Schema. To do that, go to Virtual Events on the left side menu, then switch to the Log Events tab at the top of the screen. From here, you can edit already existing log events by clicking on them, or create a new log event by clicking the New Log Event button.
Log event schemas are pretty similar to normal event schemas, all you need to do in a log event is define the schema key and add log attributes.
When creating a log event schema, meta attributes will be defined
Attributes in log events support string, double, long and integer data types. Regarding the attributes of type double, amount of decimal places is considered later on, when editing the rows in the log widget.
A log event on its own doesn't really do much, not before combining it with a normal event schema. As an example, a log event with an attribute "alarm handled" will not be useful if it isn't combined with some kind of alarm event schema.
That's why we are going to create a new dataset where we will join together an event schema with a log event. That way we have our new attribute "alarm handled" mixed with e.g. our alarm event schema, so that we can define if the alarm was handled on every alarm event.
To add log event attributes to a dataset, go to the tab Log Event and click on the data column you want to add.
As you will notice, the created log event will have many more attributes than we've defined initially. These are so-called metadata attributes that will be generated automatically when creating a log event.
To create a valid dataset for your log widget, you need to follow some rules:
Besides your log event columns, you need to add columns from exactly one normal event schema or one virtual event.
You can't add columns from multiple event schemas, multiple virtual events or multiple log events.
Timestamp, thing, and id columns must be present in the dataset.
No columns in the dataset can be grouped or aggregated.
If you break one of the rules with your dataset, the dataset editor will show you an error in the column headers.
If you've done everything correctly, no errors will be present, and you can go to the next step and create the log widget!
After creating a valid log event dataset, we can go ahead and do the final step, creating the log widget, where you can finally enhance your normal event data with custom data from the log event!
To create a log widget, simply go to your widgets as normal and create a new widget. Select the Log Entry Table Widget at the general tab.
A log entry table widget is pretty much the same as a table widget, with the following exceptions:
You can only select datasets as your widgets' data source (no scripts)
You can only select valid log event datasets as your widgets' data source
Adding columns to your log entry table widget works similar to the normal table widget. If you add a column and select to display a log event column, you will notice that there is a new field appearing: the Input Type field. Here you can select, depending on the log event attributes data type, what kind of editor you would like to use for entering custom values in your widget.
As input types, Select and Manual Input are supported. The Select type is allowed to pick only for columns (attributes) of data type string. Manual Input is allowed to pick for all columns.
Manual Input enables free text/number input, depending on the attribute data type:
type string: free text input with a limit of 130 characters
type integer/long: only numbers input is allowed
type double: only decimal numbers allowed
When Select as Input type is chosen, there is an option for the user to set the datasource type: Dataset, Script, or Fixed.
When Dataset or Script type is selected, columns of type string of that selected datasource type are shown as option to select from which data is pulled and set as dropdown options for the current log widget column.
Dropdown options are limited to 15 options only, so when choosing datasource type Dataset or Script, only the first 15 rows of that datasource result are being shown and ordered accordingly.
For Fixed datasource type, user is able to insert and name each option which is reflected in the edit mode for that Log widget. Options can be reordered using handle, or can be deleted using trash icon.
Fixed options are also limited to 15 entries only. The saved order is reflected in the dropdown.
After you've configured your log widget, you should see a widget that looks similar to this:
Right now, this widget looks the same as a table widget. However, when you hover over your widget, you will see a new icon (the pencil icon) in the header of the widget, that will switch to the edit mode of your log widget. When doing this, all rows in your log event columns will be replaced by your selected input types for these columns.
When in edit mode, you can now add data to all your log event columns. While you're in edit mode, you can edit as many rows as you like.
When editing a value on a column type double, the decimal number will be rounded to a decimal number having decimal places defined previously in the log event attribute setup.
To save your entered data, you can use the checkmark icon in the header of the widget. To discard your changes, you can click on the x icon in the header of the widget.
As it is already stated, editing and saving data can be done through log widget. Log widget always shows combined data, and therefor always last change is seen after saving.
Non-combined data can still be seen in the log dataset, when accessing directly through dataset editor. This means each new change is seen as separate row in the log dataset result. Basically, log dataset represents a history of log widget changes.
This behavior can be used to show a history of each event, by using drilldown functionality, but it must be setup correctly.
To crate a table which displays the history of event changes, follow the next steps.
The log widget itself and the regular table used for history do not need to contain the ID column. An exception has been implemented to be able to pass the ID as a filter without having to set it up in the widgets themselves.
Assuming log dataset & log widget is already created using the instructions above, if not, create them
Create dashboard containing log widget
Save and exit edit mode. Now, by clicking on the row in the log widget, the user will be redirected to the dashboard containing the table widget, but with passed filter of event ID. This table represents the history of event data changes.
Make sure you add at least one data column from your schema.
Create another dashboard containing a regular table widget, which uses the same log dataset as datasource. Configure the ID filter for the dashboard as exemplified in the screenshot.
Go to the dashboard containing the log widget (from point 2.) and set linked dashboard as the one using the regular table widget (point 3.). In the link section check the event ID column and pass it by using values from table interaction, similar to the screenshot below:
