Integrator Guide - Revision 2.22.1, März 2018 - SystemTera

SystemTera®

Integrator Guide Revision 2.22.1, März 2018

- i -

Document Information

Title: Integrator Guide

Revision: 2.22.1

Revision Date: 07 März 2018

Filename: systemtera_integratorguide_2.22.1_0b.docx

© 2018 System Tera Electronics GmbH, Austria

This work is copyright protected.

All rights including reprint and translation of the document are reserved. Reproduction or use of content in any

manner without express permission of the copyright holder is prohibited.

Whilst every precaution has been taken in the preparation of this manual, no responsibility is assumed for errors

or omissions. No liability is assumed for loss or damage resulting from the use of information in this document.

- ii -

Table of Contents

1. GENERAL INTRODUCTION 1

2. GETTING STARTED 1

2.1 Download and install SystemTera.Manager 2

2.2 Create an Installation 2

2.3 Configure the Installation 4 2.3.1 Configure what is executed on the SystemTera.Server 5

2.4 Configure the Visualization 19

2.5 Transfer the configuration to SystemTera.Server 22

3. CONFIGURATION 23

3.1 Bus Objects 23 3.1.1 Modbus RTU Master 24 3.1.2 Modbus RTU Slave 36 3.1.3 Modbus IP Master 37 3.1.4 Modbus IP Slave 40 3.1.5 KNX 42 3.1.6 EnOcean 42 3.1.7 Other supported Interfaces 45

3.2 Data Objects 45

3.3 Data Sources 52

3.4 Gateway 52 3.4.1 Modbus IP – RTU Gateway 52

3.5 Modules 53

3.6 Rules 53

3.7 Alerting 58 3.7.1 Alert Configuration 58 3.7.2 Alert settings at the tenant level 62 3.7.3 Configuration Example: Temperature threshold alarm 64

- 1 -

1. General Introduction

This document describes

Components and concepts of SystemTera

How to configure a SystemTera.Server

This document is intended for integrators and power users who intend to plan,

setup or modify the configuration of a SystemTera.Server.

2. Getting Started

To configure a new SystemTera.Server, you need to cover the following steps:

1. Download and install the SystemTera.Manager

2. Create an installation in the SystemTera.Manager. This can be done

either by registering a new SystemTera.Server-V using the credentials

printed on the back side of the server housing (preferred method), or by

manually creating a new installation in the List view of the Installations

section of the SystemTera.Manager. In the latter case matching

credentials need to be set up both in the SystemTera.Manager and in

the section “Cloud Settings” of the SystemTera admin web pages.

3. Configure what is executed on the SystemTera.Server in the

SystemTera.Manager configuration section of an installation. This

includes setting up bus objects, data objects, rules and data handling:

a. Bus objects define which data is exchanged with devices

connected to the SystemTera.Server.

b. Data objects define a device independent anchor for processing

the data from devices and input from the visualization.

c. Data handling defines whether data objects are to be logged for

having a history of the data, and it defines which data is

forwarded to the cloud or a mobile app for visualization.

d. Rules define functionality executed on the SystemTera.Server

when new data is received or when a defined time has expired.

This step does not require a SystemTera.Server to be online. This step

requires online access to the SystemTera.Cloud.

4. Configure the scope and shape of the visualization of the data in the

visualization editor of the SystemTera.Manager. Configure additional

users for viewing the visualization as needed in the User section of the

SystemTera.Manager.

This step does not require a SystemTera.Server to be online. This step

requires online access to the SystemTera.Cloud.

5. Transfer the configuration to SystemTera.Server.

- 2 -

This step requires both the SystemTera.Manager and the System-

Tera.Server to have an online connection to the cloud, or the

configuration can be saved on a USB stick and transferred to the

SystemTera.Server by restarting it with the USB stick present at startup.

6. Test the configuration. You can activate the debug mode in the

configuration editor of the SystemTera.Manager to see the current

values of bus objects and data objects to facilitate this step.

7. Test the visualization on the target device, e.g. a particular smart phone.

The following sections explain these steps in more detail. As an example, a

PT1000 temperature sensor is configured with data logging and display of the

current value on a smart phone. The sensor is then used to control an electric

heater to reach a set temperature.

2.1 Download and install SystemTera.Manager

The SystemTera.Manager is the software for

configuring a SystemTera.Server,

accessing the visualization of installations,

performing user management, and

exporting data from the System.

Download the installation file for the SystemTera.Manager from

https://www.systemtera.com/de/downloads/ .

The SystemTera.Manager requires Windows 7 or newer and the .NET Framework

from Microsoft.

The installation is a so called Click-once installation, which does not require

administrative privileges on the system.

2.2 Create an Installation

When you start the SystemTera.Manager for the first time, you will see the login

window shown in Figure 1.

- 3 -

Figure 1: Login to SystemTera.Manager

To create a new installation, click on “Register new SystemTera.Server” and

follow the instructions.

Figure 2: First step of registering a new SystemTera.Server

As part of the registration process you will be able to choose between creating

a new user for the SystemTera.Manager, or to add the new installation to an

existing user you already have.

It is not necessary for the SystemTera.Server to be online for these steps.

- 4 -

2.3 Configure the Installation

To start the configuration process, launch the SystemTera.Manager and login

using the user you have either received during the registration process or from

your integration partner.

Your screen will look similar to Figure 3. If you see more tiles than in Figure 3,

you have additional access permissions which are not required for the

configuration of a single SystemTera.Server and which can be ignored for the

purpose of this document section.

Figure 3: SystemTera.Manager after login

- 5 -

Click on “Installations”, select the installation you would like to configure in the

list of installations, and click on the configuration button as indicated on Figure

4.

Note: the question mark in the status column indicates that the System-

Tera.Server for this installation is currently not online and has never been online

before.

Figure 4: List of installations

2.3.1 Configure what is executed on the SystemTera.Server

2.3.1.1 Configure what is connected to the SystemTera.Server

In the first step of the configuration you need to define which devices the

SystemTera.Server should be communicating with.

This is done by adding elements to the bus objects tree on the left-hand side of

screen as shown in Figure 5.

- 6 -

To do thi

Figure 5: Configuration screen of an installation

As part of this getting started section we will just add a simple PT1000

temperature sensor which we assume to be connected to input 1 of the

SystemTera.Server.

To do this, move the mouse cursor over the connector where you want to add

a device and press the “+” button which appears in this line. In our example this

is the line called “Inputs”, as shown in Figure 6.

- 7 -

Figure 6: Add an input to the bus objects

A selection of compatible object templates appears. Select “PT 1000”.

Figure 7: Select a bus object template

- 8 -

Figure 8: A new PT1000 sensor has been added

Figure 8 shows the tree of bus objects with the new PT1000 temperature sensor.

You can change the name of the sensor to reflect its purpose, e.g. “Room temp”.

The Description property can be used to capture more details about the sensor.

This field is just for documentation purposes and does not have a functional

impact.

The Address refers to the physical connector being used on the

SystemTera.Server.

For more details about using bus objects please refer to section 3.1 “Bus

Objects”.

2.3.1.2 Configure Data Objects

Data objects are used to define what happens with data handled in the

