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 | 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 |
Base Query: station:|slot:/|bql:select * from jsonToolkit:JsonExportMarker
Example Bound Property Binding Ord: slot:..
(References the parent of the JsonMarker Base)
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 |
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.
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.
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.
Send Since Last Export: Can be used to send only unsent history data, using the timestamp stored on each Export Marker.
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. |