Cloud History Device Ext (nCloudDriver-CloudHistoryDeviceExt)

Similar to points, histories can be pushed to the cloud.

Using the Cloud History Device Extension, click Discover to show all histories and allow selections to be added the device database for export to the cloud platform. When this is done, you can set a time period for how often to send that data. All data is queued on the station/Supervisor until that period expires. When it expires, the histories are bundled into 500-record bundles and sent to the cloud platform. The default bundle size is 500, but it is configurable via the History Batch Size property.

Learn Histories action

The automatic Learn Histories action provided by the CloudHistoryDeviceExt creates a CloudHistoryFolder for each HistoryDevice it finds in the station’s history database, including the local station. This helps organize the potentially large number of history exports into a logical structure. It will also provide some performance improvement for extremely large stations by decreasing the number of children in a single container.  The Learn Histories action is strongly recommended over standard history discovery and adding, as it will help avoid creating duplicate history exports for a single history.

 CAUTION: If you create two cloud history exports for a single Niagara history, you will end up causing overlapping records in the Honeywell Forge database, which will result in missing or incomplete data for cloud-based applications. For this reason, we suggest reducing the likelihood of duplicate exports by using the Learn Histories workflow. 

Cloud histories and restored connectivity

When the station is disconnected from the cloud for any reason, history records are not pushed to the cloud.  After reconnecting, sending history records to the cloud resumes. In order to avoid problems that can arise with excessive bandwidth usage, the driver will NOT necessarily send every record that has not yet been sent. The maxBackfillDuration property describes how far back the driver will look within each history to begin sending records. 

For example, consider a history collecting records every 15 minutes at :00, :15, :30, and :45 past the hour, and a maxBackfillDuration setting of 1 hour.

  • The station loses connectivity at 11:58pm.  Records continue being collected locally at 12:00, 12:15, etc.
  • At 3:50, connectivity is restored.  There are now 16 unsent records, with timestamps 12:00, 12:15, 12:30, ... 3:30, and 3:45.
  • The records that will be sent to the cloud are timestamps 3:00, 3:15, 3:30, and 3:45.  The records 12:00 through 2:45 are not sent

The station output will contain one or two log messages whenever cloud history export backfill is limited by this mechanism. The first message indicates that the lastSentToCloud timestamp is being checked on all history exports, using the calculated backfill starting point. For example, after the cloud connector reconnects, you will see a message like this in station output, provided you have FINE or higher configured for the ncloud.history logger:

FINE [3:50:56 PM 24-Jan-19 EST][ncloud.history] Checking lastSentToCloud on history exports using backfill start 24-Jan-19 2:50 PM EST

This does not mean anything is being changed, only that the comparison is being made. If no exports exist, or if the lastSentToCloud on all exports is already later than the calculated backfill start time, then nothing further will be logged.  If any cloud history exports have a lastSentToCloud that is earlier than the backfill start time, their lastSentToCloud will be updated with this new time. The number of exports modified will be totaled and included in a second log message.  For example, you would see a second message like this:

INFO [3:50:57 PM 24-Jan-19 EST][ncloud.history] The backfill start time of 24-Jan-19 2:50 PM EST was used to set lastSentToCloud on 17 history exports; history records earlier than this will not be sent to the cloud!

Note that the first message will be printed any time the connector connects, including on renewal of the access token.  For normal system configuration, this will not result in skipping the export of any history records to the cloud, as the backfill duration is generally much longer than the history export batch trigger interval.

Note that any time the lastSentToCloud is adjusted by the backfill limitation mechanism, the history export's lastSentToCloud property will be set; this may not reflect that a history record was actually sent. For example, if the history export is disabled, its lastSentToCloud may still be adjusted to prevent sending too many records if it is subsequently enabled.

Figure 47.   Cloud History Device Ext properties
Image

To access these properties, expand Config > Drivers > NiagaraCloudNetwork > CloudSentienceDevice, right-click Histories and click Views > AX Property Sheet.

Name Value Description
Last History Timestamp read-only timestamp
Shows the date and time the last history record occurred.
Batch Trigger Time time trigger additional properties (Interval defaults to 15 minutes, Time of Day, Days of Week)
Sets either the history Interval or individual history items to Batch Trigger mode, but does not set both. For efficiency, use this property with Interval while setting the individual history items to Manual mode.

Leave this property set to its default or greater. Reducing this value causes a warning in the station output. Unintended consequences could occur under some conditions. Obtain guidance from your Support channel prior to adjusting this value.

 CAUTION: Setting the Interval time to less than 15-minutes may cause several unintended results, such as message throttling by the Sentience IoT Hub and/or prevention of more important messages (such as alarms) from being sent, etc.  
Trigger Mode interval (default), daily, manual Determines when a TimeTrigger will fire its trigger. Interval fires a trigger each time the specified interval has elapsed. Intended for use when firing the trigger several times per day (e.g. every 5 minutes). Daily allows the trigger to be fired at a specific time on selected days of the week. Also, provides randomization interval so that the trigger is not fired at exactly the same time every day. Manual requires human interaction to fire a trigger.
Batch History Size 500 (default) Number of history records to include in a single message to the cloud platform. Acceptable range is 100–10,000 records.
Max Backfill Duration RelTime (default 1 hour) Specifies the maximum duration of record backfill that will occur when the connector is reconnected after a disconnection.

This can be disabled by setting it to a very high number. For example: setting it to 90000 hours (10 years) causes all Cloud Export components to retain the value of "Last Sent to Cloud" which they had before the device lost connectivity. However, this is not recommended in conditions of high-volume batch history exports.

 CAUTION: The Max Backfill Duration should always be more than twice the Batch Trigger Time. (For example: If Batch Trigger Time Interval is adjusted to 30 minutes, Max Backfill Duration should be remain at 1 hour, or more.). 

Actions

Following are the three actions:

  • Retry — downloads the history again.
  • Ping Last History — Displays the last history record.
  • Execute — executes the selected history.