Step 1: Setting up JSON Toolkit for JACE devices

Install jsonToolkit module on Jace. For the jsonToolkit to publish, the Jace must have an active service maintenance agreement.

Under Station: Config, right-click and create a new folder called DchSchema. Change to Wire Sheet view if not already (select this view on the top right corner of the WorkPlace UI).

The schema utilises 3 components:

• IntervalTrigger to generate the schema at regular time intervals (1m, 5m, 10m or 15m). The trigger sends out a “pulse” at the user defined interval and this triggers the RelativeJsonSchema to read the point values and create the json files.

• RelativeJsonSchema which generates the schema

• EngineCycleMessageQueue which buffers the schema output messages and sends to the MQTT publish point.

• The output of the EngineCycleMessageQueue is linked to an AbstractMqttDriverDevice (json format) which publishes the data to Senaps.io. Refer to the next section for setting up the MQTT driver.

NOTE: If there are multiple polling cycles for different points (i.e. some points are polled fast, others slower), there will be additional RelativeJsonSchema and trigger functions. These are described in more detail in the Base Query using DchTags for Different Polling Intervals section, later in the document.

Interval Trigger

In Palette, open the control palette. Drag Interval (from the Trigger folder) into the Wire Sheet of DchSchema.

Double click the Interval and select the desired time interval. Set up initially for 10min.

Trigger Mode: Interval

Interval: 0000h XXm 00s

Use defaults for time of day, days of week.

Right-click inside the Interval Property Sheet and select Pin Slots Fire Trigger. This will add the Fire Trigger slot to the Interval box which will be linked to the RelativeJsonSchema box in a later step.

EngineCycleMessageQueue

An engine cycle is the JACE running through all the programmed station logic in a sequential manner, and then repeating the cycle perpetually. This usually takes several milliseconds depending on how many processes the station incorporates.

The engine cycle message queue places a pause (user-defined, usually 20-50ms) between each engine cycle and safeguards against publishing two messages at the same time.

In palette, open the jsonToolkit palette. From Queues folder, drag EngineCycleMessageQueue into the DchSchema Wire Sheet.

Right-click on the EngineCycleMessageQueue box and select Pin Slots Enqueue. This slot will be linked back to the Relative Json Schema box in a later step.

The EngineCycleMessageQueue has some default settings that are hidden and may need to be changed. Double click on the EngineCycleMessageQueue and change the view to Property Sheet (top right of UI).

Click on Slot Details (top right of UI) and then click on Hidden Slots. This will show the hidden slots.

Click on the flags for Rate and Max Size and deselect the Hidden flag. The Flags for Rate and Max Size should change to (none) and will show up on the AX Property Sheet.

Max Size needs to be set larger than the total number of points being published by the JACE.

The Rate should be set higher than the average Time/scan (cycle time). This value can be found by double clicking on the Station in the station tree. A Station Summary window will appear. Double click on Spy, then sysManagers, then engineManager (Station: Spy: sysManagers: engineManager).

The value to look for is averageTime/scan at top of the window. If the time is too low, it may overload the CPU, so try to stay above 20ms.

DCH Schema Setup

There are three things that the schema must do:

1. Publish point data that is current and not stale. This is done by ensuring points are subscribed.

2. Select and publish the required point data only. This is done using the Json Base Query.

3. Publish the data in the correct json format. This is done by adding and configuring the { } Root fields in the AX Property Sheet.

JSON Schema point subscription and stale data (as well as setting up histories)

NOTE: Before setting this, make sure you have determined the publish interval of the jsonToolkit from the previous section. The History interval will be set at the same value typically.

The jsonToolkit RelativeJsonSchema has two polling options CoV (Change of Value) and OnDemand (set interval polling). CoV subscribes to the points, but OnDemand does not. DCH requires OnDemand polling.

Using RelativeJsonSchema with OnDemand polling does not subscribe to points. In order to ensure points are subscribed, and stale data is not being published, a mechanism for ensuring the points subscriptions are maintained is required.

Subscriptions can be maintained by adding history extensions to each point or using a second RelativeJsonSchema block with CoV polling.

