Topic Glossary

The Topic glossary goes into detail covering the implementation of specific MQTT Topics. There are three main types of TOPICS

  • SYS: Handles system level configuration, reporting, error messages

  • SENSOR: List, Add, configuration from available sensors.

  • LIVE: Stream raw data from configured sensors to the host application for data collection

Topic Schema

MQTT Topic Namespace/Major/Minor

All MQTT topic strings are prefixed with sensiml/. This defines a namespace for use by the SensiML tools and allows the extension of protocol by prefixing commands.

Customers, partners, or third-party vendors can create additional commands within their own namespace.

The sensiml/ name space is divided into sensiml/<MAJOR>/<MINOR> subtopics.

If a topic change is required, either (a) a new topic name will be created, or (b) a digit will be added to the end of the MINOR topic name.

For example: /sensiml/sys/status/req might become /sensiml/sys/status2/req

Major Section

Topic String

Description / Notes

TOPIC_SYS

sensiml/sys/

Software version, date/time, status

TOPIC_LIVE

sensiml/live/

Transmitting raw sensor data over the air (or wire) to the DCL.

TOPIC_SENSOR

sensiml/sensor/

Configure and control the sensors.

Request & Responses (REQ/RSP)

The MQTT/MQTT-SN protocol is a publish/subscribe protocol. To create a command response pattern, we overlay the publish topics with a pair of REQ and RSP packets. For example, the message TOPIC_SENSOR_LIST_REQ requests the target device publish TOPIC_SENSOR_LIST_RSP listing the available SENSORIDs that are currently supported by the target firmware.

Protocol Byte Order

At the protocol level, MQTT and MQTT-SN use network byte order. Therefore, all parameters for all topics are transmitted Big Endian, MSB First, also known as the network byte order. Sensor values are 16-bit signed integers. The live-streaming sensor data should be sent in the same order as that of the target device. An ARM Cortex M3 MCU uses little endian, LSB first – therefore, it transmits data in the little-endian order. See the device specific JSON file for details.

Topic documentation Convention

MQTT-SN Publish topic is an addressing format that allows MQTT-SN clients to share information through an MQTT broker. The publish message format is as follows:

Length (1 or 3), MsgType(1), Flags(1), TopicId(2), MsgId(2), Payload(x).

If the total length is less than 256 bytes, the Length field is exactly 1 byte.

If the total length is more than 256 bytes, the length field is exactly 3 bytes.

The Fields in the format described below is referred to the payload of the publish message. Each topic command, or response is described in the format, in a way similar to the Unix man page, as follows:

TOPIC_NAME
NAME

Symbolic name for the message used in documentation.

DIRECTION

HOST->TARGET, or TARGET->HOST

REPLY

The name of the reply (if this is a request)

REQUEST

The name of the request (if this is a response)

MQTT_URL

URI string used in the MQTT transaction

TOTAL

<value> The total or maximum length of the packet in bytes. The Total/Max row is not part of the fields that will be included in the payload.

FIELDS

Same as: <Other Name/Command> or Empty Or a table that is similar to the following table

Field Name

Type

Description

Name Here

U8, S8, U16, S16, U32, S32, U64, S64

  • signed S, or unsigned U.

  • Always transmitted BIG ENDIAN (MSB first)

Name Here

  • BYTES(N)

  • ASCII(N)

DESCRIPTION

Paragraph describing the purpose of the packet.

THER HEADINGS

As required by the specific item.

ALSO SEE

List of other messages that are related to this message.

TOPIC_SYS

All TOPIC_SYS messages are for system level configuration and reporting.

TOPIC_SYS_ALL_STOP

NAME

TOPIC_SYS_ALL_STOP

DIRECTION

HOST->TARGET

REPLY

no reply

MQTT_URL

sensiml/sys/all/stop

FIELDS

Empty – there is no payload.

DESCRIPTION

The host can use this command any time to force the device into a known state. This is a generic stop command to the device. Upon receipt, the device:

  • Stop streaming data (TOPIC_LIVE_STOP)

  • Clears all sensor configuration (TOPIC_SENSOR_CLR)

  • Stops other implementation specific activities as needed.

After receiving this message, the device periodically sends MQTT-SN pings as needed when it is connected to the network.

