Contents

Json Export Marker

Export Marker: Selecting Control Points

Selection of Control Points to export can be achieved either using:

The Json Export Marker offers several benefits beyond just marking points to include in a Relative Schema. For example they can be used to support export of alarm or history data related only to points with an Export Marker present. Or to store a unique identifier supplied by a third party platform. This can be used differentiate between registered points with an id and unregistered without an id. An example use case is sending different payloads prior to registration, for example including more detailed information (units, min/max, descriptive tags) than should be sent upon every change of value.

When applied to a Numeric point a Json Export Marker also introduces a tolerance property to reduce unwanted updates from the station if a value changes only slightly.

The export marker can also be used with incoming json payloads: - Export Setpoint Handler - Export Registration Handler

Property Overview

Property Description
id This value allows an id to be provided from the cloud platform. The expectation is that this value will be unique, at least within each station as it may be used by the cloud platform as a primary key
sendHistorySince Filter should discard history records from before this date
sendAlarmSince Filter should discard alarm records from before this date
platformWritable Used with setpoint/override feature to prevent writes from the upstream platform
Tolerance Only appears for Export Marker on Numeric Points. Prevents generating updates inside the given tolerance

Relative Schema Configuration

Base Query: station:|slot:/|bql:select * from jsonToolkit:JsonExportMarker

Example Bound Property Binding Ord: slot:.. (References the parent of the JsonMarker Base)

Export Marker Filters

Both Filters belows have a Send Since action which allows alarms or histories since a given date to be exported. This feature might be useful following network disruption or during initial commissioning of a system.

The Send Since action allows a specific start time to be specified, and only records stored on or since this time will be considered for output in the linked Schema.

Common Properties Description
Current Export Id Allows a description of the Export Marker currently being exported to be included if linked to a FixedString in the Schema
Count How many export marked points where processed in the last invocation. Resets when station restarted

Alarm Export Marker Filter

The Alarm Export Marker Filter allows alarms generated by the station to be filtered before they are passed to a recipient. Typically that would be a Json Alarm Recipient, but it could be SNMP, BACnet etc. with the source Alarm Class being linked to the in slot of the filter.

AlarmFilter

Filter Modes Outputs Alarms
Marked With Id If the Source has an Export Marker present, with Id set
Marked If the source has an Export Marker present
Pass All All Alarms
Block All No Alarms

In the context of alarming the filtering occurs normally on alarms passed from the alarm class as they are generated.

The Send Since action will query the alarm database and pass existing records in to this filter (inclusive of the supplied timestamp) so that they can be checked for a suitable Export Marker and then passed to the receiving Json Schema as required to create a new record for each alarm. The timestamp being in the past should help identify when this mode is active.

Note: To prevent accidental data deluge, send since will not function if the filter is in Pass All mode. A bql Query on the alarm db could be used if this is a requirement.

History Export Marker Filter

Allows the export of history data for points with an Export Marker.

There is some overlap with Relative History Query which can select history for points using many different selection criteria, or an appropriate Base Query may also be used to generate history for each export marked point. The History Export Marker Filter allows updating of the timestamp stored on each Export Marker, so only ‘recent’ history records will be sent to the remote system (typically records added since the last export).

The JsonSchema nested under the filter determines the payload format, and the output from that Schema should be linked to a target transport point to complete export.

The History Export Marker Filter adds a new Query to the Queries Folder of the Schema beneath if one does not exist already.

This query will need to be referenced by a Bound Query Result

In the event that an Export Marked point has more than one history extension beneath it, then each will be exported in turn.

In most cases it is likely the Current Export Id property will need to be linked into the Schema output to provide identifying information, or even the query used to select data may be included if the target system could infer useful data from it.

Note: Because the Export Marker relies on being added to a local Control Point in the station, it is not possible to match histories imported over BACnet or Niagara Network using this method, a Relative Schema should be used instead.

Actions

Send Since Last Export: Can be used to send only unsent history data, using the timestamp stored on each Export Marker.

Properties

Property Description
History Export Filter This is the Json Schema used to produce output
Current Query The query being fed into the Schema below. The first query in the Queries Folder will be linked on start, doesn’t have to be the only one, or output first in the json schema
Columns CSV, for example: timestamp, value, status
Update Send Since Time Should the most recent send time be updated when data is generated, enables sending only changed records on next run. If true, then every time history is exported the timestamp stored on each Export Marker is updated.