MQTT connection

This connector allows you to connect Network Server to your application using MQTT protocol.

For message types please refer to the corresponding section of Data API messages.

Argument Required Description
description no Description of connection
uri yes URI of the broker, please refer to the scheme
filter yes The Network Server Filter ID.
topic_up yes The topic name for messages network server will publish to. IT supports real-time substitution with type and fields in ''meta'' This topic name may contain message type and fields from meta, e.g /messages/{type}/{device}/
topic_down no The topic name for message network server will subscribe to.

List of schemas allowed to be used in URI field:

Scheme Encrypted Default port Description
mqtt:// no 1883 Native MQTT TCP
mqtts:// yes 8883 Native MQTT TCP TLS, requires valid certificate for domain name
ws:// no 80 WebSocket MQTT, supports custom path (/mqtt if not provided)
wss:// yes 443 Secured WebSocket MQTT, supports custom path (/mqtt if not provided), requires valid certificate for domain name

Authentication is optional, but if present, it should be done using basic URI parameters mqtts://username:password@example.com:1234

List of fields could be substituted in topic_up field:

device The device EUI (dev_eui by LoraWAN specification)
device_addr The device address (dev_addr by LoraWAN specification)
application The application EUI (app_eui by LoraWAN specification)
gateway The gateway mac address
network The network of gateways identifier
type The type of message (uplink / join / error / e.t.c.)

QoS

All messages are sent using MQTT QoS = 1

It means, that your broker MUST acknowledge with PUBACK all of the messages.

Timeout for the one awaiting message is 1 second

Maximum awaiting messages is 100 messages

Reconnections

If the connection to broker dropped, the connector is trying to reconnect to it. The timeout for that is the following. It starts with 0.1s and doubles every following fail, the maximum timout is 60s.

Missed messages

During the reconnect, the connector requests old messages from NS since the time connection is dropped.

Adapter Working Cycle

Once the conncection to the MQTT broker is established, the connector will start to PUBLISH data to the generated topic_up.

If the topic_down is provided, the connector will subscribe to it right after successfull connection.

Publishing messages

For the format of the messages from the Network server please refer to the corresponding section of Data API.

Subscribing for messages

For the format of the messages to the Network server please refer to the corresponding section of Data API.

You need to send proper Data API JSON message.

If your messages is not JSON it will be silently discarded.

Example of usage

What this example is about:

  • You have MQTT broker with the following URI: mqtt://example.com
  • You will receive uplink messages to the topic /lora/uplink and downlink_request messages to /lora/downlink_request
  • You will send messages to the Network server by publishing to the topic /donwstream

What you should do:

  1. Create a filter in the NS for the data you want to receive. Select uplink and downlink_response types.
  2. Create MQTT connection with the following

    • URI = mqtt://example.com
    • Filter ID = the one of the filter you have just created.
    • Publish topic = /lora/{type}
    • Subscribe topic = /downstream
  3. After creation, the connector connects to your broker and starts to send messages.

Example of uplink message:

> Topic: /lora/uplink
{
  "params": {
    "payload": "MzQ3NjcwNjFiNDc3NGU2ZmFiZjBhNmY4YTJjYmI0Y2M=",
    "port": 7,
    "duplicate": false,
    "counter_up": 3,
    "rx_time": 1532073817.157281,
    "encrypted_payload": "pLgR8Tzh3JptkhtozJ5OlFuS3zQCygWD5hmx9zMjLnU="
  },
  "meta": {
    "network": "e23d2f31af81b25ef50375b5b7810c52",
    "packet_hash": "73465c1ed0cae413816d0f78baf3dcc2",
    "application": "1293e9e373666fd5",
    "device_addr": "d242b7a6",
    "time": 1532073817.175208,
    "device": "b2b48f713c2f973d",
    "packet_id": "f577207419bb4701ff9f7874c2e2808e",
    "gateway": "92a199d4e41ab64b"
  },
  "type": "uplink"
}

Example of downlink_request message and downlink_response message reply back

> Topic: /lora/downlink_request
{
  "params": {
    "counter_down": 3,
    "max_size": 51,
    "tx_time": 1532075747.295559
  },
  "meta": {
    "network": "12b5d8a8df8d9255c65d6d565d836a9d",
    "packet_hash": "cf59f7bf410a9eb23383f41342c3c7fe",
    "application": "6264dd6a1b4e9ca1",
    "device_addr": "f22eef89",
    "time": 1532075746.335046,
    "device": "c20ba71a9affafc6",
    "packet_id": "a8b464039cca609bed00f8ec58f494fe",
    "gateway": "524d07d7ef40dea3"
  },
  "type": "downlink_request"
}


< Publish: /dowstream
{
  "meta": {
    "application": "6264dd6a1b4e9ca1", 
    "device": "c20ba71a9affafc6", 
    "device_addr": "f22eef89", 
    "gateway": "524d07d7ef40dea3", 
    "network": "12b5d8a8df8d9255c65d6d565d836a9d", 
    "packet_hash": "cf59f7bf410a9eb23383f41342c3c7fe", 
    "packet_id": "a8b464039cca609bed00f8ec58f494fe", 
    "time": 1532075746.335046
  }, 
  "params": {
    "counter_down": 3, 
    "payload": "220de733f4", 
    "port": 50
  }, 
  "type": "downlink_response"
}

Class C downlink_claim

To send class C downlink message you need to send downlink_claim message

< Publish: /dowstream
{
    "meta": {
        "device": "d2953b67bca671a6", 
        "network": "12024f9efc46a98120a6fac272a9c3a4"
    }, 
    "type": "downlink_claim"
}

results matching ""

    No results matching ""