SystemTera.Server in fashion which is independent of the interface the data

originally came from.

- 9 -

Data objects also offer an opportunity to describe all aspects of a logical entity

in one object. For example, a data object representing venetian blinds might

contain attributes covering all commands that can be sent to the blinds and all

the status responses which may come back.

Use folders to organize data objects intuitively, e.g. by having one folder per

room and another folder for central functions.

For our example, move the mouse cursor to the line “Data objects” and press

the “+” button.

Figure 9: Add a new data object

There is a template for a temperature sensor. To avoid searching in the long list

of available templates just type a part of the template name. If only one template

remains in the list you can also simply press the enter key to select it. See Figure

10.

Figure 10: Ad a temperature sensor data object

- 10 -

Figure 11: The temperature sensor object has been added

To get the data from the physical sensor to the temperature sensor data object,

use the mouse to drag the “Value” attribute from the PT 1000 sensor and drop

it on the “Value” attribute of the temperature sensor data object (see Figure 12).

Figure 12: Drag and drop bus object attribute to data object attribute

As a result, a link from the bus object attribute to the data object attribute is

created. Because the name of the data object was still the default name, the

name of the bus object was copied to the data object which is now also called

“Outdoor temp” (see Figure 13).

- 11 -

Figure 13: After drag & drop operation

2.3.1.3 Configure Data Handling

We would like to store a history of the measurements from our sensor. To do

so, we need to globally activate the local data storage module. This is done in

the properties of the root node of the data objects tree.

Figure 14: Activate local data storage in the properties of the root node

- 12 -

Local data storage stores data on a USB stick on the SystemTera.Server. The data

on the stick can be shown on diagrams of the SystemTera.Manager, or exported

to a .csv file using the SystemTera.Manager. Future versions of the smart phone

app will also be able to display diagrams by directly access this data.

The fastest sampling rate available is 100ms. Normal and slow sampling intervals

have to be a multiple of the fast sampling interval.

Figure 14 shows the default settings.

You need to attach a suitable USB stick to one of the USB ports of the

SystemTera.Server to use local data storage. If data logging is intended for

several months or more, we recommend using an industry grade or SLC type

USB stick.

Now we can activate data logging in the properties of the temperature sensor

data object by just selecting the checkbox of the module (see Figure 15).

Figure 15: Activate local data storage for the temp sensor

The properties of each data object determine which modules are active for this

object.

The module “Live Data” is required to show live updates on the

SystemTera.Manager and the SystemTera.App via the SystemTera.Cloud.

The module “Local access” is required for the SystemTera.App to directly access

the SystemTera.Server without going through the SystemTera.Cloud.

- 13 -

2.3.1.4 Configure Data Aggregation

When needed the numerical attributes of data objects can be used to create a

rolling minimum, maximum or average of the received values.

We will use this in this example to combine multiple sensor readings for getting

better quality data for visualization.

To improve the quality of the sensor readings, increase the polling interval for

the sensor from every 10 seconds (default) to e.g. every 100ms.

This is done in the properties of the “Inputs” node.

Figure 16: Set the input polling interval

We can now use the properties of the data object attribute to define that we

would like to use only the minimum of the last 100 values. Note: this works

better than the average to reduce the impact of noise from the sensor cabling

on the AD converter. This configuration will produce a rolling minimum across

the most recent sensor readings.

- 14 -

Figure 17: Select aggregation for data received by the data object attribute

2.3.1.5 Configure Rules

Go through the following steps to create and configure a rule which controls a

heater depending on a fixed setpoint (for the sake of simplicity of the example)

and the current room temperature.

First add another data object using the “Electrical load” template.

Then add the rule by moving the mouse cursor in the line of a folder and press

the “+” button, then select the Two-Point Controller template.

- 15 -

Figure 18: Add two-point controller rule template

Switch to the rule editor by pressing the button. The screen will then look

as shown in Figure 19. Later move back to the previous view by pressing the

button.

- 16 -

Figure 19: Rule editor for two-point contntroller

Configure the parameters of the rule as shown in Figure 20.

Use data object attributes as parameters by drag & drop from the attribute

name to the parameter field.

Use the link toggle button next to the “Nominal Value” parameter to toggle the

parameter from link to constant value and enter the desired target temperature.

The final result should look like Figure 20.

- 17 -

Figure 20: Parameters for two-point controller after configuration

The rule is now fully functional. However the result will just be written to the

electrical load data object without effect in the physical world. Therefore we

need to add an actor for the heater.

In this simple example we just use one of the relay outputs of the

SystemTera.Server itself. See Figure 21after adding the output and Figure 22

after linking the output attribute with the switching status attribute of the

electrical load.

- 18 -

Figure 21: Add relais output for heater

Figure 22: Link relais output value to switching status of data object

- 19 -

2.4 Configure the Visualization

To configure the visualization, you need to save the configuration and then

switch to the visualization editor (see Figure 23).

Figure 23: Switch to visualization editor

Create a first schema by selecting “Layout for mobile devices”.

Figure 24: Select the type of visualization schema

Use drag & drop to drag a temperature sensor to the preview area.

- 20 -

Figure 25: Drag & drop temperature sensor

In the properties of the temperature sensor widget, select the data object which

should provide the data (see Figure 26).

Figure 26: Select the room temp data object as data source

- 21 -

Figure 27: Temperature widget after configuration

Then add a push button widget for showing the status of the heater.

If it should not be possible to manually control the heater, add a dummy

attribute and select this for the normal attribute, select “separate status

attribute” and select the attribute controlled by the two-point controller there.

Figure 28: Add a push button widget for the heater

The following figure shows a screenshot from an Android smart phone with a

page from a sample configuration.

- 22 -

Figure 29: Sample screenshot of the SystemTera.App

2.5 Transfer the configuration to SystemTera.Server

In order for a configuration to become active on a SystemTera.Server, it has to

be saved (see Figure 30) and sent to the server (see Figure 31).

Figure 30: Save configuration

Figure 31: Transfer configuration to the server

- 23 -

3. Configuration

3.1 Bus Objects

Bus objects exist to interface with external devices.

The primary interfaces supported by SystemTera.Server are well known industry

standards. In addition to that SystemTera.Server also supports integration for

some proprietary interfaces.

Bus objects are structured and named reflecting the structure and naming

conventions of the target interfaces.

Modbus RTU devices can be connected via the built in RS485, or via USB RS485

adapter. Modbus RTU slaves can also be connected via USB to RS232 adapter.

Although RS232 is not a bus, some manufacturers have products which use

Modbus to communicate between components internally and offer an RS232

gateway to the internal bus.

The following table shows all SystemTera.Server interfaces with support for the

Modbus protocol. For each interface the Modbus functionality supported by the

SystemTera.Server is shown, as well as how many instances of that functionality

can be configured and what functionality needs to be present on the connected

devices.

SystemTera.Server

Interface

SystemTera.Server

configured as Max Connected device

RS485 Modbus RTU

Master 1 Modbus RTU Slave

RS485 Modbus RTU Slave 1 Modbus RTU Master

USB connected to

RS232 adapter

Modbus RTU

Master

2 / 8 via

USB hubs