COV Polling

NOTE: This method is not preferred but may be used for non-critical applications.

Drag BooleanDelay from kitControl: Timer Palette into Station: Config: DchSchema, Wire Sheet View.

Double click and set ON and OFF delay both to one second.

Link BooleanDelay: Out RelativeJsonSchema: Generate Json

The Boolean delay triggers every second and subscribes to all points. The output is not published to MQTT, it is just used to force the JACE to maintain point subscriptions active on all points.

Adding Histories (and Interval Polling)

This process will batch add history extensions to all points in a file/directory.

The process summary is:

1. Use the batch editor to find the points of a certain type (i.e. Boolean or Numeric etc) that are to be uploaded to DCH.

2. Apply the appropriate history extensions to all the points in a batch process.

3. Apply the jsonToolkit ExportMarker to all the point in a batch process.

4. Clear the batch editor.

5. Repeat the process with the next required point type until all required points are processed.

The history extensions save point data locally on the JACE but also ensure the point is subscribed. If the point is not subscribed the jsonToolkit will read stale data.

The jsonExportMarker extensions allows you to select which points you want exported but also is required by the HistoryExportMarkerFilter to find the associated point history (via its history extension).

Single Points

If configuring single points, open the History palette.

Navigate to Extensions and expand to see the types of history extensions. They are point type dependent.

Click and drag the appropriate point extension onto the point to be added to histories.

Configure the history extension as per the configurations shown in the next sections.

Batch Editor

Go to Station: Config: Services: ProgramService and double click to bring up the Batch Editor.

Click the Find Objects button to bring up the Bql Query Builder.

Point History Extensions

Set the Of Type: Box to Control Point. More specific point types such at Boolean Point can be selected if desired.

Select the location in the In: box by clicking on the magnifying glass. The screen shot below shows a query that will select all Points types in Config: Drivers: BacnetNetwork (i.e. all

points with the selected type).

Important: As the history extensions are point type specific (BooleanIntervalHistoryExt, NumericIntervalHistoryExt, etc.) the batch additions need to also be by point type.

Start with Boolean Point, then repeat for Numeric, then Enumerated, String, Schedule as required.

Click OK to run the query.

NOTE: Sometimes it may be necessary to apply the history extensions in smaller batches, e.g. one Modbus Device at a time.

Check the list of points. Right-click on points and select Clear Selected Items to remove any unnecessary points.

At the bottom of the Batch Editor, click Add Slot

Important: Set Enabled to true. This will be reset to false in a later step, prior to running baja code to change histories to non-critical.

New Name	BooleanInterval or similar
Enabled	True
History Name	%parent.parent.name%_%parent.name% NOTE: If you don’t change the name it’s probable that multiple histories will have the same name and some histories won’t be created. This will occur when different devices have the same point names within them (e.g. power meters). The change adds the device name to the History name and reduces the chance for duplicates.
Interval	match JsonToolkit write interval (1, 5, 10 or 15 minutes)
Capacity	Record Count, around 3 days’ worth of records
Full Policy	Roll will continually overwrite the values after the record count is exceeded to prevent memory filling up.

Click OK to apply the extensions. Under Station: History, the histories should appear.

Check the history names. Some may be in the form points_MqttLibbiStateCmdText. If so, find the point in the navigation tree, double click on the History extension and change the point name back to %parent.name%. Note the History Name has maximum of 44 characters, so %parent.parent.parent.name%_%parent.name% isn’t possible.

NOTE: The Jace may disconnect from the Supervisor PC. If so, wait a couple of minutes, then reconnect to the Station.

Point ExportMarker

While the points have been selected with Bql Query Builder add the jsonToolkit ExportMarker.

1. Click Add Slot

2. Name the new slot ExportMarker

3. Select jsonToolkit for point type

4. Select JsonExportMarker

This marker (Tag) will be used in the json Schema Base Query to select all points in the Jace that are onboarded to Senaps.

Click Remove Slot and click on the dropdown to check whether any slots have been accidentally added twice. If so, select and remove the duplicates.

