KPN LoRa Developer Portal

  • 22 september 2016
  • 33 reacties
  • 22860 keer bekeken

Reputatie 2
Badge +1

Getting started with the free KPN LoRa developer portal


The LoRa developer portal was built to enable developers free access to the KPN LoRa network. This portal allows testing with up to 10 devices for a period of 6 months.
The developer portal can be used for testing with Class A Activation-By-Personalisation (ABP) and Class A Over-The-Air-Activation (OTAA) devices. Note that on the KPN live network, only OTAA devices are allowed and it is thus recommended to start developing with OTAA right away.
All a developer has to provide is a forwarding address (endpoint) for the Application Server to get the device credentials (DevEUI, AppSKey and NwkSKey, in case of an ABP device). Upload these credentials to your LoRa device and you are good to go.

Differences between ThingPark and the Developer Portal


The aim of the KPN Lora Developer Portal is to enable users to quickly connect their LoRa device to the KPN Lora network. Where possible, the functionalities and concepts similar to those used in ThingPark (the portal for contracted customers) are applied for using the Developer Portal. This means that a device and Application Server working with the Developer Portal should also work with ThingPark. But there are a few differences:
  • The NwkSKey and AppSKey are generated by KPN (as a consequence, device-clientserver encryption is not possible).
  • Only device Class A is supported.
  • The same processes, elements and formats are used where possible, however there will remain some differences with full-scale implementation on the KPN LoRa network.
  • The Developer Portal is provided based on 'Best effort' support. This means no direct support and no uptime guarantees.
  • The Developer Portal is meant for testing purposes, no commercial exploitation is allowed
  • Fair use policy applies, limited downlink and uplink capacity (average 6 uplink/hour, 2 downlink/hour)
  • A limited duration of 6 months applies. After 6 months, accounts are automatically locked
  • An important difference between the developer portal and the KPN live environment is that the restriction on the ports that can be used is not implemented on the developer portal. In the live environment port 443 should be used for forwarding messages.

More technical information can be found in the documentation on the developer portal itself.

33 reacties

Hello,
It appears the developer portal is down.
https://loradeveloper.mendixcloud.com/index.html does not produce any response, no login request, etc.

Pim
Reputatie 2
Badge +1
Hi MikenAhh,

Seeing your payload I suspect you are using the Microchip RN2483 to send LoRa data. It so happens that I have some experience with it so I know what is going on. You are sending to LoRa port 88. The LoRa Developer Portal only supports sending on port 1. Any other port will result in encrypted data and cannot be guaranteed to arrive.

Please use
code:
mac tx uncnf 1 30
.

Michiel
Reputatie 2
Badge +1
Hi all,

We have done a reset and everything seems to work again. We will try to figure out what went wrong in the meantime.

Cheers,

Michiel
Reputatie 2
Badge +1
All, there was a memory problem somewhere which we are monitoring now. Right now, however, we cannot reproduce a problem at our side. Is the portal still not working at your side?
Thanks It s working now.
Hi Tim,
It was down till ~10:00 this morning.
Someone must have kicked it.
It's back up again.
tnx
Pim
Reputatie 7
Badge +11
@michieljol
Is there a description somewhere of each of these properties what data they contain?

Hi mikenahh,

We've posted a new topic with all properties explained.
You can find the topic here: LoRa | Dictionary & Definitions.
Reputatie 7
Badge +11
Hello Guus,

The developer portal supports only DevEUI’s provided by KPN (for technical reasons). The commercial service allows for the use of your own DevEUI’s or those provided by hardware manufacturers.
The DevAddr will always be provided by the KPN network (in both ABP and OTAA situations).
I think you’re referring to OTAA devices, this is unfortunately not possible to test yet on the Developer Portal. We’re working on a version where OTAA is also supported.

If you want to develop a commercial Lora service and need to test OTAA devices, please contact iot@kpn.com to discuss the possibilities.
Reputatie 7
Badge +11
Hello,
It appears the developer portal is down.
https://loradeveloper.mendixcloud.com/index.html does not produce any response, no login request, etc.

Pim

Hi Pim, I can login to the developer portal. I'm not sure if there was any down time this weekend. Do you also have access again?


Hello

for a project, I am interested in getting on touch with developers familiar with KPN LoRaWan as well as the development of IoT applications.

If interested, please contact me on my email : ensamine@gmail.com

Cheers

Amine

Hello Amine, I've noticed you also posted a call-up in another thread. Maybe it's better to create a new topic to get a better scope on your post!
Reputatie 7
Badge +11
Hi Tim,
It was down till ~10:00 this morning.
Someone must have kicked it.
It's back up again.
tnx
Pim