Gateway to Modbus

RTU Slaves

USB connected to

RS485 adapter

Modbus RTU

Master

2 / 8 via

USB hubs Modbus RTU Slave

USB connected to

RS485 adapter Modbus RTU Slave

2 / 8 via

USB hubs Modbus RTU Master

Ethernet Modbus IP Master 1

Modbus IP Slave or

Gateway to Modbus

RTU Slaves

Ethernet Modbus IP Slave n Modbus IP Master

Ethernet Modbus IP – RTU

Gateway n

Modbus IP Master

connected to

Ethernet and Mod-

- 24 -

bus RTU Slave

connected to

another System-

Tera.Server interface

3.1.1 Modbus RTU Master

To configure SystemTera.Server as a Modbus RTU Master, move the mouse

cursor into the line of the interface where the slaves for the Modbus RTU Master

will by physically connected, and press the button.

The following interfaces support Modbus RTU Master:

RS485

USB via a USB – RS485 adapter


Figure 32

After clicking on , a popup window (see Figure 33) comes up. Select “ModBus

– RTU Master” from the list.

- 25 -

Figure 33

3.1.1.1 Serial Interface Parameters

Once you have added and selected the ModBus RTU Master, the properties for

configuration are visible underneath the tree of bus objects as shown in Figure

34.

Figure 34

- 26 -

Name: A name for this bus master. Changing the name is important

if there are more than one Modbus RTU master in one

configuration. Short names have an advantage because the

path name to an element in the master will be shorter, and it

will be easier to see the full link between a bus object attribute

and a data object attribute. The name does not have a

functional impact.

Description: A description to better document the configuration. The

description does not have a functional impact.

Address: The Linux device for the interface on the SystemTera.Server.

The system populates this element automatically. This is a read

only property.

Baud rate: The speed for the serial interface to the bus. You need to make

sure that all devices attached to one bus line share the same

settings for Baud rate, parity, data bits and stop bits. The

length and quality of the bus cabling and the slowest device

on the bus determine the maximum Baud rate.

Figure 35

Parity: This property determines the type of additional check bit sent

with each character: Odd, even or none.

Data bits: The number of bits per character. Select 8 bits.

Stop bits: The number of stop bits sent after each character. Modbus

standard defines either the use of 2 stop bits and no parity, or

a parity bit and one stop bit. SystemTera.Server supports all

possible combinations of parity and stop bits.

3.1.1.2 Adding Modbus Slaves

Press the button on the line of the Modbus RTU master. In the list of Modbus

slave templates (see Figure 36) either select a generic Modbus RTU device or

- 27 -

the specific device type of your device if the list contains a specific template for

the device you want to communicate with.

Templates for a specific slave offer the advantage of already knowing the

register names and addresses for that device type.

Figure 36

Figure 37 shows the properties for a generic Modbus slave.

- 28 -

Figure 37

Name: A name for the slave device. Short names have an

advantage because the path name to an element in the

master will be shorter, and it will be easier to see the full

link between a bus object attribute and a data object

attribute. The name does not have a functional impact.

Max numerical registers per read request: The SystemTera.Server will auto-

matically group access to consecutive numerical

registers and if possible create only one read request to

- 29 -

read all consecutive registers of the same type with one

command.

Some devices only permit a limited number of registers

to be read per request. Use this parameter to limit the

number of registers read per request if the target device

requires a smaller limit. The maximum value is 125

registers per request.

Max bit registers per read request: The SystemTera.Server will automatically

group access to consecutive bit registers and if possible

create only one read request to read all consecutive

registers of the same type with one command.








Address: Each Modbus RTU slave must be configured to have an

address. Valid values range from 1 to 247. The address

must be unique amongst all slaves connected to the

same physical bus line.

Polling interval: Modbus is a single master bus. Therefore, the slaves

cannot notify the master of any changed values on their

own. The master has to query the slaves at regular

intervals. This parameter determines the pause between

asking the slave for an update on all of the values

configured for this slave (see 3.1.1.3 for how to configure

which values are to be read). The interval is defined in

seconds. The smallest possible interval is 100ms.

Please keep in mind that the bus line is a shared medium

and has to provide the bandwidth to support the polling

interval for all data from all slaves. The more values you

read per cycle the longer the interval will have to be.

Device Read Delay: This parameter determines the length of the pause after

reading data values from other slaves before requesting

data from this slave in milliseconds. The default value is

zero.

Some Modbus slaves have very little CPU power and

cannot respond to a series of queries, which arrive as

quickly as the selected Baud rate permits. If needed, start

with a long time to see whether it makes a difference

- 30 -

(e.g. 500ms) and work down to smaller values to see

what still works. Add at least 10% to the smallest value

that still worked for the final configuration.

Attribute Read Delay: This parameter determines the length of a pause

between reading data values from this slave in

milliseconds. The default value is zero.

Some Modbus slaves have very little CPU power and

cannot respond to a series of queries, which arrive as

quickly as the selected Baud rate permits. If needed, start

with a long time to see whether it makes a difference

(e.g. 500ms) and work down to smaller values to see

what still works. Add at least 10% to the smallest value

that still worked for the final configuration.

Write in intervals: Check this checkbox if you want all values configured for

writing to the slave written at regular intervals.

Independent of this setting data configured for writing

to a Modbus slave will always be written on an event

driven basis when the data value changes.

Writing interval: This parameter determines the pause between writing

all data to the slave again. This parameter only has an

effect if “Write in intervals” is checked. The smallest

possible parameter value is 1 second.

Write mode: This parameter (see Figure 38) determines how the

SystemTera.Server writes values to the Modbus slave.

The Modbus protocol offers two functions for doing so.

Some devices only support one of those functions.

Usually it is sufficient to select “Automatic”.

Figure 38

3.1.1.3 What data to exchange

Modbus communication is based on registers. The register types are very basic.

The following table shows the Modbus register types.

Read only Read and write access

2-byte values

Signed: -32768 - 32767

Unsigned: 0 - 65535

Input register Holding register

- 31 -

1 Bit: true / false Discrete input Coil

To work with larger number formats several Modbus registers are used in

combination to represent one value.

It is important to understand that Modbus register addressing works like

addressing memory in units of 2 bytes. A 4-byte value at input register address

10 will actually occupy input register addresses 10 and 11.

For data types needing more than one register SystemTera.Server uses a single

command to read or write multiple registers thus only using one request.

The following data types are available for Modbus communication:

Figure 39

There is no data type specific to date, time and combined date / time values.

You can map date, time and combined date / time data object attributes to a

numerical 8-byte Modbus register type. The system will convert the date time

information from and to the Modbus attribute according to the Unix style

representation of milliseconds since Jan 1st 1970.

Press the button on the right-hand side of a Modbus slave to add a value for

data exchange with that Modbus slave. Figure 40 shows the screen after a 4-

byte Integer attribute has been added.

- 32 -

Figure 40

The properties for numerical Modbus attributes are:

Name: A name for the attribute. This should resemble the

register description of the manual of the Modbus device.

Short names have an advantage because the path name

to an element in the master will be shorter, and it will be

easier to see the full link between a bus object attribute

and a data object attribute. The name does not have a