TOPIC_SYS_DEVICE_UUIDS_REQ

NAME

TOPIC_SYS_DEVICE_UUIDS_REQ

DIRECTION

HOST->TARGET

REPLY

TOPIC_SYS_DEVICE_UUIDS_RSP

MQTT_URL

sensiml/sys/device/uuids/req

FIELDS

Empty – there is no payload.

DESCRIPTION

This command requests the device publish the two UUID values — DCLASS_UUID and DSPECIFIC_UUID. See Page 24.

ALSO SEE
  • TOPIC_SYS_DEVICE_UUIDS_RSP

  • TOPIC_SYS_VERSION_RSP

  • TOPIC_SYS_COMPDATETIME_REQ

  • TOPIC_SYS_COMPDATETIME_RSP

TOPIC_SYS_DEVICE_UUIDS_RSP

NAME

TOPIC_SYS_DEVICE_UUIDS_RSP

DIRECTION

TARGET->HOST

REQUEST

TOPIC_SYS_DEVICE_UUIDS_REQ

MQTT_URL

sensiml/sys/device/uuids/rsp

FIELDS

Field Name

Type

Description

DCLASS_UUID

BYTES(16)

This UUID is for the device class.

DUNIQUE_UUID

BYTES(16)

This UUID is for device specific UUID.

TOTAL

BYTES(4)

DESCRIPTION

This response contains DCLASS_UUID and DUNIQUE_UUID.

The DUNIQUE_UUID models a board serial number. The combined DCLASS_UUID + DUNIQUE_UUID must be unique.

For the implementation recommendations, see 15.1 Notes for TOPIC_SYS_DEVICE_UUIDS in PART 2.

ALSO SEE
  • TOPIC_SYS_DEVICE_UUIDS_REQ

  • TOPIC_SYS_VERSION_RSP

  • TOPIC_SYS_COMPDATETIME_REQ

  • TOPIC_SYS_COMPDATETIME_RSP

TOPIC_SYS_VERSION_REQ

NAME

TOPIC_SYS_VERSION_REQ

DIRECTION

HOST->TARGET

REPLY

TOPIC_SYS_VERSION_RSP

MQTT_URL

sensiml/sys/version/req

FIELDS

Empty – there is no payload.

DESCRIPTION

This command requests the device publish the SW version.

ALSO SEE
  • TOPIC_SYS_VERSION_RSP

  • TOPIC_SYS_COMPDATETIME_REQ

  • TOPIC_SYS_COMPDATETIME_RSP

TOPIC_SYS_VERSION_RSP

NAME

TOPIC_SYS_VERSION_RSP

DIRECTION

TARGET->HOST

REQUEST

TOPIC_SYS_VERSION_REQ

MQTT_URL

sensiml/sys/version/rsp

FIELDS

Field Name

Type

Description

STRING

ASCII(N)

This reply should be 10 to 20 bytes long.

TOTAL

N

This UUID is for device specific UUID.

DESCRIPTION

This command retrieves a short ASCII string identifying the current device firmware version. The version string gives the current firmware version information.

ALSO SEE
  • TOPIC_SYS_VERSION_REQ

  • TOPIC_SYS_COMPDATETIME_REQ

  • TOPIC_SYS_COMPDATETIME_RSP

TOPIC_SYS_COMPDATETIME_REQ

NAME

TOPIC_SYS_COMPDATETIME_REQ

DIRECTION

HOST->TARGET

REPLY

TOPIC_SYS_COMPDATETIME_RSP

MQTT_URL

sensiml/sys/compdatetime/req

FIELDS

Empty – there is no payload.

DESCRIPTION

This command requests the device publish the compile date and time of the firmware.

ALSO SEE
  • TOPIC_SYS_VERSION_RSP

  • TOPIC_SYS_COMPDATETIME_RSP

TOPIC_SYS_COMPDATETIME_RSP

NAME

TOPIC_SYS_COMPDATETIME_RSP

DIRECTION

TARGET->HOST

REQUEST

TOPIC_SYS_COMPDATETIME_REQ

MQTT_URL

sensiml/sys/compdatetime/rsp

FIELDS

Field Name

Type

Description

