A Device is any electronic device configured and controlled by Tibbo AggreGate. LinkServer works with different types of Devices using special Data Transfer/Device Plugins. These plugins may be also called Device Drivers, because they know how to "talk" to a certain device using its native protocol. Every Device Plugin provide a normalized representation of one or more Device as Contexts. This normalization process involves several steps:
| • | Creation of one Device Context per every Device that works with AggreGate. |
| • | Conversion of Device internal settings and configuration options into context Variables (Properties). |
| • | Conversion of control operations supported by the Device into context Functions and corresponding Actions helping to execute these functions interactively (Call Function actions). |
| • | Conversion of events generated by Device into context Events. |
All these operations help provide unified methods of Device configuration, control and monitoring within AggreGate infrastructure. When a Device is represented as a context with variables, functions, and events, you can use all of AggreGate's management features (Alerts, Reports, Widgets etc.) to work with it.
Connection Types
Devices may be connected to LinkServer either directly, or using a Device Server.
In the case of a direct connection, the Device Plugin communicates with the device directly, without any middle man. This is how SNMP (Simple Network Management Protocol) devices work with LinkServer.
Directly connected Devices are accessed and managed using the Devices Context:
To connect new Device to a system, use Add Device action (Devices Context).
Connection Using Device Server
In some cases Device are connected to AggreGate using so-called Device Servers. A Device Server is a piece of hardware that resides on the Device's side, and acts as data transfer agent and/or protocol converter. Connection using Device Server has several advantages:
| • | It is possible to connect multiple devices using one network host and TCP connection to the server. This may be important when connecting numerous simple devices (such as sensors). There is no need to network-enable each sensor in this case. |
| • | A Device Server may convert a Device's native protocol into AggreGate Communications Protocol. Since the Device Server "understands" the Device's native protocol, it may also perform some data processing, such as filtering out meaningless Device events in order to optimize the data flow between LinkServer and Device. |
An example of a Device Plugin that supports Devices connected via Device Servers is the AggreGate Agent plugin.
Administering Devices
Two contexts are used to administer Devices: One is the general Devices context that acts as a container of all Device connected to LinkServer through a single Device Server. The other is the Device context, corresponding to a single Device. There are two additional contexts related to Devices: All Devices context under the User context and All Devices under the Root context. These contexts provide access to grouped actions for all Devices belonging to a particular user account, and all Devices in the system, respectively. |
|
When the connection between LinkServer and a Device is active, the server synchronizes them periodically. The actual algorithm of synchronization depends on the Device type, but in most cases synchronization includes two primary steps:
| • | Reading information about available device settings, operations and events and creating appropriate variables, functions and events in Device Context to access them; |
| • | Synchronization of Device setting values between LinkServer and server cache. |
When LinkServer first reads values of Device internal settings, it stores these values in the database. This is called settings caching. Users can view and edit settings for any Device, even if it is not currently connected to the <%LS%.
|
NEW TERM: A cache is a collection of data duplicating original values stored elsewhere or computed earlier. A cache is used when the original data is expensive (usually in terms of access time) to fetch or compute, while reading the cache is "cheap" (i.e, easy and quick). |
|
When you're viewing or editing Device settings, you're actually working with the server's cache. There is no way to edit the actual Device settings directly. New settings are written to the Device on synchronization. |
The Settings Cache is periodically synchronized with the Device. Synchronization occurs in the following cases:
| • | When a Device connects to the LinkServer; |
| • | When setting values are changed in the cache (using AggreGate Client for example) while a Device is connected to the server; |
| • | Periodically, as defined by the Synchronization Interval setting of Data Transfer/Device Plugin that communicates with the Device. |
Every setting is synchronized according to the following algorithm:
| • | If the setting value does not exist in the server cache, it is cached (i.e. its value is read from the Device and stored in the server cache); |
| • | If the setting value in the server cache was changed later than in the Device, the cached value is written to the Device; |
| • | If the setting value in the Device was changed later than in the server cache, the cached value is replaced by the current value of the Device setting; |
| • | Otherwise, no action is performed. |
Cached Settings Synchronization Status
Every setting value in the server cache is contained in a variable in the server context corresponding to the Device. When settings are being viewed or edited (e.g, using the Properties Editor of AggreGate Client), the Synchronization Status of every setting appears by the setting description.
Available Synchronization Statuses
Synchronization Status takes on the following values:
Icon |
Status |
Description |
|
Synchronized from Device to Server |
Indicates that value was arrived from a Device and stored in the server cache. |
|
Synchronized from Server to Device |
Indicates that value was changed in the server cache and written to the Device. |
|
Waiting for Synchronization |
Indicates that the value in the server cache was changed since last synchronization but was not written to Device yet. |
|
Synchronization Error |
Indicates that an error has occurred when synchronization was last attempted for this setting. |
Using Common Tables for Storing Shared Values of Device Settings
It is possible to set up master values for Device settings. Master values are stored in Common Data tables instead of the normal server cache. Every common table contains the value for a single Device setting, so the values of simple settings such as String or Number are stored in a table containing just one column and one row.
When synchronizing a Device with the server, the plugin tries to detect if there are common tables containing setting values. If Global Common Data contains a table with the same name as the setting name, the value of the setting (from the common table) will be written to all Devices in the system which have settings with this name. If the common table is found in User Common Data, its contents will be used for all Devices under the user's account (which have a setting by this name).
If the plugin finds that some setting should be synchronized using a common table, synchronization is always performed from LinkServer to the Device. The contents of a common table are never overridden or modified according to the value of a Device setting.
If a setting is synchronized using a common table, you can't view or change its value using a Configure Device action. Instead of its value, you'll see a read-only string, like Using Common Table XXX contained in YYY:
See Integration with Device in Common Data for more information.