functional impact.

- 33 -



Table: A complete address for a Modbus register consists of

table and register address. The table can either be “Input

register”, “Holding register”, “Discrete input” and “Coil”.

Some devices do not document the table used for

registers because they use a fixed range of register

addresses per table. In this case, the register address

implicitly defines the table. For these devices, you can

determine the table by looking at the register number in

the device documentation. At the same time, the first

digit is usually not part of the register address that has

to be used.

Register in

documentation

Calculate

Register

address

Table

1-9999 -1 Coil

10001-19999 -10001 Discrete Input

30001-39999 -30001 Input register

40001-49999 -40001 Holding register

Register address: A zero based data address between 0 and 65535. Some

devices document their registers using an addressing

scheme starting with one. In this case, you have to

subtract one from the number in the documentation

before entering the address in the SystemTera.Server

configuration.

Byte order: Use this parameter to specify the byte order for this

slave.

AB CD = big endian

CD AB = little endian

The Modbus documentation only specifies the byte

order for 2-byte values as big endian. This means that

the first byte sent on the bus contains the higher-

ranking bits of the two bytes. The standard does not

explicitly specify how to deal with values that require

more than 2 bytes for representation. Consequently,

different vendors have implemented this differently.

Factor: Use this parameter to transform the value read from the

device before using it.

- 34 -

Example: use “0.1” to automatically divide an incoming

temperature specified as an integer in 1/10° C. The

SystemTera.Server will then internally use double

precision float values in °C.

The inverse calculation is performed before writing to

the device.

Offset: Use this parameter to transform the value read from the

device before using it.

Example: if a temperature sensor value in 1/10°C is read

from the device and the factor is set to “0.1”, use “-0.2”

to subtract a fixed offset to correct a sensor with a

known fixed error of 0.2°C.

The inverse calculation is performed before writing to

the device.

Ignore repeated values from bus: Check this checkbox to suppress further

processing if consecutive read operations return the

same result.

You might want to use this option to prevent rules which

depend on this input to be executed after each read,

especially if this has undesired side effects.

You might want to make sure not to check this option if

you want to calculate an average for some values and

therefore depend on getting values with the most

regular timing possible.

Read: Check this box to read from the device.

Write: Check this box to write to the device. This box cannot be

checked for registers in read only tables.

- 35 -

Figure 41

Figure 41 shows the properties for a Yes/No (Boolean) attribute. For all

properties with identical names as for numerical attributes, please refer to the

explanation above.

Invert value: Use this parameter to invert the Boolean value read from

the device before using it.

Example: check this option to invert the logic of an

attribute e.g. from “is open” to “is closed”.

- 36 -

The inverse calculation is performed before

writing to the device.

3.1.2 Modbus RTU Slave

To configure SystemTera.Server as a Modbus RTU Slave, move the mouse cursor

into the line of the interface, which the SystemTera.Server will be physically

connected to as a slave, and press the button.

The following interfaces support Modbus RTU Slave:

RS485


After clicking on , a popup window (see Figure 33) comes up. Select “ModBus

– RTU Slave” from the list.

Figure 42 shows the properties for the Modbus RTU slave.

Figure 42

Name: A name for this slave. Changing the name is important

if there are more than one Modbus RTU slaves in one

configuration. Short names have an advantage because

the path name to an element in the slave will be shorter,

and it will be easier to see the full link between a bus

object attribute and a data object attribute. The name

does not have a functional impact.



Address: The Linux device for the interface on the

SystemTera.Server. The system populates this element

automatically. This is a read only property.

- 37 -

Baud rate: The speed for the serial interface to the bus. You need

to make sure that all devices attached to one bus line

share the same settings for Baud rate, parity, data bits

and stop bits. The length and quality of the bus cabling

and the slowest device on the bus determine the

maximum Baud rate.

Figure 43

Parity: This property determines the type of additional check

bit sent with each character: Odd, even or none.

Data bits: The number of bits per character. Select 8 bits.

Stop bits: The number of stop bits sent after each character.

Modbus standard defines either the use of 2 stop bits

and no parity, or a parity bit and one stop bit.

SystemTera.Server supports all possible combinations of

parity and stop bits.

Address: This is the address of the slave on the bus. It has to be

unique amongst all slaves on the same physical bus line.

Valid values range from 1 to 247.

Configuring attributes for a Modbus slave is identical to configuring attributes

for a Modbus master. Please refer to chapter 3.1.1.3 “What data to exchange”.

3.1.3 Modbus IP Master

Modbus IP has almost identical capabilities as Modbus RTU. The main difference

is the layer for transporting the data: Modbus IP uses an IP network connection,

and Modbus RTU uses a serial data interface.

Take care to only use Modbus IP in a secured network environment because the

Modbus IP protocol does not support authentication, authorization or

encryption of any sort.

- 38 -

The IP network provides a transport layer that can be shared easily. Therefore, it

is possible to set up one Modbus IP master and several Modbus IP slaves on the

same physical Ethernet interface of the SystemTera.Server at the same time.

Figure 44

Figure 44 shows the properties for a Modbus IP master.

Name: A name for this bus master. The name does not have a

functional impact.



3.1.3.1 Adding Modbus IP Slaves

Press the button on the line of the Modbus IP master. Select Modbus IP

device.

Figure 45 shows the properties for a Modbus IP slave connected to a

SystemTera.Server as a master.

Address: Modbus RTU address of the target slave. This parameter

has no bearing on Modbus IP slaves. This parameter is

important, if the target slave is a Modbus RTU slave

behind a Modbus IP to RTU gateway.

- 39 -

IP address: IPv4 address or hostname of the Modbus slave.

Port: Port number for the Modbus interface on the Modbus

slave.

Figure 45: Properties of a Modbus IP device

Timeout: Timeout in seconds when waiting for an answer from the

slave. The smallest possible value is 100ms.

Polling interval: This parameter determines the pause between asking

the slave for an update on all of the values configured

for this slave (see 3.1.1.3 for how to configure which

values are to be read). The smallest possible interval is

100ms.

Max numerical registers per read request: The SystemTera.Server will auto-

matically group access to consecutive numerical

registers and if possible create only one read request to

read all consecutive registers of the same type with one

command.




- 40 -



Max bit registers per read request: The SystemTera.Server will automatically

group access to consecutive bit registers and if possible

create only one read request to read all consecutive

registers of the same type with one command.






Write in intervals: Check this checkbox if you want all values configured for

writing to the slave written at regular intervals.

Independent of this setting data configured for writing

to a Modbus slave will always be written on an event

driven basis when the data value changes.

Writing interval: This parameter determines the pause between writing

all data to the slave again. This parameter only has an

effect if “Write in intervals” is checked. The smallest

possible parameter value is 1 second.

Write mode: This parameter determines how the SystemTera.Server

writes values to the Modbus slave. The Modbus protocol

offers two functions for doing so. Some devices only

support one of those functions. Usually it is sufficient to

select “Automatic”.

3.1.4 Modbus IP Slave

Press the button on the line of the Ethernet interface. Select Modbus IP slave.

Figure 46 shows the properties of a Modbus IP slave.

- 41 -

Figure 46

