How to Migrate OTAA Devices from V2 to V3

bluejedi · February 8, 2021, 11:57pm

Yes that’s correct. Where would you want to migrate to if the target is not yet available?

In the mean time you could already have a look at the V3 documentation and the topics in the V2 to V3 Upgrade category.

clery · February 9, 2021, 1:40am

Thank you. Another question: I have V2 devices that are buried and programmed to only transmit if an erosion event occurs and the device is exposed - possibly years from now. Will these V2 devices still be able to communicate through our updated V3 stack as long as they are able to detect network loss and rejoin via OTAA?

descartes · February 9, 2021, 9:22am

Yes, as long as it’s migrated to the V3 stack.

Test several units for reassurance!

I’d personally start burying ABP devices going forward, less reliant on hearing any downlink so the message is more likely to get through as gateway antennas are pretty good at hearing but partially buried devices not so much.

clery · February 9, 2021, 4:35pm

OK, thank you both for the prompt replies!

BK-Vest · February 10, 2021, 12:08pm

Is there any http-Integration on V3? (webhook)

Like V2: HTTP | The Things Network

Backround: I had a application with http-integration

Access Key

The access key used for downlink
default key

URL
The URL of the endpoint
https://xyz

Method
The HTTP method to use
POST

How will be made the Integration in TTS V3?

E_T

bluejedi · February 10, 2021, 4:40pm

See V3 documentation.

Next time do some searching on the forum first.

BK-Vest · February 10, 2021, 11:09pm

I read the V3 documentation, but i can’t find a solution!
Creating Webhooks | The Things Stack for LoRaWAN (thethingsindustries.com)

In V3 I have to make decisions for which I have no information because I did not have to set this before in V2!

I am only user of the interface!

I only see, that the infercae workes not for me!

E_T

bluejedi · February 10, 2021, 11:38pm

If you want other users to be able to help you you should be more specific.
(I have not used the webhooks myself.)

Please give any details like.

What did you expect?
What is different?
What are you missing?
For what exactly do you need help.

TTN V3 is still new and TTI has not worked out all migration guides yet unfortunately.

descartes · February 10, 2021, 11:38pm

It’s almost identical to V2. I didn’t even break step setting up a WebHook using my V2 PHP scripts - no changes in PHP, just a change of UI but still very similar in V3.

There are some additional options, but if you don’t need them, don’t worry about them. About the only extra you do have to choose is JSON vs Protocol Buffers - V2 was only JSON, so stick with that.

BK-Vest · February 12, 2021, 7:40pm

What are the settings in the webhook to get the behavior of the old settings?

Is it possible that the changed format for the payload on the server side leads to problems?

E_T

Like this:
webhook1

descartes · February 12, 2021, 9:02pm

The id is like v2, something you can use to id the HTTP integration / Webhook

Webhook format should be JSON (it’s what we had in V2, I don’t have time to learn Protocol Buffers and I have a PHP script that can semi-auto read JSON)

The Base URL is the v2 URL.

The rest can be left alone unless your script requires some authorisation id.

You will have to make substantive changes to picking out the data you want from the new expanded format, but it’s still just JSON. But it’s just a different structure. Not something I’d describe as leading to problems, just different.

BK-Vest · February 16, 2021, 12:20pm

Ok, thanks!

bluejedi · March 5, 2021, 3:34pm

A post was split to a new topic: Importing devices in V3 with JSON generated by V2 ttn-lw-migrate tool fails

s54mtb · April 14, 2021, 8:10am

Tool in WIN10. First I set:

D:\tmp\migrate_ttn>set TTNV2_APP_ID="my-ttn-app"
D:\tmp\migrate_ttn>set TTNV2_APP_ID="nmpmaq"
D:\tmp\migrate_ttn>set TTNV2_APP_ACCESS_KEY="ttn-account-v2.2iw3xxxxxxxxxxxxxx9qctlwV7jCowj2Nc"
D:\tmp\migrate_ttn>set FREQUENCY_PLAN_ID="EU_863_870_TTN"
D:\tmp\migrate_ttn>set TTNV2_DISCOVERY_SERVER_ADDRESS="discovery.thethings.network:1900"

Then I run the tool and got errors:

D:\tmp\migrate_ttn>ttn-lw-migrate devices --dry-run --verbose --source ttnv2 nmpmaq-00059590f10fe481
 DEBUG [core]parsed scheme: ""
 DEBUG [core]scheme "" not registered, fallback to default scheme
 DEBUG [core]ccResolverWrapper: sending update to cc: {[{"discovery.thethings.network:1900"  <nil> 0 <nil>}] <nil> <nil>}
 DEBUG [core]ClientConn switching balancer to "pick_first"
 DEBUG [core]Channel switches to new LB policy "pick_first"
 DEBUG [core]Subchannel Connectivity change to CONNECTING
 DEBUG [core]Subchannel picks a new address "\"discovery.thethings.network:1900\"" to connect
 DEBUG [core]pickfirstBalancer: UpdateSubConnState: 0xc00062f7d0, {CONNECTING <nil>}
 DEBUG [core]Channel Connectivity change to CONNECTING
  WARN [core]grpc: addrConn.createTransport failed to connect to {"discovery.thethings.network:1900" "discovery.thethings.network:1900" <nil> 0 <nil>}. Err: connection error: desc = "transport: Error while dialing dial tcp: lookup tcp/1900\": getaddrinfow: The specified class was not found.". Reconnecting...
 DEBUG [core]Subchannel Connectivity change to TRANSIENT_FAILURE
 DEBUG [core]pickfirstBalancer: UpdateSubConnState: 0xc00062f7d0, {TRANSIENT_FAILURE connection error: desc = "transport: Error while dialing dial tcp: lookup tcp/1900\": getaddrinfow: The specified class was not found."}
 DEBUG [core]Channel Connectivity change to TRANSIENT_FAILURE
 DEBUG [core]Subchannel Connectivity change to CONNECTING
 DEBUG [core]Subchannel picks a new address "\"discovery.thethings.network:1900\"" to connect
 DEBUG [core]pickfirstBalancer: UpdateSubConnState: 0xc00062f7d0, {CONNECTING <nil>}
 DEBUG [core]Channel Connectivity change to CONNECTING
  WARN [core]grpc: addrConn.createTransport failed to connect to {"discovery.thethings.network:1900" "discovery.thethings.network:1900" <nil> 0 <nil>}. Err: connection error: desc = "transport: Error while dialing dial tcp: lookup tcp/1900\": getaddrinfow: The specified class was not found.". Reconnecting...
 DEBUG [core]Subchannel Connectivity change to TRANSIENT_FAILURE
 DEBUG [core]pickfirstBalancer: UpdateSubConnState: 0xc00062f7d0, {TRANSIENT_FAILURE connection error: desc = "transport: Error while dialing dial tcp: lookup tcp/1900\": getaddrinfow: The specified class was not found."}
 DEBUG [core]Channel Connectivity change to TRANSIENT_FAILURE
 DEBUG [core]Subchannel Connectivity change to CONNECTING
 DEBUG [core]Subchannel picks a new address "\"discovery.thethings.network:1900\"" to connect
 DEBUG [core]pickfirstBalancer: UpdateSubConnState: 0xc00062f7d0, {CONNECTING <nil>}
 DEBUG [core]Channel Connectivity change to CONNECTING
  WARN [core]grpc: addrConn.createTransport failed to connect to {"discovery.thethings.network:1900" "discovery.thethings.network:1900" <nil> 0 <nil>}. Err: connection error: desc = "transport: Error while dialing dial tcp: lookup tcp/1900\": getaddrinfow: The specified class was not found.". Reconnecting...
 DEBUG [core]Subchannel Connectivity change to TRANSIENT_FAILURE
 DEBUG [core]pickfirstBalancer: UpdateSubConnState: 0xc00062f7d0, {TRANSIENT_FAILURE connection error: desc = "transport: Error while dialing dial tcp: lookup tcp/1900\": getaddrinfow: The specified class was not found."}
 DEBUG [core]Channel Connectivity change to TRANSIENT_FAILURE
 DEBUG [core]Subchannel Connectivity change to CONNECTING
 DEBUG [core]Subchannel picks a new address "\"discovery.thethings.network:1900\"" to connect
 DEBUG [core]pickfirstBalancer: UpdateSubConnState: 0xc00062f7d0, {CONNECTING <nil>}
 DEBUG [core]Channel Connectivity change to CONNECTING
  WARN [core]grpc: addrConn.createTransport failed to connect to {"discovery.thethings.network:1900" "discovery.thethings.network:1900" <nil> 0 <nil>}. Err: connection error: desc = "transport: Error while dialing dial tcp: lookup tcp/1900\": getaddrinfow: The specified class was not found.". Reconnecting...
 DEBUG [core]Subchannel Connectivity change to TRANSIENT_FAILURE
 DEBUG [core]pickfirstBalancer: UpdateSubConnState: 0xc00062f7d0, {TRANSIENT_FAILURE connection error: desc = "transport: Error while dialing dial tcp: lookup tcp/1900\": getaddrinfow: The specified class was not found."}
 DEBUG [core]Channel Connectivity change to TRANSIENT_FAILURE
 DEBUG [core]Subchannel Connectivity change to CONNECTING
 DEBUG [core]Subchannel picks a new address "\"discovery.thethings.network:1900\"" to connect
 DEBUG [core]pickfirstBalancer: UpdateSubConnState: 0xc00062f7d0, {CONNECTING <nil>}
 DEBUG [core]Channel Connectivity change to CONNECTING
  WARN [core]grpc: addrConn.createTransport failed to connect to {"discovery.thethings.network:1900" "discovery.thethings.network:1900" <nil> 0 <nil>}. Err: connection error: desc = "transport: Error while dialing dial tcp: lookup tcp/1900\": getaddrinfow: The specified class was not found.". Reconnecting...
 DEBUG [core]Subchannel Connectivity change to TRANSIENT_FAILURE
 DEBUG [core]pickfirstBalancer: UpdateSubConnState: 0xc00062f7d0, {TRANSIENT_FAILURE connection error: desc = "transport: Error while dialing dial tcp: lookup tcp/1900\": getaddrinfow: The specified class was not found."}
 DEBUG [core]Channel Connectivity change to TRANSIENT_FAILURE
 DEBUG [core]Subchannel Connectivity change to CONNECTING
 DEBUG [core]Subchannel picks a new address "\"discovery.thethings.network:1900\"" to connect
 DEBUG [core]pickfirstBalancer: UpdateSubConnState: 0xc00062f7d0, {CONNECTING <nil>}
 DEBUG [core]Channel Connectivity change to CONNECTING
  WARN [core]grpc: addrConn.createTransport failed to connect to {"discovery.thethings.network:1900" "discovery.thethings.network:1900" <nil> 0 <nil>}. Err: connection error: desc = "transport: Error while dialing dial tcp: lookup tcp/1900\": getaddrinfow: The specified class was not found.". Reconnecting...
 DEBUG [core]Subchannel Connectivity change to TRANSIENT_FAILURE
 DEBUG [core]pickfirstBalancer: UpdateSubConnState: 0xc00062f7d0, {TRANSIENT_FAILURE connection error: desc = "transport: Error while dialing dial tcp: lookup tcp/1900\": getaddrinfow: The specified class was not found."}
 DEBUG [core]Channel Connectivity change to TRANSIENT_FAILURE

