Skip to content

Downlink via MQTT

If you're running a broker, you can create a MQTT Server pusher over ResIOT and use it to trigger downlinks over the platform.

Want to know more about MQTT pushers?

If you want to learn more about how downlinks work over ResIOT feel free to refer to this page.

In order to do so:

{
  "Command": "",
  "appEUI": "8A7628C12D7889EA",
  "askConfirmation": true,
  "devEUI": "0080A4B60410A19B",
  "extraData": "",
  "gwEUI": "0270F0B0A010D0D9",
  "payload": "PayloadEsempio",
  "port": 48,
  "raw": true,
  "reference": "testReference"
}

Feedback from the server

The server will acknowledge your downlink request at several levels. Let's dive into it.

Reaching the basestation server and feedback

The basestation server is one of the key components of the ResIOT platform. It is part of our suite of software and can be used on the server side as well as on the gateway itself.

The first thing we need to make sure of, is your downlink request is able to reach the basestation server. If everything went fine, you will get a comm_txinfo log.

If we stick to our "testReference" example, you will get an output log similar to this if you are able to reach the basestation server:

--topic
comm_txinfo/[Gateway EUI]
--body
{"CommType":"comm_txinfo","Reference":"testReference"} --along with other useful data

Reaching the gateway and feedback

If you've made it this far, the basestation server is finally ready to contact your gateway and will try to do so. If the gateway receives a downlink request from the basestation server, it will let us know our request has been received and ResIOT will report it with a comm_sendack log.

If we stick to our "testReference" example, you will get an output log similar to this:

--topic
comm_txsendack/[Gateway EUI]
--body
{"CommType":"comm_txsendack","Reference":"testReference","Error":""} --along with other useful data

The "Error" field will report is there's a problem to send the radio downlink. In case you get a "None" error, an empty "" error or you're completely missing the error field, it means the gateway managed to transmit the correct radio signal.

Final ResIOT Output

Finally, at the end of everything, the ResIOT platform will let you know if it managed to get feedback from all the required components

If we stick to our "testReference" example, you will get an output log similar to this:

--topic
comm_txsendconfirm/[Device AppEUI]/[Device DevEUI]
--body
{"CommType":"comm_txsendconfirm","AppEui":"[Device AppEUI]","DevEui":"[Device DevEUI]","Reference":"testReference","error":"none","warning":"Gateway unable to ack. Ack assumed."} --along with other useful data

The "error" field will report is there's a problem to send the radio downlink. In case you get a "none" error, it means a gateway managed to successfully send your downlink request. Otherwise, you will get an error description in the "warning" field.

Reaching the target device and feedback

If everything went fine, once you're here you know your gateway received a request and transmitted it down in the air. If you asked for a confirmation in your downlink request, you will likely get an acknoledgement from the device itself.

ResIOT will log it down over a comm_txconfirm log.

If we stick to our "testReference" example, you will get an output log similar to this:

--topic
comm_txconfirm/[Device AppEUI]/[Device DevEUI]
--body
{"CommType":"comm_txconfirm","AppEui":"[Device AppEUI]","DevEui":"[Device DevEUI]","Reference":"testReference"} --along with other useful data

Device message acknowledgement

If you haven't asked for a radio confirmation in your downlink request, there is actually no way to know if your device actually received it or not.

ResIOT Bounceback and Troubleshooting

The ResIOT platform will monitor the server and all the feedback from all devices all the way down to the gateway itself(included). Whenever an error is encountered (missing comm_txinfo/comm_txsendack or not empty error fields), the server will command another gateway to pick up the task that the first gateway failed to manage(whatever the reason).

All the communication logs exposed here report the Attempt that's being reported. Attempts start a 0. So, if we stick to our examples, you're actually getting (if we're talking about the first gateway being tried by the server):

{"CommType":"comm_txinfo","Reference":"testReference","Attempt":0} --along with other useful data
{"CommType":"comm_txsendack","Reference":"testReference","Error":"","Attempt":0} --along with other useful data
{"CommType":"comm_txconfirm","AppEui":"[Device AppEUI]","DevEui":"[Device DevEUI]","Reference":"testReference","Attempt":0} --along with other useful data

The final report will also report the number of gateways it had to try to reach in order to succeed in sending down your request. If attempt 0 was successful all the way down, you will get:

{"CommType":"comm_txsendconfirm","AppEui":"[Device AppEUI]","DevEui":"[Device DevEUI]","Reference":"testReference","error":"none","Attempts":1} --along with other useful data

This means the 1st attempt (called Attempt 0 in the previous logs) actually succeeded in sending down your downlink request.

The number of attempts will be always reported, even if you finally get an error, it's still possible to get an error after 3 attempts with 3 different gateways.

Older gateway models and acknowledgement support

Older gateways are not able to acknowledge downlink requests. In such case, the server will assume the gateway receveived the request, but will report a warning message in the final response: {"CommType":"comm_txsendconfirm","AppEui":"[Device AppEUI]","DevEui":"[Device DevEUI]","Reference":"testReference","error":"none","Attempts":1,"warning":"Gateway unable to ack. Ack assumed."}