Name: A name for this slave. Changing the name is important

if there are more than one Modbus RTU slaves in one

configuration. Short names have an advantage because

the path name to an element in the slave will be shorter,

and it will be easier to see the full link between a bus

object attribute and a data object attribute. The name

does not have a functional impact.



Port: The port at which the slave listens for Modbus

commands from the server. Values need to be in the

range from 1500 to 1599 to let the SystemTera.Server

firewall pass the requests. Each port can only be used

once for all types of Ethernet services in one entire

SystemTera.Server configuration.

Configuring attributes for a Modbus slave is identical to configuring attributes

for a Modbus master. Please refer to chapter 3.1.1.3 “What data to exchange”.

- 42 -

3.1.5 KNX

The SystemTera.Server supports KNX on twisted pair wiring.

KNX support is currently described in a separate document.

3.1.6 EnOcean

EnOcean is a wireless communication standard optimized for low energy usage.

A lot of enOcean devices use power from harvesting energy from the

environment and operate without needing a battery.

To be able to communicate with enOcean radio devices, an enOcean sender and

receiver must be connected to one of the USB ports of the SystemTera.Server.

The SystemTera.Server can communicate with enOcean devices in one of two

ways:

1. EnOcean devices such as an enOcean rocker switch can be taught into

the SystemTera.Server. In order to do so the SystemTera.Server must be

online, and the enOcean USB extension must be connected and

configured. After pressing the teach-in button in the System-

Tera.Manager (see Figure 47), teach in telegrams will be displayed in a

device list. The received teach-in telegrams can then be used to add an

enOcean device to the list of paired devices.

2. The SystemTera.Server can be used to simulate a standard enOcean

device such as a rocker switch. The SystemTera.Server can send teach-in

telegrams to enOcean actuator devices such as a smart plug. The

simulated devices are then listed in the “Simulated devices” folder. This

way the SystemTera.Server offers control over enOcean actuators.

Figure 47: enOcean teach-in button

- 43 -

EnOcean devices communicate with each other using so called Enocean

Equipment Profiles, abbreviated “EEP”.

The following list shows the EEPs supported by the SystemTera.Server.

EEP Description

A5-02-01 Temperature Sensor Range -40°C to 0°C

A5-02-02 Temperature Sensor Range -30°C to +10°C



A5-02-05 Temperature Sensor Range 0°C to +40°C

A5-02-06 Temperature Sensor Range +10°C to +50°C




A5-02-0A Temperature Sensor Range +50°C to +90°C

A5-02-0B Temperature Sensor Range +60°C to +100°C







A5-02-16 Temperature Sensor Range 0°C to +80°C




A5-02-1A Temperature Sensor Range +40°C to +120°C

A5-02-1B Temperature Sensor Range +50°C to +130°C

A5-02-20 Temperature Sensor Range -10°C to +41.2°C

A5-02-30 Temperature Sensor Range -40°C to +62.3°C

A5-04-01 Temperature and Humidity Sensor Range 0°C to +40°C and 0% to 100%

A5-04-02 Temperature and Humidity Sensor Range -20°C to +60°C and 0% to

100%

A5-04-03 Temperature and Humidity Sensor Range -20°C to +60°C (10bit) and 0%

to 100%

A5-07-01 Occupancy with Supply voltage monitor (opt.)

A5-07-02 Occupancy with Supply voltage monitor

- 44 -

EEP Description

A5-07-03 Occupancy with Supply voltage monitor and 10-bit illumination

measurement

A5-08-01 Range 0lx to 510lx, 0°C to +51°C and Occupancy Button

A5-08-02 Range 0lx to 1020lx, 0°C to +51°C and Occupancy Button

A5-08-03 Range 0lx to 1530lx, -30°C to +50°C and Occupancy Button

A5-09-02 CO-Sensor 0ppm to 1020ppm

A5-09-04 CO2 Sensor

A5-09-05 VOC Sensor

A5-09-06 Radon Sensor

A5-09-07 Particle Sensor

A5-09-08 Pure CO2 Sensor

A5-10-01 Temperature Sensor, Set Point, Fan Speed and Occupancy Control

A5-10-02 Temperature Sensor, Set Point, Fan Speed and Day/Night Control

A5-10-03 Temperature Sensor, Set Point Control

A5-10-04 Temperature Sensor, Set Point and Fan Speed Control

A5-10-05 Temperature Sensor, Set Point and Occupancy Control

A5-10-06 Temperature Sensor, Set Point and Day/Night Control

A5-10-07 Temperature Sensor and Fan Speed Control

A5-10-08 Temperature Sensor, Fan Speed and Occupancy Control

A5-10-09 Temperature Sensor, Fan Speed and Day/Night Control

A5-10-0A Temperature Sensor, Set Point and Single Input Contact

A5-10-0B Temperature Sensor and Single Input Contact

A5-10-0C Temperature Sensor and Occupancy Control

A5-10-0D Temperature Sensor and Day/Night Control

A5-10-10 Temperature and Humidity Sensor, Set Point and Occupancy Control

A5-10-11 Temperature and Humidity Sensor, Set Point and Day/Night Control

A5-10-12 Temperature and Humidity Sensor and Set Point

A5-10-13 Temperature and Humidity Sensor, Occupancy Control

A5-10-14 Temperature and Humidity Sensor, Day/Night Control

A5-10-15 10 Bit Temperature Sensor, 6 Bit Set Point Control

A5-10-16 10 Bit Temperature Sensor, 6 Bit Set Point Control; Occupancy Control

A5-10-17 10 Bit Temperature Sensor, Occupancy Control

A5-10-18 Illumination, Temperature Set Point, Temperature Sensor, Fan Speed and

Occupancy Control

A5-10-19 Humidity, Temperature Set Point, Temperature Sensor, Fan Speed and

Occupancy Control

- 45 -

EEP Description

A5-10-1A Supply Voltage Monitor, Temperature Set Point, Temperature Sensor,

Fan Speed and Occupancy Control

A5-10-1B Supply Voltage Monitor, Illumination, Temperature Sensor, Fan Speed

and Occupancy Control

A5-10-1C Illumination, Illumination Set Point, Temperature Sensor, Fan Speed and

Occupancy Control

A5-10-1D Humidity, Humidity Set Point, Temperature Sensor, Fan Speed and

Occupancy Control

A5-10-1E Supply Voltage Monitor, Illumination, Temperature Sensor, Fan Speed

and Occupancy Control (II)

A5-10-1F Temperature Sensor, Set Point, Fan Speed, Occupancy and Unoccupancy

Control

A5-10-20 Temperature and Set Point with Special Heating States

A5-10-21 Temperature, Humidity and Set Point with Special Heating States

A5-12-01 Electricity

D5-00-01 Single Input Contact

F6-02-01 Light und Blind Control Application Style 1

F6-10-00 Window Handle

F6-10-00 Window Handle ERP2

3.1.7 Other supported Interfaces

Awattar Hourly Tariff via Ethernet

MBus via USB Extension

Honeywell XL-50 / XL-500 via RS232 via USB

Buderus Logamatic 4000 via RS232 via USB

Davis Vantage Weather Stations via USB

Solarier SHX Controller via RS232 via USB