What is wrong?

descartes · April 14, 2021, 8:12am

Port 1900 is blocked?

KrishnaIyerEaswaran2 · April 14, 2021, 9:03am

Use

TTNV2_DISCOVERY_SERVER_ADDRESS=discover.thethingsnetwork.org:1900

zacn · June 30, 2021, 3:33am

Is it possible to use this strategy (i.e. changing the AppKey) to move a device from between applications on the v3 stack? Or for that matter on the v2 stack?

kersing · June 30, 2021, 6:32am

It can be done on both. However it does put additional load on the stack to determine which application should be used. And you can just as easily delete the device and and it in the other application. And back…
If you use the command line tool to add an device you can even create a batch file to first delete and next add.

V2 will become ‘read only’ today so you should be moving devices away from it. Not between applications on the V2 stack.

Inou · August 10, 2021, 4:12pm

Hello all, I was wondering: since TTN V2 has become read only since the beginning of July I can’t change the AppKey anymore of devices in V2 in order to prevent them from joining again with V2 except from deleting the device all complete.

But since that has the risk of devices not being able to reach anymore, I was wondering if there is any alternative right now for this?

descartes · August 10, 2021, 5:38pm

I was just talking to @Jeff-UK on exactly that issue as he’s ended up with some devices that won’t move over as there are still v2 gateways around them and I’m sure I’ll be hit with that issue too.

I’m trying out the CLI to see if we can alter the AppKey from there - if not, we’ll be petitioning TTI to allow AppKey edits on the console.

The plus point of the conversation is that the last seen timestamp and the fcnt is available for a device using the CLI so we can at least tell which devices are still alive.