MQTT Topics and JSON Data Format
MQTT Topics and JSON Data Format
and
JSON Data Format
User Manual
USA Headquarters
Advantech B+B SmartWorx
707 Dayton Road
Ottawa, IL 61350 USA
Phone (815) 433-5100 -- General Fax (815) 433-5105
www.advantech-bb.com
[email protected]
European Headquarters
Advantech B+B SmartWorx
Westlink Commercial Park
Oranmore, Co. Galway, Ireland
Phone +353 91-792444 -- Fax +353 91-792445
Document: MQTT_Topics_and_JSON_Data_Format_R3_User_Manual_0316
2
REVISION HISTORY
3
CONTENTS
7 – GET THE Sensor List – Sensors Available on the Sensor Platform. ....................................................................19
5
ABOUT THIS DOCUMENT
This document contains the messaging details for accessing the published data and controls that are
available on the Wzzard Sensor. The sensor uses the MQTT protocol containing data in a JSON format
for all of the data being sent across the sensor network.
MQTT is a lightweight broker based publish/subscribe messaging protocol designed for use on low
bandwidth networks. JSON is an open standard format that contains data objects consisting of attribute-
value pairs in human readable text.
In order to have the ‘data’ and ‘configuration’ items sent to a MQTT client, a user will need to subscribe
to the broker handling the Wzzard Sensor network so that the data being published by the sensor will be
forwarded to the client. The subscribe message will contain the ‘topic’ that is being requested. This
‘topic’ represents the area (or grouping) of data that the user wants to see or collect. This document
contains the ‘topic’ values along with what data is available for each ‘topic’.
If the user wants to change one of the digital outputs on a sensor, then a ‘publish’ will need to be sent to
the broker handling the Wzzard Sensor network with the new setting. This is handled via the ‘ctl’ topics
supported by the sensor and is covered in the ‘Sensor Control’ section of this document.
If the user wants to change a configuration setting on a sensor, then a ‘publish’ will need to be sent to
the broker handling the Wzzard Sensor network with the new setting. This is handled via the ‘set’ topics
supported by the sensor and is covered in the ‘Sensor Configuration’ section of this document.
6
MQTT FORMAT
2. mfg_id: the OEM identifier for the manufacturer. For B & B Electronics this will be "BB". The
mfg_id cannot contain the following MQTT reserved characters: plus ('+'), forward slash ('/'),
number sign ('#').
3. asset_id: this is the unique identifier for the sensor module. The asset_id cannot contain the
following MQTT reserved characters: plus ('+'), forward slash ('/'), number sign ('#').
IMPORTANT: The JSON data sent to each MQTT topic must be 75 bytes or less to be transferred over the
wireless network to the sensor platform.
mfg_id/asset_id/topic
JSON FORMAT
c: a number that is incremented whenever there is a configuration change affecting the reading (e.g.,
scaling, calibration)
7
SENSOR DATA FORMAT
This section describes all the data possible for every variant of the Wzzard. An individual Wzzard will
have a subset of this data corresponding to the sensors available on the specific model. This data is
published on a time based interval that’s configured using the ‘publish interval’ setting of the system
configuration.
8
"temp1":{"title":"Temperature Input 1","description":"The value of temperature input 1.",
"$ref":"#/definitions/temp_value"},
"temp2":{"title":"Temperature Input 2","description":"The value of temperature input 2.",
"$ref":"#/definitions/temp_value"},
"tempint":{"title":"Internal Temperature","description":"The internal temperature of the sensor
platform.",
"$ref":"#/definitions/temp_value"},
"vbatt":{"title":"Supply Voltage","description":"The voltage supplied to the sensor platform.",
"$ref":"#/definitions/vbatt_value"}
},
"definitions":{
"ai_value":{"type":"number"},
"di_value":{"oneOf":[{"type":"boolean"},{"type":"number"}]},
"do_value":{"type":"boolean"},
"temp_value":{"type":"number"},
"vbatt_value":{"type":"number"},
"accel_value":{"type":"number","minimum":-9.999,"maximum":9.999}
}
}
{"s":1,
"t":"2014-07-11T15:26:37Z",
"q":192,"c":1,
"ai3":-123456.7}
Example of the BB/0013430C981B {"s":1, The value of di1 and di2 can be:
data for digital /data "t":"2014-07-11T15:26:37Z", false, true.
input when "q":192,"c":1,
configured for "di1":false,"di2":true}
a Boolean
input.
9
Example of the BB/0013430C981B {"s":1, The value of di1 and di2 can be:
data for digital /data "t":"2014-07_11T15:26:37Z", counts or frequency.
input when "q":192,"c":1,
configured for "di1":1.234567,
counter or "di2":123456.7}
frequency.
Example of the BB/0013430C981C {"s":1, The value of do1 and do2 can
data for digital /data "t":"2014-07-11T15:26:37Z", be: false, true
output. "q":192,"c":1,
"do1":false,"do2":true}
Example of the BB/0013430C981D {"s":1, The temperature in the
data for /data "t":"2014-07-11T15:26:37Z", configured engineering units
temperature "q":192,"c":1,
sensor. "temp1":23.6,
"temp2":-273.0}
Example of the BB/0013430C981F {"s":1, The supply voltage.
data for /data "t":"2014-07-11T15:26:37Z",
supply. "q":192,"c":1,
"vbatt":3.1}
Example of the BB/0013430C981fF {"s":1, Temperature in the configured
data for /data "t":"2014-07-11T15:26:37Z", engineering units
internal "q":192,"c":1,
temperature. "tempint":-25.2}
10
SENSOR CONTROL
These topics are used to control the digital outputs on the sensors that support them. These requests
need to be published to the broker handling the Wzzard Sensor network.
Description MQTT Topic Format Example JSON Data Format (Specified in Notes
Data JSON Schema)
Generalized mfg_id/asset_id/ctl/s Example1: {"$schema":"http://json- v: the value in
format for ensor_id/sensor_inst {"v":false} schema.org/draft- engineering
setting ance 04/schema#", units.
sensor data. "description":"Set a wireless
sensor output",
"type":"object",
"additionalProperties":
false,
"required":["v"],
"properties":{
"v":{"description":"The
sensor output value specified
in engineering units",
"type":"boolean"}}
}
11
SENSOR CONFIGURATION
The following sections describe all the configuration settings for every variant of the Wzzard. An
individual Wzzard will have a subset of this data corresponding to the sensors available on the specific
model. This data is published when the sensor first connects to the network and again when a
configuration setting is changed.
12
2 – SET THE DUST NETWORK CONFIGURATION.
13
3 – GET THE BLUETOOTH LE CONFIGURATION.
14
4 – SET THE BLUETOOTH LE CONFIGURATION.
15
5 - GET THE SENSOR PLATFORM CONFIGURATION
17
6 - SET THE SENSOR PLATFORM CONFIGURATION
18
7 – GET THE SENSOR LIST – SENSORS AVAILABLE ON THE SENSOR PLATFORM.
Only the sensors available on the specific sensor platform are returned in the array. The array
entries can be used as the suffix for the topics "BB/0013430C981F/data" and
"BB/0013430C981F/cfg/sensor".
19
8 – GET AN ANALOG INPUT CONFIGURATION.
The "ahi", "alo", "sp" & "zp" values only support 2 decimal places.
21
9 – SET AN ANALOG INPUT CONFIGURATION.
The "ahi", "alo", "sp" & "zp" values only support 2 decimal places.
The “ahi” setting must be set to a value greater than the “alo” setting and the “ahi” and “alo”
settings must be set within the “zp” and “sp” span for proper operation.
23
10 – GET A DIGITAL INPUT CONFIGURATION.
For the rate type: the "period" option is currently read-only and is set to 1 second. The "ahi" &
"alo" values only support 2 decimal places.
For the rate and counter types: the "mot" period is reserved for future use. Do not implement.
26
11 – SET A DIGITAL INPUT CONFIGURATION.
For the rate type: the "period" option is currently read-only and is set to 1 second. The "ahi" &
"alo" values only support 2 decimal places.
The “ahi” setting must be set to a value greater than the “alo” setting for proper operation.
For the rate and counter types: the "mot" period is reserved for future use. Do not implement.
29
12 – GET A DIGITAL OUTPUT CONFIGURATION.
30
13 – SET A DIGITAL OUTPUT CONFIGURATION.
31
14 – GET A TEMPERATURE INPUT CONFIGURATION.
33
15 – SET A TEMPERATURE INPUT CONFIGURATION.
The “ahi” setting must be set to a value greater than the “alo” setting for proper operation.
35
16 – GET THE ACCELEROMETER CONFIGURATION.
36
17 – SET THE ACCELEROMETER CONFIGURATION.
37
18 – GET THE GEOLOCATION CONFIGURATION.
The "la" & "lo" values support 4 decimal places and the "el" value supports 1 decimal place.
39
19 – SET THE GEOLOCATION CONFIGURATION.
The "la" & "lo" values support 4 decimal places and the "el" value supports 1 decimal place.
41
20 – GET THE SUPPLY VOLTAGE CONFIGURATION.
42
21 – SET THE SUPPLY VOLTAGE CONFIGURATION.
The “ahi” setting must be set to a value greater than the “alo” setting for proper operation.
43
QUALITY CODES
ID Major Quality Sub- Quality Quality Code Notes on OPC quality and substatus
Quality Status Code (Hexadecimal) codes.
(Decima
l)
1 No Quality No Value 255 0xFF No quality value is provided.
2 Bad Non Specific 0 0x00 The value is bad, but no specific
reason is known.
3 Bad Configuration 0x04 The value is bad, but no specific
4
Error reason is known.
4 Bad Not 8 0x08 The input is required to be logically
Connected connected to something, but is not.
This quality may reflect that no value
is available at this time, for reasons
like the value may have not been
provided by the data source.
5 Bad Device 12 0x0C A device failure has been detected.
Failure
6 Bad Sensor 16 0x10 A sensor failure had been detected
Failure (the ’Limits’ field can provide
additional diagnostic information in
some situations.)
7 Bad Last Known 20 0x14 Communications have failed;
Value however, the last known value is
available. Note that the ‘age’ of the
value may be determined from the
timestamp.
8 Bad Communicati 24 0x18 Communications have failed. There is
on Failure no last known value is available.
9 Bad Out of 28 0x1C The sensor is off scan or otherwise
Service locked.
10 Uncertain Non Specific 64 0x40 There is no specific reason why the
value is uncertain.
11 Uncertain Last Usable 68 0x44 Whatever was writing this value has
Value stopped doing so. The returned value
should be regarded as ‘stale’. Note
that this differs from a BAD value
with Substatus 5 (Last Known Value).
That status is associated specifically
with a detectable communications
error on a ‘fetched’ value. This error
is associated with the failure of some
44
external source to ‘put’ something
into the value within an acceptable
period of time. Note that the ‘age’ of
the value can be determined from
the timestamp.
12 Uncertain Sensor Not 80 0x50 Either the value has ‘pegged’ at one
Accurate of the sensor limits (in which case the
limit field should be set to 1 or 2) or
the sensor is otherwise known to be
out of calibration via some form of
internal diagnostics (in which case
the limit field should be 0).
13 Uncertain EU Units 84 0x54 The returned value is outside the
Exceeded limits defined for this parameter.
Note that in this case the ‘Limits’ field
indicates which limit has been
exceeded, but does NOT necessarily
imply that the value cannot move
farther out of range.
14 Uncertain Sub Normal 88 0x58 The value is derived from multiple
sources and has less than the
required number of Good sources.
15 Good Non Specific 192 0xC0 The value is good. There are no
special conditions.
16 Good Local 216 0xD8 The value has been overridden.
Override Typically this is means the input has
been disconnected and a manually
entered value has been ‘forced’.
45