Eaton Moeller RF Bus via RS232 via USB

3.2 Data Objects

Data objects are used as the basis for visualization in the SystemTera.Manager,

the Apps for smart phones, and for logging data either to a USB stick or into

cloud storage on the SystemTera.Cloud.

Each data object may contain one or more attributes, e.g. a data object of the

type “Light” may contain the attributes “Light On” and “Brightness”.

- 46 -

Data objects represent data in a device independent fashion. All data exchanged

with external devices is converted between the device specific format and the

internal format used by the data objects. If the internal format uses a binary

format different from the native format of the external device, numbers will be

converted using up to 8 bytes floating point numbers for the internal

representation to avoid loss of information.

When the SystemTera.Server is used as a gateway between devices using a

different bus standard (e.g. an enOcean button and a KNX actor), the conversion

from and to data objects makes it possible to exchange data between any

combination of bus standards supported by the SystemTera.Server.

Each data object type offers a set of attributes which matches the purpose of

the type.

The generic data object offers all attributes available in the system. Therefore,

you could create a configuration just using generic data objects.

Using data object types specific to a particular purpose has the following

advantages:

The most commonly used attributes are created automatically. E.g. using

the Jalousie data object type to represent venetian blinds will

automatically create attributes “Slats / Close/Stop”, “Set Slat Position”, …

Because the generic data object is generic, it does not have default

attributes. Here all attributes have to be created manually.

Specific data objects types are linked to a matching default visualization

widget for a graphical visualization schema in the SystemTera.Manager.

This speeds up configuring the visualization later on.

Using appropriate attributes predetermines display units for the

visualization. For example, using the temperature value attribute of a

temperature sensor data object will default to a display with the unit “°C”

in the visualization later on. If you use generic numbers, all display units

have to be configure manually later on.

Some attributes are automatically selected as a default for matching

visualization widget properties.

The following table lists all data object types.

Group Data Object

Type

Comment

General

Purpose

Generic data

object

This type of data object can be used for

any purpose.

Building

Automation

Electrical load Use for any electrical load which is just

turned on or off, with an optional separate

status.

- 47 -

Group Data Object

Type

Comment

Jalousie Use for venetian blinds including up/down

movement, control of slat angle, absolute

positioning and position status feedback.

Light Use for lights, normal, dimmed or colored.

Building

Automation,

Heating

System

Temperature

sensor

Use this to represent any form of

temperature sensor which returns readings

in °C.

Metering

Electric meter Use this to represent an electric meter

which measures energy in kW/h and

optionally other attributes such as power,

voltage, …

In combination with cloud data storage

readings can be used in a separate meter

management section of the

SystemTera.Manager.

Gas meter Use this to represent a gas meter which

measures volume in m³ and optionally

other attributes such as power, voltage, …




SystemTera.Manager, along with functions

to calculate energy from operating m³.

Heat meter Use this to represent a heat flowmeter

which measures energy in kW/h and

optionally other attributes such as

temperature and flow.




SystemTera.Manager.

Pulse counter Use this to count pulses. Can be used to

either determine e.g. windspeed as a

function of pulses per time or to

determine energy consumption as a

function of pulses from a meter. In this

case the meter management section of the

- 48 -

Group Data Object

Type

Comment

SystemTera.Manager can be used to input

manual readings of absolute meter values

and to define the energy per pulse.

Heating

System

Boiler Use this to represent a heater, either

electric or burning gas or other

combustible material with an attribute for

modulation (0-100%) and operational

state.

Buffer tank Use this to represent a buffer tank for

heated or cooled liquids. Add temperature

attributes as needed.

Burner Use this to represent a separate forced-air

burner which is attached to a boiler.

Manometer Use this to represent a pressure measuring

device.

Pump Use this to represent a pump with

attributes for relative speed (0-100%) and

operational state.

Valve Use this to represent a valve with a

numerically encoded position.

Documenta-

tion only

Automatic

expansion tank See Figure 48

Expansion tank Similar to Figure 48

Heat exchanger Similar to Figure 48

Hydraulic

separator

Similar to Figure 49

Oil tank See Figure 49

Pellets storage Similar to Figure 49

Solar collector Similar to Figure 49

Solar

installation


- 49 -

Group Data Object

Type

Comment

Wood chips

storage


Refrigeration

System

Cooling Unit Use this to represent a refrigeration unit

with an attribute for modulation (0-100%)

and operational state.

Alerting

Alert Use this object in combination with the

cloud data storage module to send alert

emails or alert text messages.

Warning Use this object in combination with the

cloud data storage module to send

warning emails or warning text messages.

Some data object types are not intended to receive live data from external

devices. They are listed in the group “Documentation only”. They are intended

as an aid for documenting the installation and provide additional properties to

document components used in the installation. See the following figures for

examples.

Figure 48: Properties of an automatic expansion tank

- 50 -

Figure 49: Properties of an oil tank

The following table lists the default visualization widgets and the default

attributes of all data object types.

Group Data Object

Type

Default

Visualization

Widget

Default Attributes

General

Purpose

Generic data

object

Data display -

Building

Automation

Electrical load Electric switch Switching status

Jalousie Push-button Jalousie down

Slats Close/Stop

Set Jalousie Position

Set Slat Position

Jalousie Position

Slat Position

Light Push-button Light on

Building

Automation,

Heating

System

Temperature

sensor

Temperature

sensor

Value

Metering Electric meter Electric meter Energy

- 51 -

Group Data Object

Type

Default

Visualization

Widget

Default Attributes

Gas meter Gas meter Energy

Heat meter Heat meter Energy

Pulse counter Data display Pulse count

Duration

Heating

System

Boiler Boiler State

Buffer tank Buffer tank -

Burner Burner State

Manometer Pressure gauge Pressure

Pump Pump Rotational speed

Valve Valve Position

Heating

System

Documentation

Automatic

expansion tank

Automatic

expansion tank

-

Expansion tank Expansion tank -

Heat exchanger Heat exchanger -

Hydraulic

separator

Hydraulic

separator

-

Oil tank Oil tank -

Pellets storage Pellets storage -

Solar collector Solar collector -

Solar

installation

Solar installation -

Wood chips

storage

Wood chips

storage

-

Refrigeration

System

Cooling Unit Cooling Unit State

Alerting Alert Electric switch Status

Warning Electric switch Status

- 52 -

3.3 Data Sources

3.4 Gateway

3.4.1 Modbus IP – RTU Gateway

A Modbus IP – RTU gateway acts as a router of requests from a Modbus IP

master to multiple Modbus RTU slaves.

To create a Modbus IP – RTU gateway press the button on the line of the

Ethernet interface. Select Modbus IP gateway.

Figure 50

Figure 50 shows the properties of a Modbus IP – RTU gateway.

Name: A name for this gateway. The name does not have a

functional impact.



Port: The port at which the gateway listens for Modbus

commands from the server. Values need to be in the

- 53 -

range from 1500 to 1599 to let the SystemTera.Server

firewall pass the requests. Each port can only be used

once for all types of Ethernet services in one entire

SystemTera.Server configuration.

Modbus RTU master: In order for the gateway to work, the SystemTera.Server

