SystemTera Integrator Guide. Revision , März 2018

Transcription

1 SystemTera Integrator Guide Revision , März 2018

2 Document Information Title: Integrator Guide Revision: 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. - i -

3 Table of Contents 1. GENERAL INTRODUCTION 1 2. GETTING STARTED Download and install SystemTera.Manager Create an Installation Configure the Installation Configure what is executed on the SystemTera.Server Configure the Visualization Transfer the configuration to SystemTera.Server CONFIGURATION Bus Objects Modbus RTU Master Modbus RTU Slave Modbus IP Master Modbus IP Slave KNX EnOcean Other supported Interfaces Data Objects Data Sources Gateway Modbus IP RTU Gateway Modules Rules Alerting Alert Configuration Alert settings at the tenant level Configuration Example: Temperature threshold alarm 64 - ii -

4 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

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

6 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

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

8 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 Configure what is executed on the SystemTera.Server 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

9 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

10 Figure 6: Add an input to the bus objects A selection of compatible object templates appears. Select PT Figure 7: Select a bus object template - 7 -

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

12 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 - 9 -

13 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)

14 Figure 13: After drag & drop operation 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

15 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

16 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

17 Figure 17: Select aggregation for data received by the data object attribute 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

18 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

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

21 Figure 21: Add relais output for heater Figure 22: Link relais output value to switching status of data object

22 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

23 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

24 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

25 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

26 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 RS485 SystemTera.Server configured as Modbus RTU Master Max Connected device 1 Modbus RTU Slave RS485 Modbus RTU Slave 1 Modbus RTU Master USB connected to RS232 adapter USB connected to RS485 adapter USB connected to RS485 adapter Modbus RTU Master Modbus RTU Master Modbus RTU Slave 2 / 8 via USB hubs 2 / 8 via USB hubs 2 / 8 via USB hubs Ethernet Modbus IP Master 1 Gateway to Modbus RTU Slaves Modbus RTU Slave Modbus RTU Master 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

27 bus RTU Slave connected to another System- Tera.Server interface 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 USB via a USB RS232 adapter Figure 32 After clicking on, a popup window (see Figure 33) comes up. Select ModBus RTU Master from the list

28 Figure 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

29 Name: Description: Address: Baud rate: 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. A description to better document the configuration. The description does not have a functional impact. The Linux device for the interface on the SystemTera.Server. The system populates this element automatically. This is a read only property. 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: Data bits: Stop bits: This property determines the type of additional check bit sent with each character: Odd, even or none. The number of bits per character. Select 8 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 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

30 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

31 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 automatically group access to consecutive numerical registers and if possible create only one read request to

32 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. 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 2000 registers per request. Description: Address: Polling interval: Device Read Delay: A description to better document the configuration. The description does not have a functional impact. 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. 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 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. 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