STRING

ASCII(N)

This reply should be 10 to 20 bytes long.

TOTAL

N

This UUID is for device specific UUID.

DESCRIPTION

This command retrieves the firmware build date and time to help with software identification. See the Notes for TOPIC_SYS_COMPDATETIME

ALSO SEE
  • TOPIC_SYS_VERSION_REQ

  • TOPIC_SYS_COMPDATETIME_REQ

TOPIC_SYS_STATUS_REQ

NAME

TOPIC_SYS_STATUS_REQ

DIRECTION

HOST->TARGET

REPLY

TOPIC_SYS_STATUS_RSP

MQTT_URL

sensiml/sys/status/req

FIELDS

Empty – there is no payload.

DESCRIPTION

This command requests the device publish TOPIC_SYS_STATUS_RSP

ALSO SEE
  • TOPIC_SYS_STATUS_RSP

  • TOPIC_SYS_ERROR

TOPIC_SYS_STATUS_RSP

NAME

TOPIC_SYS_STATUS_RSP

DIRECTION

TARGET->HOST

REQUEST

TOPIC_SYS_STATUS_REQ

MQTT_URL

sensiml/sys/status/rsp

FIELDS

Field Name

Type

Description

BYTES_SAVED

U32

Counts the bytes written to the sensor data file. Sensor data blocks are 4K bytes. Zeroed using TOPIC_SYS_STATUS_CLR.

BIT_FLAGS

U32

See the following table for the list of bits.

RX_COUNT

U16

Number of messages received (not including duplicates), always increasing, rolls over at 0 xffff. This value is reset to 0 at power up/reset.

TX_COUNT

U16

Number of messages transmitted (not including duplicates) always increasing, rolls over at 0xffff. This value is reset to 0 at power up/reset.

LIVE_OE_COUNT

U16

Number of TOPIC_LIVE_<various> messages dropped because the transport cannot keep up (over run error). Zeroed using TOPIC_SYS_STATUS_CLR

COLLECT_OE_COUNT

U16

Number of data blocks dropped that could not be saved to the SD card because the total sen sor data rate was too high. Zeroed using TOPIC_SYS_STATUS_CLR

STICKY_ERROR_CODE

U8

Sticky error code, 0 indicates no error. See the following table for details. Zeroed using TOPIC_SYS_STATUS_CLR to clear status

ERROR_COUNT

U8

Error counter, always increasing may roll over after 0xFF, TOPIC_SYS_STATUS_CLR. This is a n indication that multiple errors occurred and the STICKY_ERROR_CODE captured only the fir st.

DESCRIPTION

Not all values are zeroed by issuing the TOPIC_SYS_STATUS_CLR command. The following table gives additional details of specific fields.

BIT_FLAGS

Bit Number

Description / Notes

0

COLLECT_ACTIVE If 1, then data is being collected/saved to the storage medium (ie., SD card). This bit auto clears if storage error occurs. For example, the SD card is removed, not present, or full.Set: TOPIC_COLLECT_STARTClear: TO PIC_COLLECT_STOP, or TOPIC_SYS_ALL_STOP

1

LIVE_STREAM_ACTIVEIf 1, then LIVE_STREAM sensor messages are active. TOPIC_LIVE_STOP, or Set: TOPIC_LIVE_START Clear: TOPIC_SYS_ALL_STOP

2

LIVE_STREAM_RECOG_ACTIVEIf 1, then recognition results are live streamed.Set: TOPIC_RECOG_STARTClear: TOPIC_RECOG_STOP, or TOPIC_SYS_ALL_STOP

3..31

Reserved / Future

STICKY_ERROR_CODE

ZERO indicates no error, non-zero indicates error. At startup (or after issuing the TOPIC_SYS_STATUS_CLR command) the STICKY_ERROR_CODE is zero (0).

When an error occurs:
  • Only the first (0 to non-zero) transition is captured.

  • The status bit ANY_ERROR is set.

  • Depending on the error, other error bits are set. For example, collection and live stream.

  • The status byte: ERROR_COUNT is increased.

Notes:
  • If ERROR_COUNT is greater than 1, more than 1 error has occurred.

  • If the error is related to data collection (saving data to the storage medium), the BITFLAG: COLLECT_ACTIVE auto clears.

