What's the minimal input to register a device through the HTTP API

TTN V2 to V3 Upgrade V3 Devices
1

Hello and thanks for reading,

I’ve build a program in V2 based on he available SDKs where I was able to register any device and have it work using nothing more than the Dev- AppEUI and AppKey.

The idea is that this is meant for different work related projects in which customers are technically needing to rely on TTN but are not supposed to interact with it directly and have presumably no technical knowledge.

Upgrading to V3, I am building another program with the same purpose. I am setting devices in my application through the End Device API.

The json-body of an end device can contain so much more information than just three hex strings (V2).
I’ve been practically experimenting for days to find out how much information I really need to feed the servers to have an Otaa-Device join successfully and I keep getting all sorts of problems. Mainly any join request being denied serverside because it’s being seen as an ABP.
Adding the “supports_join”:true-field has the network server complaining about missing sessionkeys.

So therefore my question. Are fields like Lorasettings and MAC-Settings necessary? V2 didn’t differentiate it seems. In the end, we don’t expect anything more than writing down some keys and a device type from an end-user.

2

We are all on the very same voyage of discovery as TTSv3 is so new.

The TTI dev team recommended technique is to use the console to set something up and look at the API call / JSON payload that the browser sends. I find that if a field is present that I’ve not filled in, then it’s usually because the API needs to know that the field is meant to be empty. Ironically the use of Protocol Buffers does not do us the same curtesy.

3

I looked properly at those json calls again, thanks for that, took it as base and tested what can be removed. So I can answer my own question now. My json-bodies are now reduced to this:

To the app:
{
“end_device”: {
“ids”: {
“device_id”: “testcreati0n001”,
“dev_eui”: “A84041B45182AD7F”,
“join_eui”: “A000000000000101”
},
“join_server_address”: “eu1.cloud.thethings.network”,
“network_server_address”: “eu1.cloud.thethings.network”,
“application_server_address”: “eu1.cloud.thethings.network”
}
}

To the joinserver:
{
“end_device”: {
“ids”: {
“device_id”: “testcreati0n001”,
“dev_eui”: “A84041B45182AD7F”,
“join_eui”: “A000000000000101”
},
“root_keys”: {
“app_key”: {
“key”: “XXXX”
}
},
“network_server_address”: “eu1.cloud.thethings.network”,
“application_server_address”: “eu1.cloud.thethings.network”
},
“field_mask”:{
“paths”:[
“root_keys.app_key.key”
]
}
}

To the networkserver:
{
“end_device”: {
“ids”: {
“device_id”: “testcreati0n001”,
“dev_eui”: “A84041B45182AD7F”,
“join_eui”: “A000000000000101”
},
“frequency_plan_id”: “EU_863_870_TTN”,
“lorawan_phy_version”: “PHY_V1_0_3_REV_A”,
“lorawan_version”: “MAC_V1_0_3”,
“supports_join”: true
},
“field_mask”:{
“paths”:[
“frequency_plan_id”,
“lorawan_phy_version”,
“lorawan_version”,
“supports_join”
]
}
}

To the applicationserver:
{
“end_device”: {
“ids”: {
“device_id”: “testcreati0n001”,
“dev_eui”: “A84041B45182AD7F”,
“join_eui”: “A000000000000101”
}
}
}

Perhaps this can help people who generally struggle with HTTP-Calls and gives them an example.

1 Like