Press Clear All in the Batch Editor window.

Setting Histories to Non-Critical

If this process is not performed, the Niagara Backup Service will eventually report errors.

The code in this section needs to run on the Histories, not the History extensions. As such, the histories need to have been enabled to create the histories. Unfortunately, the histories must be disabled prior to running code to batch set them to non-critical.

If history extensions are enabled, an error with running the code will occur while trying to follow this process. To avoid the error, use Batch Editor to search for all points with history extensions using Bql Query Builder.

Click Edit Slot at the bottom of the Batch Editor, In the Edit Slot window, set Property to BooleanInterval (or the data type Interval), and set Boolean Interval History Ext Enabled to false.

Then click OK.

Repeat for other Point types (Numeric, String etc.).

Click Edit Slot at the bottom of the Batch Editor, In the Edit Slot window, set Property to NumericInterval (or other point types), and set Numeric (or other point types) Interval History Ext Enabled to false.

The Click OK. The Station may disconnect. If so, wait a few minutes and reconnect.

Repeat for other point types and folders if required.

Run the Code

Go to Station: Config: Services: ProgramService and double click to bring up the Batch Editor

Under ProgramService (1), change your view to Robot Editor (2), copy and paste the code (on the next page) (3) and press Run (4)

Baja Code

Ensure you copy the entire code on the next page. If the code doesn’t run, ensure you’ve included the closing bracket and a carriage return after the closing bracket.

// depends: baja; program; history

import javax.baja.collection.*;

import javax.baja.naming.*;

import javax.baja.sys.*;

import javax.baja.history.*;

import com.tridium.program.*;

public class RobotImpl

extends Robot

{

public void run()

throws Exception

{

BHistoryConfig history = null;

BOrd hqord = BOrd.make("history:/|bql:select *");

BITable<BHistoryConfig> hresult = (BITable<BHistoryConfig>)hqord.resolve().get();

TableCursor<BHistoryConfig> h = hresult.cursor();

while(h.next()) {

history = h.get();

String historyName = history.getId().getHistoryDisplayName();

log.println("setting non-critical flag on " + historyName);

Slot idSlot = history.getSlot("id");

history.setFlags(idSlot, history.getFlags(idSlot) | Flags.NON_CRITICAL);

}

}

}

Checking Code Executed Properly

A log report window will pop up after the code runs.

Copy all the lines in the log report and paste them into Excel.

Check that the number of lines in the log report matches the number of points (within say 1%).

Go to Station: History

Right-click on a point history and select Views AX Slot Sheet

Right-click on the first Property (Id) and select Config Flags.

Check that the Non-Critical flag is ticked. Check multiple histories and try to check NumericInterval, BooleanInterval and other point type Interval histories.

Re-Enable History Extensions

Click Config: Services: ProgramServices to open the Batch Editor.

Click Find Objects and select all Boolean Points.

Set Enabled to true and adjust other settings as required.

Click OK. Reconnect to the JACE if required.

Click Clear All in the Batch Editor.

Repeat for other Point types.

Check History Extensions

Wait several intervals (say 30 minutes)

Go to Station: History: <PointName>

Double click on the history to bring up the Chart.

Check new data has been added.

Right-click on a history and select Views AX Slot Sheet

Right-click on the first Property (Id) and select Config Flags.

Check that the Non-Critical flag is ticked. Check multiple histories and try to check NumericInterval, BooleanInterval and other point type Interval histories.

Point selection using Tags

If you have a single JACE doing various polling intervals and/or multiple sites, it is convenient to apply custom tags to points. The RelativeJsonSchema Base Query can then be configured to select and direct different points from a larger group of exported points.

This works as follows:

Apply the jsonToolkit ExportMarker to ALL points in the JACE that will be published to a MQTT broker.

Apply specific tags to points to allow them to be selected as groups.

Setup the tags as follows:

1. Expand the Nav tree and double click on Station: Config: Services: TagDictionaryService .

2. Click New at the bottom of the window.

3. Add a Tag Dictionary, Qty 1 and click OK.

