Migrate device to new Application

End Devices (Nodes)
1

Hi,
TTN Noob here. What’s the best way to move a device which is already registered in Application A over to Application B?
Thx
JP

2

Hi @Maj,

Would you have any ideas on this one? I’ve been searching through the forums but as yet haven’t found a straight answer…

Thx
JP

3

Depends of a few factors.
If it’s an OTAA device then it will need to rejoin the network when you register it in the new application. If you have physical access to the device, then just delete it from Application A (take note of DevEUI, AppEUI, AppKey), reregister in Application B and reboot the device.

If you don’t have physical access to the device, and it supports Network Link Check, then reregister and wait for it to rejoin the network.

If you don’t have physical access and it doesn’t support link check, then some further thinking is required.

2 Likes
4

Thanks!!
JP

5

I’ve seen that before, so you’re probably right, but I wonder if that’s always the case.

The scheme that TTN uses to assign a DevAddr indeed makes it impossible to, for example, move devices between regions, or from TTN to Meshed. A new join would then get it a proper DevAddr.

But when moving devices within the same region, I wonder if the command line ttnctl devices set could be used to change the DevAddr (and NwkSKey and AppSKey) after migration?

(I guess not, as on Slack @htdvisser also wrote that OTAA devices need to rejoin, though that was in the context of his migration tool. It’s actually easily tested, though maybe one successful test does not guarantee it will always work.)

6

Generally speaking, when you migrate a device from one network to another, the device needs to perform a new Join procedure. The Things Network treats different clusters as different networks, so if you migrate to a different cluster, the device also needs to perform a new Join procedure.

We strongly recommend to follow this :point_up:, but if that’s impossible:

When migrating a device between different applications of the same v2 cluster, the device can keep using the old DevAddr until it performs a new Join procedure. I think my migration tool already lets you do this, but otherwise you can indeed use ttnctl to force the new registration to use the old DevAddr.

When migrating a device to a The Things Stack (v3) cluster, the device can keep using the old DevAddr until it performs a new Join procedure, but with some limitations. It will only have connectivity from gateways that are connected to the same cluster and there is no roaming/peering possible.

1 Like
7

I completely forgot about using ttnctl to set nwk-s-key and app-s-key!
So even if the device doesn’t support network link check and won’t rejoin, there’s still a way to keep the device communicating.

8

Thanks @Maj, @htdvisser & @arjanvanb for your advice.

Can you provide the correct link to the docs that covers the use of ttnctl and the Join procedure @htdvisser mentions?

Thx
JP

9

The Join procedure that Hylke mentioned is just an OTAA Join. The other documentation has already been linked above. But if using ttnctl, or even finding its documentation gives you problems, then I’d not try to use it, but just do things manually:

10

Ok thanks,
JP