Network Server Stack

Connecting to the Network Server Stack MQTT Broker – Google Cloud Platform

Created OnMay 09, 2018
byDavid Baerg
You are here:
< Back

Prerequisites

Before you can receive data over MQTT, you must first configure the Network Server Stack to receive data.

Configuration

You will need to properly configure your MQTT client’s settings to connect to the Network Server Stack’s MQTT broker. The broker’s default port is 1883, and can thus be found at <vm public ip>:1883.

Topics

The MQTT topics published by the broker are per-Application and follow the form:
<Application EUI>/devices/<Device ID>/<method>

For OTAA authenticated devices, the Device ID is just the Device EUI, whereas for ABP authenticated devices, the Device ID field is eight zeros followed by the device’s DevAddr, e.g. 000000001234EAAE.

Topics for different methods are detailed in the sections below. For convenience, a wildcard “+” can be used in place of any of the four fields. This will match anything that could have been placed in that field. This allows a client to, for instance, subscribe to all device uplink messages on an application with EUI `123456789ABCDEF` by subscribing to the topic123456789ABCDEF/devices/+/up

Similarly, a client could receive all messages for every device on the application by subscribing to123456789ABCDEF/devices/+/+

Note that even if the Application EUI is wildcarded, only messages from the Application corresponding to the Application EUI used to login when connecting to the MQTT broker will be received.

Activations

Device activations are published on the topic <Application EUI>/devices/<Device ID>/activations

To receive all devices’ activations on an application, a wildcard can be used: <Application EUI>/devices/+/activations  

Uplink Messages
Device uplink messages are published on the topic <Application EUI>/devices/<Device ID>/up

To receive all devices’ uplinks on an application, a wildcard can be used:<Application EUI>/devices/+/up

Downlink messages
In addition to subscribing to uplink messages, an MQTT client can also publish downlink messages to send data to a device. The topic is<Application EUI>/devices/<Device ID>/down

 

Downlink messages published to the topic of a specific device must be formatted as a JSON object with the following fields:

  • “TTL” (string) – Time To Live. How long the packet should be preserved in the downlink queue before being discarded if no uplink is received. Formatted in the duration string format documented at https://golang.org/pkg/time/#ParseDuration.
    • Examples:
      • 1.5 minutes: {“TTL”: “1m30s”}
      • 1.5 minutes: {“TTL”: “1.5m”}
      • 1 day: {“TTL”: “24h”}
  • “payload” (string) – Base64 (RFC4648) encoded binary payload for the end device.
    • Examples:
      • Hex 0x01 : {“payload”: “AQ==”}
  • “confirmed” (bool) – Whether the message should be sent as a confirmed downlink, eliciting an acknowledgment from the device.
    • Examples:
      • Send confirmed: {“confirmed”: true}
  • Example of complete downlink MQTT message:
    • {“payload”:”AQ==”, “TTL”: “6h”, “confirmed”: false}
Tags:
David Baerg