-
Notifications
You must be signed in to change notification settings - Fork 9
2. Parsing KPN LoRa
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 LoRa data to your server
Let's now point our data to our /lorapost
listener we've created in the first exercise.
#Structure of KPN LoRa messages We've 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).
- Here you can see that 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.
- The J-SON body has a
payload_hex
parameter or, in case of Thingpark, it has a extra layerDevEUI_uplink
which again contains apayload_hex
. Can you spot other parameters like the Spreading Factor (SF) or DevEUI? - The query-parameters include a
AS_ID
and aToken
. 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. That's why we have created simple simulator instructions here, using Postman to post message equivalent to a LoRa message as much as you like!
Let's move on to set up our application server.
#Parsing LoRa Data
Exciting! Now it's time to move on and check our token.