Niagara - BACnet - Historical export/import
The article outlines how to appropriately export/import historical data with the BACnet protocol in the Niagara system. Initially, it is required to correctly configure the BACnet driver, which is covered in the BACnet - Basic Configuration Steps article.
1. Historical Data Export
The export of historical data can be carried out twofold:
Exposing existing historical data over the BACnet communication (the method is available only if at least 1 record of data has been registered - which covers most cases of online working);
Creating ‘TrengLog’, which is automatically exposed over the BACnet protocol (the method can be used before any data have been registered - in case no Niagara ‘deamon’ is on the station, offline working).
These methods cannot be used together in one component ('BooleanWritable'/'EnumWritable'/'NumericWritable'), because in case if two historical extensions are added, two separate ‘TrendLog’ files are created in the database, and it is not possible to join them. It is possible to use both methods in one station.
However, if the station with historical data has been created, and later (e.g., after a month or a year) the station’s functionality is enhanced to export historical data, the first method is required.
1.1. Export of Existing Historical Data
As indicated before, export of existing historical data is possible only if at least 1 record has been created, which requires editing the station online or (if the station has been copied with the Niagara ‘deamon’, which has already saved data, and while copying the station to the ‘UserHome’ folder on the PC, the ‘Copy every file in the station directory and its subdirectories’ option has been selected) offline.
By way of example, the station was uploaded to the controller, and historical data was configured according to the standard procedure ('module: history’ as an extension to the ‘BooleanWritable'/'EnumWritable'/'NumericWritable’ component):
Figure 1. Configuration of the historical extension in the ‘NumericWritable’ component
Then, the first record of data was created (to confirm, check if the historical record is in the local database, in the ‘History/Station_Name’; in the described example it is ‘History/BACnet_test’):
Figure 2. List of registered historical records in the local station
Next, go to the ‘Config/Drivers/BacnetNetwork/LocalDevice/ExportTable’, and change the view to ‘Bacnet Niagara Log Export Manager’. In the main window, click the ‘Discover’ button, which searches for all local historical data in the station. Drag&drop selected objects (from the ‘Local Histories’ window) to the ‘Exported Objects’ window. Confirm with OK; the selected historical data are exposed over the BACnet protocol.
Figure 3. Exposing local historical data with the ‘Discover’ option in the BACnet protocol
1.2. Export of New Historical Data
As indicated before, export of new historical data is possible to configure even if the station is edited offline and no historical records have been registered in the database yet. This method is also available in online editing mode, and it is even faster than the first one.
In this method (offline or online), add the extension from the ‘bacnet’ module palette in the ‘Trending/BACnetLogExtensions’ folder to the ‘BooleanWritable'/'EnumWritable'/'NumericWritable’ component. Apart from standard options of historical extensions (from the ‘history’ module), there are also options to limit time of exposing historical data in the BACnet protocol ('Active Period').
Figure 4. Configuration of the ‘BACnetNumericCovTrendLogExt’ extension
Having such configured station uploaded to the device, the historical data appear automatically (with first registration), and they are auto-exposed in the BACnet protocol:
Figure 5. List of the ‘BACnetNumericCovTrendLogExt’ extensions automatically added to the BACnet ‘ExportTable’
2. Import of Historical Data
In order to import historical data, go to the ‘Config/Drivers/BacnetNetwork/Device_Name/TrendLogs’, and open the ‘Bacnet History Import Manager’ view. Click the ‘Discover’ button, and in the ‘Discovered’ window all historical data (published in the searched device) appear. The object can be dragged&dropped to the ‘Database’ window.
Figure 6. Importing historical data from the device communicating in the BACnet protocol
Having moved selected historical data to the ‘Database' window, the pop-up window appears allowing to configure the objects. Focus in particular on:
synchronization method (the ‘Execution Time’ slot) - manual/daily/cyclic modes are available; the manual mode can be linked to a logic or action invoked, while the other two require specifying days/hours/periods of execution;
historical capacity (the ‘Capacity’ slot') - WARNING: if historical data are synchronized to another controller, the number of records have to be specified (‘Record Count’ = X, where X is a number), however, if the synchronization is to the Supervisor, set on a powerful server, it is possible to consider an unlimited number of records ('Unlimited'); still, it is recommended to limit a number of records;
time zone (the ‘Time Zone’ slot) - values are automatically converted to the selected time zone;
local name of historical data (the ‘Local History Name Format’ slot) - the ‘%name%’ value copies the value from the ‘Name’ slot, however, for better sorting of data, it is recommended to add a prefix (in the described example, the ‘MAC36NL_%name%’ prefix has been set):
Figure 7. Configuration of the historical datum in the BACnet protocol
After adding historical data, the first synchronization is forced automatically, and each next is executed according to the method set in the ‘Execution Time’ slot.
In the station, where the import of historical data has been carried out, the data are saved in the ‘History/Device_name_i_BACnetID’ location (in the described example, it is ‘History/BACnet_test_828247’):
Figure 8. List of historical data imported in the local station from the remote BACnet device
Now, the data (in the importing device, e.g., Supervisor) are a copy of the data in the exporting device (e.g., the iSMA-B-MAC36NL controller), but only for the moment of synchronization. Showing fresh historical data in the importing device requires an additional action-invoked synchronization or waiting until the next automatic synchronization. Each next synchronization adds new records in the importing device. For example, in the exporting device the records limits is set for a week, and in the importing device the number is records is unlimited. Old data have been overwritten in the exporting device (a week of registering data has passed). During synchronization in the importing device, the old data are left, and the new ones are added.