STICKY_ERROR_CODE Values

STICKY_ERROR_CODE

Unix Symbolic Name

Description / Notes

1

EPERM

Operation not permitted

2

ENOENT

File not found (see STORAGE commands)

5

EIO

IO error (SD Card or sensor)

16

EBUSY

Device is busy

19

ENODEV

No such device/sensor

22

EINVAL

Invalid parameter

30

EROFS

Read only file system

60

ETIMEDOUT

Timeout

63

ENAMETOOLONG

Filename too long

70

ESTALE

File operation is stale (see STORAGE commands)

78

ENOSYS

Feature not implemented

85

ENOMEDIUM

No medium found

91

ENOTSUP

Not supported

See Notes for TOPIC_SYS_STATUS_SP for an implementation note and example.

ALSO SEE
  • TOPIC_SYS_STATUS_REQ

  • TOPIC_SYS_ERROR (which has extended error information)

TOPIC_SYS_STATUS_CLR

NAME

TOPIC_SYS_STATUS_CLR

DIRECTION

HOST->TARGET

REPLY

no reply

MQTT_URL

sensiml/sys/status/clr

FIELDS

Empty – there is no payload.

DESCRIPTION

This command clears all sticky values shown in the TOPIC_SYS_STATUS_RSP. For more information, see TOPIC_SYS_STATUS_RSP. It clears all error counts and status counts.

ALSO SEE
  • TOPIC_SYS_STATUS_RSP

  • TOPIC_SYS_ERROR

TOPIC_SYS_REBOOT

NAME

TOPIC_SYS_REBOOT

DIRECTION

HOST->TARGET

REPLY

no reply

MQTT_URL

sensiml/sys/reboot

FIELDS

Field Name

Type

Description

NEWAPP

ASCII(N)

This string provides instructions for device.

TOTAL

N

This UUID is for device specific UUID.

DESCRIPTION

This command is used to power-cycle or reset or re-flash the device.

Requirement: All devices must support the case of N is 0 (no string). That is, the device must reset if it receives this message.

Optional: If N is not 0 (a string is provided), the NEWAPP string instructs the device to re-flash modify its configuration or re-flash itself with the image specified by the NEWAPP field.

ALSO SEE
  • TOPIC_SYS_ALL_STOP

  • TOPIC_STORAGE_PUT

TOPIC_SYS_ERROR

NAME

TOPIC_SYS_ERROR

DIRECTION

TARGET->HOST

REPLY

no reply

MQTT_URL

sensiml/sys/error

FIELDS

Field Name

Type

Description

MSG_ID

U16

Big Endian MQTT message sequence number associated with this error.

DYN_TOPIC_ID

U16

Dynamic MQTT-SN Topic ID for this message.

FIXED_TOPIC_ID

U16

Fixed device specific MQTT-SN topic ID.

STICKY_ERROR_CODE

U8

The value of the STICKY_ERROR_CODE.

EXTENDED_ERROR

U32

Transmitted big Endian that is implementation defined and is used to provide mor e details about the specific error.

TOTAL

11

DESCRIPTION
PUBLISHED
  • In response to a command containing invalid data.

  • Spontaneously by the device for reporting catastrophic conditions. For example, when the storage medium is full during data collection (saving the SD card).

ACTIONS

Each time a TOPIC_SYS_ERROR is attempted (which may fail to be delivered or get lost), the target must update the TOPIC_SYS_STATUS_RSP report fields.

In this case, the target:
  • Captures only the first STICKY_ERROR_CODE

  • Increments the ERROR_COUNT field

  • Set/Clear other BIT_FIELD bits as appropriate

OVERRUN ERRORS

Overrun errors (such as storage overrun and live stream) are not reported by this message. Overrun errors set bits only within the status. The host polls periodically using TOPIC_SYS_STATUS_REQ and finds the sticky error bits.

If the message is NOT related to a specific message, the fields MSGID, DYN_TOPIC_ID and FIXED_TOPIC_ID are zero.

If the topic is associated with a message, the MSGID field is the MQTT-SN Message ID number of the offending message.

