ResIOT, Uplinks and Downlinks¶

Uplinks¶

Uplinks are radio packets received by your gateways. These messages are encrypted and only those coming from registered devices can be decrypted by the server. The server will discard data coming from devices that do not belong to you and will try to decode incoming data with the device data you provided to the server.

ResIOT has 2 differents log reports for uplinks: one for the raw data, and one for the decoded, application, aggregated data.

comm_gwrx¶

This is a raw radio packet received by one of your gateways. ResIOT will try to understand if the data is coming from one of the devices registered to your network. If it is, a Mine field will be set to true and it will generate a comm_rx log. If the data is coming from a device that doesn't belong to you, a red the field will be set to false.

comm_rx¶

A packet received by the gateway(s) was sent from one of your devices. The ResIOT server will decode it and print all the application data received (payload) in an hex encoded format. If the message was received by multiple gateways(multiple comm_gwrx logs), the server will try to aggregate them into a single comm_rx log.

Downlinks¶

Downlinks are radio packets sent from the gateway. They're intended to reach your devices. ResIOT allows to send downlinks through several channels: api, graphic interface, scripting, etc... The server will acknowledge your downlink request at several levels. All of these elements share the same reference field.

Here's how to follow a downlink throught ResIOT interface:
- comm_gwtx: The server is requesting a downlink to a gateway.
- comm_txinfo: The basestation server received the request.
- comm_txsendack: The gateway received the request. The gateway will let us know if transmitting the data was successfull.
- comm_txsendconfirm: The platform lets you know if the request was handled and its result (elaboration of all the above steps).
- comm_txconfirm: The device confirms having received the packet (if you sent a Confirmed downlink).

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."}