first needs to be configured as a Modbus RTU master for

the slaves that should be connected via the gateway.

This Modbus RTU master needs to be selected in this

parameter.

3.5 Modules

3.6 Rules

The SystemTera.Server offers a range of rules for implementing custom logic as

part of a configuration. Rules can be created as required. There if no

predetermined set of rules which determines how many rules of which type are

available.

Rules are executed on an event driven basis. Whenever a new value for a data

object attribute becomes available, all rules using this attribute as input will be

executed.

Rules are configured in the same object tree as data objects.

Click on a rule and the rule editor button to open the rule editor. The rule editor

will also show the documentation for the rule and its parameters.

Figure 51: Rule editor button

Parameters with a pink background color are mandatory parameters.

Parameters with a button next to them can be switched between a link to a

data object attribute or a constant value.

Drag and drop an attribute from the tree of data objects to a parameter box to

create a link between a data object attribute and a rule parameter.

Figure 52 shows what the rule editor looks like for the rule if before filling in the

parameters.

If cyclic dependencies between rules or an excessive number of rules cause

continuous CPU overload, the system watchdog will detect this condition after

several minutes and restart the SystemTera.Server without active configuration.

The SystemTera.Manager has then to be used to send an improved

configuration to the SystemTera.Server. This is an important safety mechanism,

- 54 -

because in the case of working on a configuration off site it will prevent the

server to become inaccessible due to an error in the configuration of rules.

Figure 52: Rule editor showing the rule „If“

The following table shows the available rules.

Rule Group Rule Comment

Arithmetic

Functions

Linear function �(�) = � ∙ � + �

Polynomial �(��, ��) =��+��∙ �� +

��∙ ��

�

Pow �(�) = � ∙ ��

- 55 -


Maximum

Minimum

Logic

Functions

And Up to 8 inputs

Not

Or Up to 8 inputs

Trigonometric

Functions

ArcCos Inverse Cos

ArcSin Inverse Sin

ArcTan Inverse Tan

Cos

Sin

Tan

Degree to radian

Radian to degree

Building

Automation

Jalousie Automatic

(Smart Actor)

Automated control of blinds based

on the current position of the sun and

the orientation of the blinds. Use this

function for actors which accept

absolute position commands.

Jalousie Automatic

(Up/Down & Stop

Actor)

Automated control of blinds based

on the current position of the sun and

the orientation of the blinds. Use this

function for actors which only accept

up, down and stop commands.

Pulse Switch

Use a signal from a simple switch and

assign different functions based on

short and long operation of switch

Scene control Implement scenes for lights, RGB

lights and blinds.

Timer

Implements a general-purpose timer,

e.g. to control a light which should be

turned off again after a defined time

- 56 -


PID Controller

Use this to implement heating control

for individual rooms based on a

continuous valve actuator.

Two Point

Controller

Use this function to do threshold

comparisons on sensor readings and

to implement heating control for

individual rooms.

Conditional

functions

Condition

monitoring

Select one of two values depending

on an attribute being continuously

within a defined range for at least a

specific duration.

If Select one of two values depending

on a simple comparison.

Data

Conversion

Integer to bits

Convert an integer value into 16

individual bits representing the

binary encoding of the integer. Use

this to decode Modbus register

values containing several indepen-

dent flags.

Bits to integer Combine 16 bits to form an integer

value.

Integer to bitfields

Convert an integer into up to 8

numbers representing consecutive

bit fields in the binary encoding of the

integer. Use this to decode Modbus

register values containing several in-

dependent numbers, enumerations

or flags.

Bitfields to integer

Combine up to 8 numbers repre-

senting consecutive bit fields into an

integer.

Combine RGB color Combine a red, green and blue value

to form a single 32bit color value.

Split RGB color

Split an RGB color attribute into

individual values for red, green and

blue.

- 57 -


Split RGBW color

Split an RGBW color attribute into

individual values for red, green, blue

and white.

Data History

Delta Delta between the current and the

most recent value of the input

Operating meter

(input above

threshold)

Operating meter

(input below

threshold)

Operating meter

(input is on)

Operating meter

(integral of input

values)

Operating meter

(sum of input

values)

Special

functions

Interpolation Target

Value

Interpolate how long it will take until

a specific target value is reached

LinuxScript Execute a Linux shell script

Pulse Generator Generate a number of pulses

depending on a numeric input

Value Repeater Continuously resend a value after a

defined interval

In depth: all attribute changes caused by one device polling operation (e.g.

periodic Modbus read) will only dispatch final results, not emitting intermediate

results caused by a network of rules depending on several inputs. E.g. reading

two registers from one device containing mantissa and exponent which are then

combined into one floating point number using a rule will only dispatch the final

result and not the intermediate result after the first attribute has been red from

the device.

- 58 -

3.7 Alerting

System Tera supports sending of alert messages. Both the condition for sending

an alert and the alert message are configurable.

Alert messages can be sent as an email message or as a mobile phone system

text message (SMS).

To use alerts the SystemTera.Cloud connectivity has to be active. Sending SMS

requires a contract for premium cloud services to be active.

When an alert condition starts or ends, a log entry is created in the

SystemTera.Cloud log for the installation. If an alert condition is currently active,

the SystemTera.Manager shows the status of the installation as .

Only visible to users who have access privileges for all installations in a tenant:

The installation overview shows a separate area with an overview of all

currently active alerts and other installation problems (such as network

connectivity).

For installations with an active alert, the position marker on the map view

will be red.

Figure 53

3.7.1 Alert Configuration

To configure an alert, enter the configuration editor and add an “Alert” or

“Warning” object in the tree of data objects.

- 59 -

Figure 54

The alert object contains the following properties:

Name Name of the alert. When the alert is active, this name will

show up on the installation overview. This name will also be

part of the log entry in the SystemTera.Cloud log of the

installation.

Description This is for documentation purposes and has no functional

impact.

Notification type This determines how users will receive a notification, if an

alert is triggered. Possible options are:

Text message Send an SMS

Email Send an Email

Email and text message Send both an Email and an SMS

None The status in the SystemTera.-

Manager installation overview

and the log entries are updated.

No message is sent.

Message The message text which will be sent as part of the Email or

text message.

Requires confirmation Reserved for future use

Remote Monitoring This module has to be selected for alerting to work.

Period [s] This property determines how frequently the current status

is stored in cloud storage. When an alert status changes,

the SystemTera.Server immediately sends the new alert

status to the SystemTera.Cloud. Therefore, this setting does

not have an impact on the reaction speed for notifying the

users.

- 60 -

This setting only has an impact on the visualisation of the

alert status as part of a visualisation page when looking at

historic data. Select larger values (e.g. 43200) if this is not

an issue.

After Keep Period This setting determines what happens with values in cloud

storage after the data retention period has expired. The

duration of the data retention period depends on the

tenant to which the installation belongs.

Users with system administrator privilege for a tenant can

change this setting in “Settings”, “SystemTera.Cloud”,

“Keep Duration [Years]”.

Live data Select this module if you want to see the current status in

the visualization via the SystemTera.Cloud.

You will usually want to select this module.

Local access Select this module if you want to see the current status in