For example:
  • PIC_SENSOR_ADD, for an invalid sensor id.

  • TOPIC_STORAGE_GET_START, for a non-existing file.

The FIXED_TOPIC_ID and DYN_TOPIC_ID represent the topic id of the offending message. The MQTT-SN allows two types of TOPIC ID numbers. See: MQTT-SN REGISTER.

DYNAMIC – DYN_TOPIC_ID and FIXED (Predefined) -** FIXED_TOPIC_ID**

If the device uses predefined topics – then the DYNAMIC and FIXED field hold the same value (the predefined topic id)

If the device registers topics, then DYNAMIC and FIXED fields will be different. The FIXED field should be a firmware/implementation defined fixed value that can be used to identify the topic. The DYNAMIC field holds the dynamically assigned topic id as assigned by the gateway/broker.

It is recommended that the FIXED_TOPIC_ID is a hard-coded value that is unique to each topic. It is assumed that the device has implementation specific numeric #define for each message that is used internally. This value must be used for the FIXED_TOPIC_ID.

This helps in tracing the messages during a debug session.

EXCEPTIONS
  • Invalid topics and protocol errors are handled at the protocol level, not using this method.

  • Over run errors related to saving to the SD card are not reported using this method. For more information, see TOPIC_SYS_STATUS_RSP.

ALSO SEE
  • TOPIC_SYS_STATUS_RSP

  • TOPIC_SYS_STATUS_CLR

TOPIC_SENSOR

The device maintains a list of available sensors that can be used. The host can use the TOPIC_SENSOR commands to configure sensors for data collection.

TOPIC_SENSOR_LIST_REQ

NAME

TOPIC_SENSOR_LIST_REQ

DIRECTION

HOST->TARGET

REPLY

TOPIC_SENSOR_LIST_RSP

MQTT_URL

sensiml/sensor/list/req

FIELDS

Empty – there is no payload.

DESCRIPTION

This command requests the target to respond with TARGET_SENSOR_LIST_RSP.

ALSO SEE
  • TOPIC_SENSOR_LIST_RSP

  • TOPIC_SENSOR_ADD

TOPIC_SENSOR_LIST_RSP

NAME

TOPIC_SENSOR_LIST_RSP

DIRECTION

TARGET -> HOST

REQUEST

TOPIC_SENSOR_LIST_REQ

MQTT_URL

sensiml/sensor/list/rsp

FIELDS

Field Name

Type

Description

SENSOR_LIST

U32

List of SENSOR_IDs that are supported in this configuration.

TOTAL

4xN

Where N = Number of sensors

DESCRIPTION

The target responds with a list of SENSOR_IDs that are supported in this configuration.

