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 DS.
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.

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.

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 Data Studio has a record of the sampling rate of all the active sensors on the end-point device. This is an optional command for the Data Studio 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 Data Studio uses this command to configure the live streaming rate of the active sensors. The Data Studio can set the live streaming of one or more sensors to receive one or more sensor data concurrently. The Data Studio can stop the current streaming and select/configure different sensor for live streaming in any active Data Studio 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:

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 Data Studio 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 Data Studio 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 Data Studio 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