Introduction

JSON (JavaScript Object Notation) is a simple, lightweight, data encoded string. Used for data interchange since 2002 to communicate between a web browser and a server for the Javascript language, it has gained popularity and is used in many scenarios beyond those implemented in 2002. Many IoT devices can easily receive a JSON payload.

Figure 1.   Logical JSON flow

On the left is the universe of data available to a Niagara Station. The station database provides some data; other data can come from outside the station. The Schema contains configuration properties, which set up its functions. A schema updates when a CoV triggers a generation action from a bound entity or a person invokes the generate action on a schema Property Sheet. This causes any linked properties of the JSON Object payload to create the Output string, which retrieves and routes the data onward through a Transport Point and Handler to an alarm recipient, the cloud or other destination, and back to the device for asset control, such as to control the lighting in a home or acknowledge an alarm.

The format of the JSON output string is relatively simple, organised into a list of key:value pairs, with support for data types: Numeric, Boolean, Enum and String much like Niagara points. JSON messages can use any sequence of objects, arrays and key/value pairs. The JSON Toolkit is flexible. You, as a developer can extend the Toolkit or use APIs to access station data. You can drag schema elements around and change the order of the messages.

JSON supports two data structures: objects and arrays. Complexity emerges from these simple constructs mainly due to the variation in expected payload between different pieces of software, and also their expected encoding of non-primitive types, such as date and time. This is where the demand arises for a flexible solution to marshal Niagara’s rich object model to and from the JSON format.

You can extend the Toolkit or use APIs to access a station’s data. JSON can post data to APIs for data transmission. For example, using the inbound components of the JSON Toolkit, external systems can send a JSON-encoded message to a Niagara station to change a setpoint or acknowledge an alarm.

As the data manipulator, you set up data retrieval and use by creating links between JSON objects. Each schema contains a single root object, which itself contains the JSON objects that establish the links.

Figure 2.   JSON workflow

From the station to the destination, you link the output string, typically via MQTT, to a string-publish point, which sends the payload to a topic in the broker that forwards (transports) it to the destination system. The schema itself is transport agnostic. Linking produces the desired result.

For example, just as an external oBIX client can poll a station for data, the JSON output can be retrieved via an HTTP GET request to a URL that exposes its contents as a web servlet. Using JSON, you can have the same rich data that oBIX provides without the pre-defined oBIX format. Using JSON, you choose the format of the data, which affords total flexibility.

MQTT brokers can link the output of a JSON schema to a cloud platform, such as Bluemix, Google Cloud, and AWS.