It is expected that target platforms will have compile time options (#define FEATURE settings) that include or exclude certain sensors.

See Notes for TOPIC_SENSOR_LIST_RSP

ALSO SEE
  • TOPIC_COLLECT

  • TOPIC_SENSOR_LIST_REQ

  • TOPIC_SENSOR_ADD

TOPIC_SENSOR_CLR

NAME

TOPIC_SENSOR_CLR

DIRECTION

HOST->TARGET

REPLY

no reply

MQTT_URL

sensiml/sensor/clr

FIELDS

Empty – there is no payload.

DESCRIPTION

This command de-configures, clear, and disables all sensors.

ALSO SEE
  • TOPIC_SENSOR_LIST_REQ

  • TOPIC_SENSOR_LIST_RSP

  • TOPIC_SENSOR_ADD

TOPIC_SENSOR_ADD

NAME

TOPIC_SENSOR_ADD

DIRECTION

HOST->TARGET

RESPONSE

None.

MQTT_URL

sensiml/sensor/add/

FIELDS

Field Name

Type

Description

SENSOR_ID

U32

The specific 32-bit that identifies the sensor to be configured.

SAMPLE_RATE

U32

Sensor sample rate in Hz

CONFIG_BYTES

BYTES(N)

N bytes – as specified by the specific sensor id. This field is board and sensor specific.

TOTAL

8+N

Where N = Number of sensors

DESCRIPTION

This message will add one sensor that is configured when it is added to the data collection sensor id list. See Notes for TOPIC_SENSOR_ADD

ALSO SEE
  • TOPIC_SENSOR_LIST_REQ

  • TOPIC_SENSOR_LIST_RSP

TOPIC_SENSOR_DONE

NAME

TOPIC_SENSOR_DONE

DIRECTION

HOST->TARGET

REPLY

no reply

MQTT_URL

sensiml/sensor/done

FIELDS

Empty, there is no payload.

DESCRIPTION

This informs the device that the sensor configuration is complete. The device can complete the sensor configuration at this time.

ALSO SEE
  • TOPIC_COLLECT

  • TOPIC_SENSOR_LIST_REQ

  • TOPIC_SENSOR_LIST_RSP

  • TOPIC_SENSOR_CLR

  • TOPIC_SENSOR_ADD

Sequence Diagram

This diagram shows the basic steps used to configure sensors by adding them.

Sequence Diagram for Adding Sensors

Sequence Diagram for Adding Sensors

TOPIC_LIVE

The live sensor data streaming feature enables the SensiML data collection software to upload real-time raw sensor data to the Data Collection Lab. The sensor data can be used for the visual presentation of live data using the software or stored in the SensiML cloud or locally.

A sensor is active if it is configured and the sampling data is ready for collection.

Sequence Diagram

This diagram shows the basic steps used to live streaming of the raw sensor data.

Sequence Diagram for Live Streaming of Raw Data

Sequence Diagram for Live Streaming of Raw Data

TOPIC_LIVE_SENSOR_LIST_REQ

NAME

TOPIC_LIVE_SENSOR_LIST_REQ

DIRECTION

HOST->TARGET

REPLY

TOPIC_LIVE_SENSOR_LIST_RSP

MQTT_URL

sensiml/live/sensor/list/req

FIELDS

Empty – there is no payload.

DESCRIPTION

The DCL has a record of the sampling rate of all the active sensors on the end-point device. This is an optional command for the DCL to get the sampling rate of the desired sensors.

ALSO SEE
  • TOPIC_LIVE_SENSOR_LIST_RSP

TOPIC_LIVE_SENSOR_LIST_RSP

NAME

TOPIC_LIVE_SENSOR_LIST_RSP

DIRECTION

TARGET->HOST

REQUEST

TOPIC_LIVE_SENSOR_LIST_REQ

MQTT_URL

sensiml/live/sensor/list/rsp

FIELDS

Field Name

Type

Description

SENSOR_1_ID

U32

The ID of sensor 1.

SENSOR_1_RATE

U32

The sample rate of sensor 1.

SENSOR_N_ID

U32

The ID of sensor n.

SAMPLE_N_RATE

U32

The sample rate of sensor n.

Total bytes

8xN

Total number of the bytes

DESCRIPTION

This is the response with the sampling rate corresponding to each active sensor.

ALSO SEE
  • TOPIC_LIVE_SENSOR_LIST_REQ

TOPIC_LIVE_SET_RATE_REQ

NAME

TOPIC_LIVE_SET_RATE_REQ

DIRECTION

HOST->TARGET

REPLY

TOPIC_LIVE_SET_RATE_RSP

MQTT_URL

sensiml/live/set/rate/req

FIELDS

Field Name

Type

Description

SENSOR_COUNT

U8

Total number of the sensors

SENSOR_ID_1

U32

The ID of sensor 1.

SENSOR_1_COUNT_DOWN

U32

The count-down number for sensor 1

SENSOR_ID_N

U32

The ID of sensor n.

SENSOR_N_COUNT_DOWN

U32

The count-down number for sensor 1

Total

8xN+1

Total number of the bytes

DESCRIPTION

This command sets the live streaming rate which represented by the count-down number of the selected sensor but will not affect the actual sampling rate of the sensor. When the count-down number is set to “1”, it means every other sample. When it is set to “0” if you want to see every samples sensor provided.

The DCL uses this command to configure the live streaming rate of the active sensors. The DCL can set the live streaming of one or more sensors to receive one or more sensor data concurrently. The DCL can stop the current streaming and select/configure different sensor for live streaming in any active DCL session.

This command does not change the configuration of the sensors that are not in the list of the command payload. Streaming rate can be set using the count-down.

ALSO SEE
  • TOPIC_LIVE_SET_RATE_RSP

TOPIC_LIVE_SET_RATE_RSP

NAME

TOPIC_LIVE_SET_RATE_RSP

DIRECTION

TARGET->HOST

REQUEST

TOPIC_LIVE_SET_RATE_REQ

MQTT_URL

sensiml/live/set/rate/rsp

FIELDS

Field Name

Type

Description

SENSOR_1_ID

U32

The ID of sensor 1.

SENSOR_1_COUNT_DOWN

U32

The count-down number for sensor 1

SENSOR_N_ID

U32

The ID of sensor n.

SENSOR_N_COUNT_DOWN

U32

The count-down number for sensor n.

Total

8xN

Total number of the bytes

DESCRIPTION

The device sends this message in response to the TOPIC_LIVE_SET_RATE_REQ command. The message returns the live streaming rate in count down of each active sensor.

The live streaming rate depends on the capability of the underlying transport layer and varies among different communication protocols, the rate (sampling, streaming), and the way sensor data are feed.

In case the device is not able to support the requested rate of the requested senor ID, the rate field will contain an error code. The following error codes are supported:

  1. No.

Error code

Comments

1

(SENSOR_ID_INVALID) 0xFFFFFFFF

The given sensor ID does not exist

2

(SENSOR_NOT_ACTIVE) 0xFFFFFFFE

The given sensor is not configured for data sampling/acquisition

3

(INVALID_STREAM_RATE) 0xFFFFFFFD

Device could not support the requested streaming rate —either the rate is too high or too low.

In the above table, the big numbers are selected for error codes so that the DCL can identify if the requested streaming rate is accepted or rejected by the device.

ALSO SEE
  • TOPIC_LIVE_SET_RATE_REQ

TOPIC_LIVE_START

NAME

TOPIC_LIVE_START

DIRECTION

HOST->TARGET

REPLY

none

MQTT_URL

sensiml/live/start

FIELDS

Field Name

Type

Description

SENSOR_COUNT

U8

Total number of sensors

SENSOR_1_ID

U32

The ID of the sensor 1

SENSOR_1_MIN

U8

Minimum of the sample counts per packet of sensor 1

SENSOR_N_ID

U32

The ID of the sensor N

SENSOR_N_MIN

U8

Minimum of the sample counts per packet of sensor N

Total bytes

5xN+1

Total number of the bytes

DESCRIPTION

This command is used to start the live sensor data streaming. The minimum is the minimal number of samples a packet will contain before the it is published.

The DCL can choose one or multiple sensors for live streaming. This message allows you to choose to receive single or multiples samples for each sensor.

For the explanation of the minimum in the messages, see Notes for TOPIC_LIVE_START

ALSO SEE
  • TOPIC_LIVE_RAW_DATA

  • TOPIC_LIVE_STOP

TOPIC_LIVE_RAW_DATA

NAME

TOPIC_LIVE_RAW_DATA

DIRECTION

TARGET->HOST

REQUEST

none

MQTT_URL

sensiml/live/raw/data

FIELDS

Field Name

Type

Description

SENSOR_ID

U32

The ID of sensor.

SEQUENCE_NO

U8

Packet sequence number for sensor.

SAMPLE_1

M

M is the number of bytes for Sample 1 of sensor

SAMPLE_N

M

M is the number of bytes for Sample N of sensor.

Total bytes

MXN+5

Total number of the bytes

DESCRIPTION

This command is used to send live sensor streaming data from the target device to the DCL for the sensors listed in the TOPIC_LIVE_START** message.

ALSO SEE
  • TOPIC_LIVE_START

  • TOPIC_LIVE_STOP

TOPIC_LIVE_STOP

NAME

TOPIC_LIVE_STOP

DIRECTION

HOST->TARGET

REPLY

none

MQTT_URL

sensiml/live/stop

FIELDS

Empty

DESCRIPTION

This command is used to stop the live sensor data streaming. It will stop all sensors from streaming. All sensor’s live stream states/struct are reset, sensor’s sampling configuration not changed, this brings sensors to the state when they were added. To restart live streaming, do TOPIC_LIVE_START only.

ALSO SEE
  • TOPIC_LIVE_RAW_DATA

  • TOPIC_LIVE_START