33 (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: Writing interval: Write mode: 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. 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. 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 What data to exchange Modbus communication is based on registers. The register types are very basic. The following table shows the Modbus register types. 2-byte values Signed: Unsigned: Read only Input register Read and write access Holding register

34 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 1 st 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

35 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

36 Description: Table: A description to better document the configuration. The description does not have a functional impact. 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 Coil Discrete Input Input register Holding register Register address: Byte order: Factor: A zero based data address between 0 and 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. 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 higherranking 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. Use this parameter to transform the value read from the device before using it

37 Offset: 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. 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. Read: Write: 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. Check this box to read from the device. Check this box to write to the device. This box cannot be checked for registers in read only tables

38 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

39 The inverse calculation is performed before writing to the device 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 USB via a USB RS485 adapter 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: Description: 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. 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

40 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: Data bits: Stop bits: Address: This property determines the type of additional check bit sent with each character: Odd, even or none. The number of bits per character. Select 8 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. 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 What data to exchange 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

41 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: Description: A name for this bus master. The name does not have a functional impact. A description to better document the configuration. The description does not have a functional impact Adding Modbus IP Slaves Press the device. button on the line of the Modbus IP master. Select Modbus IP 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

42 IP address: Port: IPv4 address or hostname of the Modbus slave. Port number for the Modbus interface on the Modbus slave. Figure 45: Properties of a Modbus IP device Timeout: Polling interval: Timeout in seconds when waiting for an answer from the slave. The smallest possible value is 100ms. This parameter determines the pause between asking the slave for an update on all of the values configured for this slave (see 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 automatically 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. 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

43 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. 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 2000 registers per request. Write in intervals: Writing interval: Write mode: 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. 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. 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 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

44 Figure 46 Name: Description: Port: 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. A description to better document the configuration. The description does not have a functional impact. 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 What data to exchange

45 3.1.5 KNX The SystemTera.Server supports KNX on twisted pair wiring. KNX support is currently described in a separate document 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

46 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 A Temperature Sensor Range -40 C to 0 C A A A A A A A A A5-02-0A A5-02-0B A A Temperature Sensor Range -30 C to +10 C Temperature Sensor Range -20 C to +20 C Temperature Sensor Range -10 C to +30 C Temperature Sensor Range 0 C to +40 C Temperature Sensor Range +10 C to +50 C Temperature Sensor Range +20 C to +60 C Temperature Sensor Range +30 C to +70 C Temperature Sensor Range +40 C to +80 C Temperature Sensor Range +50 C to +90 C Temperature Sensor Range +60 C to +100 C Temperature Sensor Range -60 C to +20 C Temperature Sensor Range -50 C to +30 C A A A A A A A A A5-02-1A A5-02-1B A A Temperature Sensor Range -40 C to +40 C Temperature Sensor Range -30 C to +50 C Temperature Sensor Range -20 C to +60 C Temperature Sensor Range -10 C to +70 C Temperature Sensor Range 0 C to +80 C Temperature Sensor Range +10 C to +90 C Temperature Sensor Range +20 C to +100 C Temperature Sensor Range +30 C to +110 C Temperature Sensor Range +40 C to +120 C Temperature Sensor Range +50 C to +130 C Temperature Sensor Range -10 C to C Temperature Sensor Range -40 C to C A Temperature and Humidity Sensor Range 0 C to +40 C and 0% to 100% A Temperature and Humidity Sensor Range -20 C to +60 C and 0% to 100% A Temperature and Humidity Sensor Range -20 C to +60 C (10bit) and 0% to 100% A A Occupancy with Supply voltage monitor (opt.) Occupancy with Supply voltage monitor

47 EEP A A A A A A A A A A A A A A A A A A A A5-10-0A A5-10-0B A5-10-0C A5-10-0D A A A A A A A A A A Description Occupancy with Supply voltage monitor and 10-bit illumination measurement Range 0lx to 510lx, 0 C to +51 C and Occupancy Button Range 0lx to 1020lx, 0 C to +51 C and Occupancy Button Range 0lx to 1530lx, -30 C to +50 C and Occupancy Button CO-Sensor 0ppm to 1020ppm CO2 Sensor VOC Sensor Radon Sensor Particle Sensor Pure CO2 Sensor Temperature Sensor, Set Point, Fan Speed and Occupancy Control Temperature Sensor, Set Point, Fan Speed and Day/Night Control Temperature Sensor, Set Point Control Temperature Sensor, Set Point and Fan Speed Control Temperature Sensor, Set Point and Occupancy Control Temperature Sensor, Set Point and Day/Night Control Temperature Sensor and Fan Speed Control Temperature Sensor, Fan Speed and Occupancy Control Temperature Sensor, Fan Speed and Day/Night Control Temperature Sensor, Set Point and Single Input Contact Temperature Sensor and Single Input Contact Temperature Sensor and Occupancy Control Temperature Sensor and Day/Night Control Temperature and Humidity Sensor, Set Point and Occupancy Control Temperature and Humidity Sensor, Set Point and Day/Night Control Temperature and Humidity Sensor and Set Point Temperature and Humidity Sensor, Occupancy Control Temperature and Humidity Sensor, Day/Night Control 10 Bit Temperature Sensor, 6 Bit Set Point Control 10 Bit Temperature Sensor, 6 Bit Set Point Control; Occupancy Control 10 Bit Temperature Sensor, Occupancy Control Illumination, Temperature Set Point, Temperature Sensor, Fan Speed and Occupancy Control Humidity, Temperature Set Point, Temperature Sensor, Fan Speed and Occupancy Control

48 EEP Description A5-10-1A A5-10-1B A5-10-1C A5-10-1D A5-10-1E A5-10-1F A A A D Supply Voltage Monitor, Temperature Set Point, Temperature Sensor, Fan Speed and Occupancy Control Supply Voltage Monitor, Illumination, Temperature Sensor, Fan Speed and Occupancy Control Illumination, Illumination Set Point, Temperature Sensor, Fan Speed and Occupancy Control Humidity, Humidity Set Point, Temperature Sensor, Fan Speed and Occupancy Control Supply Voltage Monitor, Illumination, Temperature Sensor, Fan Speed and Occupancy Control (II) Temperature Sensor, Set Point, Fan Speed, Occupancy and Unoccupancy Control Temperature and Set Point with Special Heating States Temperature, Humidity and Set Point with Special Heating States Electricity Single Input Contact F Light und Blind Control Application Style 1 F F Window Handle Window Handle ERP 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

49 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 General Purpose Building Automation Data Object Type Generic data object Electrical load Comment This type of data object can be used for any purpose. Use for any electrical load which is just turned on or off, with an optional separate status

50 Group Building Automation, Heating System Metering Data Object Type Jalousie Light Temperature sensor Electric meter Gas meter Heat meter Pulse counter Comment Use for venetian blinds including up/down movement, control of slat angle, absolute positioning and position status feedback. Use for lights, normal, dimmed or colored. Use this to represent any form of temperature sensor which returns readings in C. 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. Use this to represent a gas meter which measures volume in m³ 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, along with functions to calculate energy from operating m³. Use this to represent a heat flowmeter which measures energy in kw/h and optionally other attributes such as temperature and flow. In combination with cloud data storage readings can be used in a separate meter management section of the SystemTera.Manager. 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

51 Group Heating System Data Object Type Boiler Buffer tank Burner Manometer Pump Valve Automatic expansion tank Comment SystemTera.Manager can be used to input manual readings of absolute meter values and to define the energy per pulse. 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. Use this to represent a buffer tank for heated or cooled liquids. Add temperature attributes as needed. Use this to represent a separate forced-air burner which is attached to a boiler. Use this to represent a pressure measuring device. Use this to represent a pump with attributes for relative speed (0-100%) and operational state. Use this to represent a valve with a numerically encoded position. See Figure 48 Expansion tank Similar to Figure 48 Heat exchanger Similar to Figure 48 Documentation only 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 Similar to Figure

52 Group Refrigeration System Alerting Data Object Type Wood chips storage Cooling Unit Alert Warning Similar to Figure 49 Comment Use this to represent a refrigeration unit with an attribute for modulation (0-100%) and operational state. Use this object in combination with the cloud data storage module to send alert s or alert text messages. Use this object in combination with the cloud data storage module to send warning s 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

53 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 - Electrical load Electric switch Switching status Building Automation 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

54 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 Boiler Boiler State Buffer tank Buffer tank - Heating System Burner Burner State Manometer Pressure gauge Pressure Pump Pump Rotational speed Valve Valve Position Automatic expansion tank Automatic expansion tank - Expansion tank Expansion tank - Heat exchanger Heat exchanger - Heating System Documentation 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 Alerting Cooling Unit Cooling Unit State Alert Electric switch Status Warning Electric switch Status

55 3.3 Data Sources 3.4 Gateway 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 Ethernet interface. Select Modbus IP gateway. button on the line of the Figure 50 Figure 50 shows the properties of a Modbus IP RTU gateway. Name: Description: Port: A name for this gateway. The name does not have a functional impact. A description to better document the configuration. The description does not have a functional impact. The port at which the gateway listens for Modbus commands from the server. Values need to be in the

56 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,

57 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 Linear function ( ) = + Arithmetic Functions Polynomial (, ) = + + Pow ( ) =

58 Rule Group Rule Comment Maximum Minimum Logic Functions Trigonometric Functions Building Automation And Not Or ArcCos ArcSin ArcTan Cos Sin Tan Degree to radian Radian to degree Jalousie Automatic (Smart Actor) Jalousie Automatic (Up/Down & Stop Actor) Pulse Switch Scene control Timer Up to 8 inputs Up to 8 inputs Inverse Cos Inverse Sin Inverse Tan 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. 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. Use a signal from a simple switch and assign different functions based on short and long operation of switch Implement scenes for lights, RGB lights and blinds. Implements a general-purpose timer, e.g. to control a light which should be turned off again after a defined time

59 Rule Group Rule Comment Conditional functions Data Conversion PID Controller Two Point Controller Condition monitoring If Integer to bits Bits to integer Integer to bitfields Bitfields to integer Combine RGB color Split RGB color Use this to implement heating control for individual rooms based on a continuous valve actuator. Use this function to do threshold comparisons on sensor readings and to implement heating control for individual rooms. Select one of two values depending on an attribute being continuously within a defined range for at least a specific duration. Select one of two values depending on a simple comparison. Convert an integer value into 16 individual bits representing the binary encoding of the integer. Use this to decode Modbus register values containing several independent flags. Combine 16 bits to form an integer value. 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 independent numbers, enumerations or flags. Combine up to 8 numbers representing consecutive bit fields into an integer. Combine a red, green and blue value to form a single 32bit color value. Split an RGB color attribute into individual values for red, green and blue

60 Rule Group Rule Comment Split RGBW color Delta Split an RGBW color attribute into individual values for red, green, blue and white. Delta between the current and the most recent value of the input Operating meter (input above threshold) Data History 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 LinuxScript Pulse Generator Value Repeater Interpolate how long it will take until a specific target value is reached Execute a Linux shell script Generate a number of pulses depending on a numeric input 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

61 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 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 Alert Configuration To configure an alert, enter the configuration editor and add an Alert or Warning object in the tree of data objects

62 Figure 54 The alert object contains the following properties: Name Description Notification type Message Requires confirmation 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. This is for documentation purposes and has no functional impact. This determines how users will receive a notification, if an alert is triggered. Possible options are: Text message and text message None Send an SMS Send an Send both an and an SMS The status in the SystemTera.- Manager installation overview and the log entries are updated. No message is sent. The message text which will be sent as part of the or text message. 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

63 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 ) if this is not an issue. After Keep Period Live data Local access 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]. 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. 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

64 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 set the following properties for the user. Select Receive alert s Provide the address in the property

65 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 Each user can change these settings for his own user. Figure 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 Subject Content If checked, s and SMS are sent for alerts and for warnings. If not checked, s and SMS are only sent for alert objects. This text will be the subject line of any alarm or warning . This is a text template which will be copied into any alarm or warning 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 . This affects the settings Subject, Content and Text message template. {{Severity}} Alert or Warning

66 {{Value}} {{Text}} {{Name}} {{Date}} {{Street}} {{StreetNumber}} {{ZipCode}} {{City}} {{Country}} {{Latitude}} {{Longitude}} Current value of the alarm object. completed if there is no alarm any more or occurred if an alarm has been detected. Alarm text configured in the message property of the alarm or warning object. Name of the installation. Date and time of the state change of the alarm or warning object Street name of the address of the installation. Street number of the address of the installation. Zip code field of the address of the installation. City field of the address of the installation. Country field of the address of the installation. Latitude of the location of the installation. Longitude of the location of the installation

67 Figure 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

68 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

69 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

70 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

71 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)

72 Figure 65: Add the alert object By changing the properties of the alert object you can define whether to send an , 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 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

73 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)