Sending Downlink messages

  • 12 August 2016
  • 28 reacties
  • 6649 keer bekeken

Reputatie 2
Badge +1
This post has become obsolete as it was incorporated in the Setting up your Application Server topic.


Developer Portal

Sending downlink messages
All downlink messages should be sent to:
and contain the following query parameters:

- DevEUI of your device
- FPort used within LoRa (developer portal only allows port 1)
- Payload formatted as hex
- AS_ID that identifies you. You can find your AS_ID at you profile in the developer portal.
- Timestamp formatted as ISO time


Also a token should be added by computing it from SHA-256
SHA 256(DevEUI=000000000F1D8693&FPort=1&Payload=00&
Remember that the can be found at you user profile in the developer portal and is 46ab678cd45df4a4e4b375Eacd096acc in this example.

The resulting is encoded as an hex string (e.g. b5a84fe9c8921e9de359e3041a37b76c4b122f6f9b83577b5596c842052f7e62) AND added at the end of the query parameters line

Complete example



[/color]Developers can send downlink messages using the HTTPS Post API of Thingpark at

Messages should contain the following query parameters:
  • DevEUI of your device
  • FPort used within LoRa
  • Payload formatted as hex
  • AS_ID that identifies you. You can find your AS_ID at you profile.
  • Time Time of your server formatted as outlined below
  • Token as a SHA 256 signature

The timestamp should be your server time in the following format:
YYYY-MM-DDThh:mm:ss.fff+|-hh:mm (eg 2016-08-01T09:06:06.000+02:00)

- YYYY = four-digit year
- MM = two-digit month
- DD = two-digit day
- hh = two digits of hour (00 through 23)
- mm = two digits of minute (00 through 59)
- ss = two digits of second (00 through 59)
- fff = three digits of millisecond (000 through 999)
- +|-hh:mm = timezone designator (+hh:mm or –hh:mm)

It appears that there are a few inconsistencies in how Thingpark handles timezones. This will be solved in comming releases. Also the '+' in the querystring is sometimes ignored in some situations, creating problems with the SHA256 generation. The most straightforward method seems to use the UTC or ZULU timezone with this format:

Below is an example of a valid HTTPS POST message, note that you will have to use your own DevEUI and generate your own token with your LRC-AS key

When a downlink message is received succesfully, a HTTP response will tell you that the LRC queued your request.

Downlink Queue information
  • Messages are queued until next uplink frame, there is no time limit.
  • 5 messages can be queued PER DEVICE. The oldest is removed if a new one is queued.
  • Queue cannot be changed or viewed by the customer.

The IoT Academy Github contains a step-by-step explanation about how to implement an application server in NodeRed: .


Useful links

[/color]- [color=#094ab1]LoRa:[/color] Starters Guide
- [color=#094ab1]LoRa:[/color] Forum and Manuals
- [color=#094ab1]LoRa:[/color] Geolocation
- [color=#094ab1]LoRa:[/color] Dictionary & Definitions
- [color=green]FAQ:[/color] Frequently Asked Questions
- [color=green]Tools:[/color]

28 reacties

Reputatie 7
Badge +11
Hi @ErikV, ik probeer dit momenteel uit te zoeken maar heb nog geen antwoord met zekerheid. Voor zover ik weet komt hiervoor een functie beschikbaar. Ik hoop snel meer duidelijkheid te hebben en kom erop terug.

Op de developer Portal is het niet mogelijk om de queue te bekijken of berichten te annuleren.
Reputatie 7
Badge +11
Is het mogelijk om berichten die in de Lora downlink queue klaarstaan, maar nog niet naar de node zijn verzonden, te annuleren/flushen? Of wordt deze functionaliteit op korte termijn verwacht?

Is de downlink queue altijd vijf berichten groot, ook bij betaalde abonnementen?

Hi @ErikV, waar ik al een beetje bang voor was, het is niet mogelijk om de queue te zien. Wel is het in zekere zin mogelijk om berichten die in de queue staat te annuleren:
Bij het verzoeken van een nieuwe downlink is het mogelijk om de berichten die op dat moment in de queue staan te annuleren. Dat gaat met de FlushDownlinkQueue-query-parameter.

FlushDownlinkQueue (Optional)
Empties the device AS DL queue of the device (Boolean). When this parameter is set to FlushDownlinkQueue=1, the AS requests the LRC to purge the AS DL queue of the device prior to adding the DL payload transported by this HTTP POST. (also added to the dictionary)

De queue is altijd maximaal 5 berichten lang, dit geldt voor de Developer portal als ook Thingpark gebruikers.
Hi all,

It doesn't really matter what I enter as parameters, but if I try for example the following request (with all the "" correctly filled in), no downlink messages will be send:"DevEUI"&FPort=1&Payload=b0&AS_ID=""AS_ID"&Time=2017-10-30T13:36:33&Token=a4b9398b34fb7c25cb29f0b3b2272b56f1afc4e28bdf7f6ab6358b99fe52f216

Where the token is:

I always get the following response:

Does anyone know what is going on?

Kijk Han, dit is wat ik bedoel.. Gewoon onvoldoende uitleg. Nu kan het zomaar zijn dat de downlink-functionaliteit nog steeds niet op orde is via de developer-portal..