4. Rename the dictionary to DchTagDictionary and namespace as dch and press OK.

5. Open the tagdictionary in palette.

6. In the palette, expand the Tags tree.

7. Drag the Marker tag into Station: Config: Services: DchTagDictionary: Tag Definitions

8. Rename the tag dchStdPoll

9. Drag additional Marker tags in from the palette and rename to dchFastPoll, dchVfastPoll, dchSlowPoll

This will provide a number of different query options in the RelativeJsonSchema’s for varying polling intervals.

1. Repeat the process and drag additional Marker tags in from the palette and rename to dch<SiteName1>, <dchSiteName2>, dch<SiteName3> etc

This will provide a number of different query options in the RelativeJsonSchema’s for points from different sites.

Generally, assign the tags as follows:

DchTag	Usage
dchStdPoll	5min, 10min, 15min
dchFastPoll	30sec < Poll < 5min
dchVfastPoll	≤ 30s
dchSlowPoll	15min < Poll ≤ Daily
dchVslowPoll	Daily, weekly
dchSiteName1	First site being polled by the Jace
dchSiteName2	Second site being polled by the Jace
dchSiteName3	Third site being polled by the Jace

Add tags manually (right-click on each point and select Edit Tags) or use the batch editor:

In Station: Config: Services: ProgramService use the Bql Query Builder to select appropriate points, then use the AddTag button to batch add tags. There are several things to note:

1. You can manually select and clear points (hold shift to select a block of points) and right-click and select Clear Selected to remove them from the batch to be modified.

2. You have to right-click and select Clear All in the window before applying other tags to a different set of points.

3. You can remove a tag by removing a slot, and then selecting the slot with the tag name, e.g. dch$3adchStdPoll.

4. If you rename a tag in the dictionary, the slot name does not update. You need to batch remove the old slots and then batch add the new tag.

JSON Base Query

The base query selects which points are to be published by the schema. It can be configured in a number of ways which are described below. There is only one base query per JsonSchema.

The BQL query builder method allows you to select a location and the type of points you wish to include. It is a quick and easy method for some Stations where:

1. There are only BACnet points to be published

2. There are only Modbus points to be published

This method becomes problematic under the following conditions:

1. Points from multiple locations, e.g. for BACnet AND Modbus points, the location needs to be Drivers, however this will also pick up any additional driver points such as the MQTT publish/subscribe points.

2. There is a folder containing logic blocks (and, or, statusDemux etc) as these are considered control points and will be published.

There are ways to limit which points are found by the query. These are detailed below, and further examples are provided in DCH JACE BQL Examples document.

Using ExportMarker

This is the quickest method as it uses the existing Json ExportMarker applied as part of the DCH JACE History Configuration and allows one JSON schema to select points from multiple drivers (BACnet, Modbus, JACE soft points). In the base query field, copy and paste the following text.

station:|slot:/|bql:select * from control:ControlPoint where ExportMarker != 'NULL'

The process for applying the ExportMarker tag to all points is described in previous sections, as it is the same process as adding history extensions.

The query will look for all points in the station marked with the ExportMarker tag.

Using DCHTags for different polling intervals

If there are multiple polling intervals being used in the JACE you’ll need to apply different tags to the various points based on polling interval. Multiple JSON schemas can be configured, with each with its own specific points and specific trigger interval. Each Json Schema base query searches for points with a specific tag.

In the Relative JSON Schema base query for each RelativeJsonSchema, copy and paste the following text:

station:|slot:/Drivers|bql:select * from control:ControlPoint where dch$243adchPoint != 'NULL'

Then change dchPoint to one of the tag names, e.g. dchStdPoll. This will then search the whole Station for Control Points which have the dchStdPoll tag from the dch tag dictionary applied. Note the $243a is used to replace the colon in the slot name, i.e. dch$243adchStdPoll looks for points that have the dch: dchStdPoll slot.

The Bql version of the query is shown below, change dchPoint to the relevant tag, e.g. dchFastPoll.

Configure the multiple triggers and schemas as follows (only include the required functions):