Thanks for your reply, good to hear it's up and running again. I'll try to find out what was causing this down time! 😞
Reputatie 7
Badge +11
Hello Martijn, welcome to the LoRa Forum :)

However, these packets are not received at the given destination endpoint. (a node-red application server). I know this endpoint works because the same evening I also did some tests with the uplink test button in the developer portal, and those messages were successfully received in node-red.
Could you try and sent some (new) lora packets from the device to your application server? We already know your DevEui (from the image - thanks!). If you can let us know at what times the packets has been sent, we can try to look them up to see what's going wrong.
Reputatie 7
Badge +11

  • Only device Class A is supported.

Is het nog steeds zo dat het Developer Portal alleen Class A ondersteund?


Nee, voor zover ik weet ondersteunen we momenteel Class A & C. Zowel op de productie omgeving als op de developer portal.
Reputatie 2
Badge +1
@vidavidorra: Yes, the java problem is unfortunate, and still work in progress. By using a hookbin.com endpoint you could see your payload. On the github of the IoT Academy an example is posted. Here you can see that some information you require is visible in this payload. Does this help?
Reputatie 2
Badge +1
Cheers. Just to be clear: values are 0 or null because you hit the test button in the Developer Portal. Thanks also for the feedback, we will consider it in our next version of the developer portal.

Cheers,

Michiel
Reputatie 2
Badge +1
Hi All, I have the same problem myself. Will check what's going on.
Reputatie 2
Badge +1
@Robbrecht: Thank you for your message. Although I cannot see anything wrong right now I will forward your message to the technicians.
I have registered for the developer portal but most of the lora devices I have seen, do not have an option to change de devEUI. In de dev portal the only option was the provided keys AND devEUI by KPN. Also have no problem to register for a commercial service if those options are available..

Did I overlook something? What commercially available devices support to programm your own devEUI?
@michieljol

Iam experimenting with sending data from a device using the KPN platform. Iam trying to send a 0 from my device. Inside my device before sending the data this gets translated to a hex value of 30.
So in my device i execute the command "mac tx uncnf 88 30".
The packages get recieved by KPN but the payload has strange values. See image.
The value iam expecting to see in the list is 30.
Is there some encryption in the data or am i missing something?
@michieljol

Thank you for the quick response, i tested it and now it works.
@michieljol
Is there a description somewhere of each of these properties what data they contain?
code:

{
"LrrSNR": "0",
"Lrrid": null,
"SpFact": 0,
"SubBand": null,
"CustomerData": null,
"FPort": 1,
"Channel": null,
"FCntUp": -1,
"Time": null,
"DevEUI": "0059AC00001811D8",
"payload_hex": "000000",
"CustomerID": 0,
"LrrRSSI": "0",
"ADRbit": 0,
"ModelCfg": 0,
"mic_hex": null,
"LrrLON": "0",
"LrrLAT": "0",
"FCntDn": 0,
"Lrcid": null,
"DevLrrCnt": 0
}
@michieljol Are there any functionality additions planned for the developer portal?

A huge functionality I am missing in the developer portal is the ability to see information about the received signal. Two things I really want to see as a developer are:
1. Which antenna has received the signal (i.e. LRR Lat and LRR Long)
2. Signal and noise figures (RSSI, SNR, ESP)

Do you have any insight on whether these functionalities are planned and when they would be available in the developer portal. At the moment I also don't know whether the JSON, send to the application, contains such information since the SSL-Certificates issue (https://zakelijkforum.kpn.com/lora-forum-16/application-server-ssl-certificates-8311).
@michiel I just performed a quick test by using hookbin as endpoint and can confirm that the 1. and (partially) 2. are included in the JSON. So that information is (except ESP) available in the JSON. However, I still think it would be useful if those fields were available in the Developer Portal's debug table view. For more detail see the test JSON from hookbin below.

code:

{
"LrrSNR": "0",
"Lrrid": null,
"SpFact": 0,
"SubBand": null,
"CustomerData": null,
"FPort": 1,
"Channel": null,
"FCntUp": -1,
"Time": null,
"DevEUI": "0059AC00001811D8",
"payload_hex": "000000",
"CustomerID": 0,
"LrrRSSI": "0",
"ADRbit": 0,
"ModelCfg": 0,
"mic_hex": null,
"LrrLON": "0",
"LrrLAT": "0",
"FCntDn": 0,
"Lrcid": null,
"DevLrrCnt": 0
}
The same problem here. Sign in failed on the developer portal. Also this account was activated < 10 weeks.
@michieljol Developer portal seems down again. Did you get a chance to look into the reason why it stopped working last week?
It's working. Before that the portal responded very slow before giving a login failure, so a memory probleem seems likely. Last time the service also stopped working in a weekend from saturday to sunday. Maybe a weekly scheduled job that causes a memory overrun?

Reageer