the visualization using direct local access to the

SystemTera.Server without going through the SystemTera.-

Cloud.

You will usually want to select this module.

Figure 55

- 61 -

Make sure that the remote monitoring module is active. This module can be

turned on and off for all data objects via the property “Remote monitoring” in

the root node of the data objects tree (see the following figure).

Figure 56

If the “Max. number of attribute values per day” is zero, please contact your

SystemTera service partner to obtain premium SystemTera.Cloud services.

When an alert status changes, the SystemTera.Cloud notifies users with the

access privileges for the installation and with the contact details necessary for

the notification type defined in the alert.

SystemTera sends a notification to users with the following access privileges to

the installation with an alert status change:

Installations administrator

Remote monitoring

To receive alert status notifications via email set the following properties for the

user.

Select “Receive alert emails”

Provide the email address in the “Email” property

- 62 -

To receive alert status notifications via SMS set the following properties for the

user.

Select “Receive text messages when an alert occurs”

Provide the mobile phone number in the “Phone number” property. The

format has to be “+country code” followed by the number, e.g.

“+436641234567”.

Each user can change these settings for his own user.

Figure 57

3.7.2 Alert settings at the tenant level

A number of settings can be defined at tenant level. These settings are identical

for all installations belonging to one tenant.

Only users with the general permissions system administrator or installations

administrator for a tenant can access the settings screen shown in Figure 58.

The following settings are available:

Send warnings If checked, emails and SMS are sent for alerts and for

warnings. If not checked, emails and SMS are only sent for

alert objects.

Subject This text will be the subject line of any alarm or warning

email.

Content This is a text template which will be copied into any alarm

or warning email message body.

Text message template This is a text template which will be copied into any

alarm or warning SMS.

The following special strings will be replaced by the appropriate content when

generating an alarm or warning SMS email. This affects the settings Subject,

Content and Text message template.

{{Severity}} “Alert” or “Warning”

- 63 -

{{Value}} Current value of the alarm object. “completed” if there is no

alarm any more or “occurred” if an alarm has been

detected.

{{Text}} Alarm text configured in the message property of the alarm

or warning object.

{{Name}} Name of the installation.

{{Date}} Date and time of the state change of the alarm or warning

object

{{Street}} Street name of the address of the installation.

{{StreetNumber}} Street number of the address of the installation.

{{ZipCode}} Zip code field of the address of the installation.

{{City}} City field of the address of the installation.

{{Country}} Country field of the address of the installation.

{{Latitude}} Latitude of the location of the installation.

{{Longitude}} Longitude of the location of the installation.

- 64 -

Figure 58

3.7.3 Configuration Example: Temperature threshold alarm

This example shows the configuration of a temperature monitoring which will

send an alarm message when a predefined temperature threshold is exceeded.

The temperature is obtained from a PT1000 sensor connected to an analogue

input of the SystemTera.Server. To prevent an alarm from being frequently

triggered and cleared again, a different temperature value is used for triggering

and resetting the alarm. This can be done in one function block using a “Two

Point Controller” function block.

Step 1: Add input and a linked temperature sensor data object

Open the configuration screen for the installation.

On the bus object side, add the PT 1000 (resistive sensor with 1000 Ohm at 0°C)

using the next to “Inputs”.

Set the polling interval for the SystemTera.Server inputs by selecting the “Inputs”

line and change to polling interval to e.g. 0.1 s.

- 65 -

On the data objects side, add a temperature sensor using the next to “Data

objects”. Change the name to something appropriate, e.g. “Server room”. If you

would like to create a visualisation for this value later on, select the “Live data”

and “Local access” modules.

Link the value of the PT 1000 sensor to the temperature sensor value by using

drag & drop (see Figure 59).

Figure 59

Figure 60: Result of step 1

Step 2: Average across multiple sensor readings

In the data objects tree, click on the attribute containing the value of the

temperature sensor.

In the section “Aggregation” select type “Minimum” and a number of sensor

readings which should be aggregated to one value for further processing, e.g.

5. In this example, we use “Minimum” instead of “Average” because this will give

- 66 -

us a more accurate result. Depending on cable length and absence of shielding

in the sensor cable electromagnetic disturbances will be picked up by the cable

and transport additional electrical energy to the AD converter. Therefore, any

bigger aberrations from the true value will be higher but not lower than the true

value.

Figure 61

Step 3: Add and configure two point controller

Add the “Two Point Controller” function block by using the next to “Data

objects”. You can speed up finding the right function block by typing the first

letters of the name of the function block or data object type (see Figure 62).

Figure 62: Add Two Point Controller

- 67 -

Select the two point controller and change to the configuration screen for the

rule by pressing the button.

Figure 63: Rule editor

Use the value from the PT 1000 sensor for the input parameter “Actual Value”

in the rule by using drag and drop to create a link.

Use the button of the “Nominal Value” input parameter to change the

parameter from a linked parameter to a constant. Enter your threshold here.

Optional: If you would like to be able to edit the threshold in your visualization,

create a separate data object (either a generic data object or a temperature

sensor which contains the threshold instead of a sensor reading) with an

attribute for the threshold. Change the startup behavior property to “Last value

before system start”. This will result in any changes to the attribute being written

to the internal SD card of the SystemTera.Server. When the SystemTera.Server

is restarted e.g. after a power loss, the last value will be used to initialize the

attribute. Link this attribute to “Nominal Value” in the two-point controller

instead of using a constant.

Set the property “Hysteresis” to determine the temperature difference the

sensor input has to drop below the threshold to clear the alert again.

- 68 -

Set the undercut value to 0 to define what is written to the result of the rule if

the threshold is not exceeded or the temperature has fallen enough to clear the

condition after the threshold has been exceeded. We will use the 0 to reset the

alarm object.

Set the overstepping value to 1 to define what is written to the result of the rule

if the threshold is exceeded. We will use the 1 to trigger the alarm object.

Figure 64

Step 4: Create Alert Object

Add the alert object by using the next to “Data objects”. You can speed up

finding the right object type by typing the first letters of the name of the data

object type (see Figure 65).

- 69 -

Figure 65: Add the alert object

By changing the properties of the alert object you can define whether to send

an email, SMS or both, as well as the message that is sent.

If you are not interested in a point in time visualization of historic data, change

the remote period to something large (e.g. 43200 for two values per day). The

change of the alert status will be sent immediately. This value determines how

frequently the alert status is recorded in cloud storage even if the status does

not change.

Use drag & drop to link the status attribute of the alert object with the output

parameter “Result” of the two – point controller rule.

- 70 -

Figure 66: Configuration of the alert object

Step 5: Send configuration to server and check what it does

Use the button to save the configuration.

Use the button to send the configuration to the SystemTera.Server. This is

the first point in time in this process where the server actually has to be online.

The entire configuration can be prepared without a physical server being

present.

Once the SystemTera.Server has successfully received the configuration, the

send configuration button will change to green . Now you can use the debug

button to get an online view of the attribute values in the SystemTera.Server

(see Figure 67).

- 71 -

Figure 67: Debug mode shows attribute values in separate columns

Integrator Guide - Revision 2.22.1, März 2018 - SystemTera

Documents