EngineCycleMessageQueue

Slow Trigger

Std Trigger

Fast Trigger

JsonSchemaVfastPoints

Base query:

dch$243adchSlowPoll

JsonSchemaStdPoints

Base query:

dch$243adchStdPoll

JsonSchemaFastPoints

Base query:

dch$243adchFastPoll

JsonSchemaVfastPoints

Base query:

dch$243adchVfastPoll

Vfast Trigger

Using DCHTags for different sites on one JACE device

If one JACE is servicing two or more sites, it is likely the MQTT packets will need to be published to separate topics for each site. This requires separate AbstractMqttDriverDevice for each site, and therefore separate RelativeDchSchemas and EngineCycleMessageQueues.

Create a dch tag for each site, e.g. dchNewcastle, dchWerribee etc.

station:|slot:/|bql:select * from control:ControlPoint where ExportMarker != 'NULL' and dch$243adchNewcastle != 'NULL'

NOTE: If you have only applied the siteName tag to points to be exported, you can remove the ExportMarker != NULL condition from the above query.

EngineCycleMessageQueue for Site 2

EngineCycleMessageQueue for Site 1

Std Trigger

JsonSchemaSite2

Base query:

dch$243adchSiteName2

JsonSchemaSite1

Base query:

dch$243adchSiteName1

Using DCHTags for different sites and different polling intervals on one JACE device

It is possible to combine both polling speed and site name tags if required. The DchSchema wire frame will have multiple Triggers, multiple RelativeSchemas and multiple EngineCycleMessageQueues linked to multiple AbstractMqttDriverDevices.

There will need to be one EngineCycleMessageQueue for each site.

There will need to be one Trigger for each polling interval.

There will be multiple RelativeJsonSchema’s in between, one for each unique combination of polling interval and site.

JSON Schema Configuration

In the palette open the jsonToolkit palette.

Drag {..\} RelativeJsonSchema component from the palette to the DCH Schema folder Wire Sheet. Change the name to the following format:

DchSchemaXxxxxYyyyy

Xxxxx options:

Modbus for querying Modbus points

BACnet for querying BACnet points

FolderName for querying control points in a local folder

Yyyyy options:

Basic for pointName, timestamp, currentValue, status, facets(units)

Simple Basic fields and also, $schema, parentName, modbusProperties, tags

Full Simple fields and also gatewayName, gatewayModel, gatewaySoftwareVersion, siteName, buildingName, ord, proxyExtProperties, bacnetProperties

Examples:

DchSchemaModbusSimple This schema generates Modbus point data in Config: Drivers and includes the Basic and Simple metadata fields.

DchSchemaHomeBasic This schema generates point data for control points in Config: Home folder and includes the Basic metadata fields.

DchSchemaBacnetFull This schema generates point data for control points in Config: Drivers folder and includes the all metadata fields.

Right-click on the Relative block in Wire Sheet View and select Pin Slots Generate Json. This will add the Generate Json slot that will link to the Interval trigger in a later step.

Right-click on the Relative block and select Pin Slots Schema Modified

Fill out the RelativeJsonSchema fields. The table below shows the fields and which ones are to be used for Basic (B), Simple (S) and Full (F) schemas.

In order to add all the fields, drag in the following objects from the jsonToolkit palette as required:

Object Type	Folder	Name in palette
Json Schema String Property	Properties	{ } FixedString
Json Schema Bound Property	BoundProperties	{*} BoundProperty
Json Schema Object	Objects	{ } Object
Json Schema Tag Property	BoundProperties	{ } Tag
Json Schema Current Time Property	Properties	CurrentTime
Json Schema Facet List	BoundProperties	{*} FacetList

