Skip to content

2. Parsing KPN LoRa

Jump to bottom
MichielJol edited this page Sep 10, 2016 · 13 revisions

In the first exercise you created your own server to listen and respond to HTTPS posts. In the second exercise we will move on to receive LoRa payload and parse it to be able to manipulate the data.

#Forwarding KPN LoRa to NodeRed Let's now point our data to our /lorapost listener we've created in the first exercise, if you haven't done already:

  1. KPN LoRa Developer Portal: go to your dashboard, click on devices and edit the device you want to forward. Under the Destination URL fill in the destination URL from your first exercise, for instance 'https://yourname.eu-gb.mybluemix.net/lorapost'. If you now hit the test button, you will see a simulated KPN LoRa message in the debug tab of NodeRed.

  2. KPN Thingpark (paying customers only): You will need to go to your deviceManager and adjust the application profile to have a destination URL matching the destination from the first exercise. Important here is to add an extra '/' at the end for it to work (so https://yourname.eu-gb.mybluemix.net/lorapost/ for example).

  3. You will see a lot of information coming into your application server. To easily inspect all elements of the message we have created a github repository showing a example of a LoRa message here. There is a slight difference between using the KPN Developer Portal or KPN Thingpark (paying customers only):

  4. A KPN LoRa post consists of information in the query-parameters, some headers (which we are not going to use for now) and a J-SON body. Note that you have to select the J-SON output in Thingpark Application Server to get J-SON instead of XML.

  5. The J-SON body has a payload_hex parameter or, in case of Thingpark, it has a extra layer DevEUI_uplink which again contains a payload_hex. Can you spot other parameters like the Spreading Factor (SF) or DevEUI?

  6. The query-parameters include a AS_ID and a Token. The token was generated by the server with a SHA256 method using a secret SHA key. Later, in the next exercise, we will check the validity of this key to know for sure that the message originates from our own device.

ProTip: To speed up your development you don't want to wait every 5 minutes for a LoRa message to check if a change works on your machine. The KPN LoRa Developer portal has a test-payload functionality for this. If you edit a device you can click on test to simulate a LoRa payload from that device. If you want to have more control over the message we have created simple simulator instructions here, using Postman to post message equivalent to a LoRa message as much as you like!

#Parsing LoRa Data

Exciting! Now it's time to move on and check our token.

Clone this wiki locally