Field	B	S	F	Entry
Enabled	Y	Y	Y	true
Config, Name Casing Rule	Y	Y	Y	Camel
Config, Name Spacing Rule	Y	Y	Y	Remove
Config, Date Format Pattern	Y	Y	Y	yyyy-MM-dd’T’HH:mm:ss.SSSXXX Remember to add the ‘T’ and the SSSXXX
Config, Use Escape Characters	Y	Y	Y	false
Tuning Policy, Write On Start	Y	Y	Y	false
Update Strategy	Y	Y	Y	On Demand Only
Schema Output History Debug, Enabled	Y	Y	Y	true
Queries, Publish Interval	Y	Y	Y	00000h 00m 00s
Base Query, Base Query	Y	Y	Y	Refer to “Point selection using Tags” section
Base Query, Publish Interval	Y	Y	Y	00024h 00m 00s
45a77e8c06e94afcaf5626fe257addc4
{ } root	Y	Y	Y	Json Schema Object
Root, { } $schema (for Full)			Y	Prior to setting this up check with Senaps administrators the correct schema. Json Schema String Property String Value: http://csiro.au/dch/bms-json/schema-draft-04.json
Root, { } $schema (for Simple)		Y		Json Schema String Property String Value: http://csiro.au/dch/bms-json/schema-draft-05.json
Root, { } $schema (for Basic)	Y			Json Schema String Property String Value: tba
Root, {*} gatewayName	N	N	Y	Json Schema Bound Property Navigate to: station:|slot:/Services/PlatformServices/SystemService/stationName
Root, {*} gatewayModel	N	N	Y	Json Schema Bound Property Navigate to: station:|slot:/Services/PlatformServices/SystemService/product
Root, {*} gatewaySoftwareVersion	N	N	Y	Json Schema Bound Property Navigate to: station:|slot:/Services/PlatformServices/SystemService/niagaraVersion
Root, { } siteName	N	N	Y	Json Schema String Property Enter the site name
Root, {} BuildingName	N	N	Y	Json Schema String Property Enter the building name
Root, { } point	Y	Y	Y	Json Schema Object
Point, { } pointName	Y	Y	Y	Json Schema Tag Property Binding: slot: Tag Id: n:displayName Search Parents: false
Point, timestamp	Y	Y	Y	Json Schema Current Time Property
Point, {*} currentValue	Y	Y	Y	Json Schema Bound Property Binding: slot:out/value Json Name Source: Display Name
Point, {*} status	Y	Y	Y	Json Schema Bound Property Binding: slot:out/status Json Name Source: Display Name
Point, { } ord	N	N	Y	Json Schema Tag Property Binding: slot: Tag Id: n:name Search Parents: false
Point, { } parentName	N	Y	Y	Json Schema Tag Property Binding: slot:.. Tag Id: n:name Search Parents: false
7b0280307c3649d9b347c79822d81506
Point, {*} facets	Y	Y	Y	Json Schema Object Binding: slot: Facet Csv list: * Write Empty Strings For Missing Facets: false
Point, { } proxyExtProperties	N	N	Y	Json Schema Object
proxyExtProperties, {*} status	N	N	Y	Json Schema Bound Property Binding: slot:proxyExt/status Json Name Source: Display Name
proxyExtProperties, {*} faultcause	N	N	Y	Json Schema Bound Property Binding: slot:proxyExt/faultCause Json Name Source: Display Name
proxyExtProperties, {*} enabled	N	N	Y	Json Schema Bound Property Binding: slot:proxyExt/deviceFacets Json Name Source: Display Name
proxyExtProperties, {*} deviceFacets	N	N	Y	Json Schema Bound Property Binding: slot:proxyExt/enabled Json Name Source: Display Name
proxyExtProperties, {*} conversion	N	N	Y	Json Schema Bound Property Binding: slot:proxyExt/conversion Json Name Source: Display Name
proxyExtProperties, {*} turningPolicyName	N	N	Y	Json Schema Bound Property Binding: slot:proxyExt/turningPolicyName Json Name Source: Display Name
proxyExtProperties, {*} readValue	N	N	Y	Json Schema Bound Property Binding: slot:proxyExt/readValue Json Name Source: Display Name
proxyExtProperties, {*} writeValue	N	N	Y	Json Schema Bound Property Binding: slot:proxyExt/writeValue Json Name Source: Display Name
0430424c5ad44d43bad9e62837cc3702
Point, { } BacnetProperties	N	Y	Y	Json Schema Bound Property
BacnetProperties, {*} objectId	N	Y	Y	Json Schema Bound Property Binding: slot:proxyExt/objectId Json Name Source: Display Name
BacnetProperties, {*} propertyId	N	N	Y	Json Schema Bound Property Binding: slot:proxyExt/propertyId Json Name Source: Display Name
BacnetProperties, {*} propertyArrayIndex	N	N	Y	Json Schema Bound Property Binding: slot:proxyExt/propertyArrayIndex Json Name Source: Display Name
BacnetProperties, {*} dataType	N	N	Y	Json Schema Bound Property Binding: slot:proxyExt/dataType Json Name Source: Display Name
BacnetProperties, {*} readStatus	N	N	Y	Json Schema Bound Property Binding: slot:proxyExt/readStatus Json Name Source: Display Name
BacnetProperties, {*} writeStatus	N	N	Y	Json Schema Bound Property Binding: slot:proxyExt/writeStatus Json Name Source: Display Name
Point, {*} tags	N	Y	Y	Json Schema Tag List Binding: slot: Dictionary Namespace Filter: Haystack Tag Id List Filter: * Include Name Space: true
86515c8606194ab19b3fd67e17f6ed1d

History Export via MQTT in JSON format

Once Histories have been setup as per DCH JSON History Service Configuration a history export can be configured as follows. This will schedule a daily (variable) dump of all history data via MQTT.

NOTE: It may be preferred by Dch to use a CSV export of histories. Confirm this with Dch and for the CSV method, refer to the DCH JSON History Service Configuration document.

History and JsonExportMarker Extensions

In the DCH Schema folder create a new RelativeJsonSchema which has a base query to retrieve all points and output a JSON with two keys: niagaraId is the handleOrd of the point, platformId is whatever identifier you’d like to create which makes it unique on the cloud side. I’ve used:

parent.parent.displayName + ‘/’ + parent.displayName.

1. In the same location, add a JsonExportRegistrationHandler and link the output of the relative schema above to the Route input of this handler component. Leave everything as default.

2. Right-click on the PointRegistrationSchema block and select Actions Generate Json on to then push all JSON into the handler and register all export markers with their new Id.

3. Add a HistoryExportMarkerFilter to anywhere in the station (better to add to Station: Config: DCHSchema folder).

   - Add a blank Query from the jsonToolkit palette: Query: Query to the Queries (Station: Config: DCHSchema: HistoryExportMarkerFilter: History Export Filter) folder (it will get filled in automatically)

- Set the Update Send Since Time property to true in Station: Config: DCHSchema: HistoryExportMarkerFilter (Property Sheet view)

- Add a BoundProperty from the json Toolkit palette: BoundProperties to Station: Config: DCHSchema: HistoryExportMarkerFilter: History Export Filter: root: point which is bound to the currentExportId property of itself

- Add a BoundQueryResult from the jsonToolkit palette: Query to Station: Config: DCHSchema: HistoryExportMarkerFilter: History Export Filter: root: point which is linked to the blank Query

The final AX Property Sheet view of the History Export Filter should look like below.

1. Link the output of the HistoryExportFilter (embedded inside the HistoryExportMarkerFilter found in Station: config: DCHSchema (Wire sheet)) to the existing Message Queue for sending to MQTT. To do this, open the HistoryExportMarkerFilter in Wire Sheet view and then open History Export Filter in Relation Sheet view.

2. Trigger the Send Since Last Export action (Actions Send Since Last Export) on the HistoryExportMarkerFilter component (Station: Config: DCHSchema (Wire Sheet)) and it should push all the history data out via MQTT, and also store the last record sent inside the export marker. You can now add a Time Trigger to call this action (like you’ve done in the original station) however you can set it to once per 30min or 1 hour instead, which should save on CPU and memory loading of the JACE.

Hopefully this solution is suitable and meets your requirements, as long as the JACE is online and the fieldbus is operational it will continue to log histories and pushing to queue. Once connectivity is back online the queue will push out via MQTT whatever was buffered inside.