# Moving a device from Loriot to TTN **URL:** \ **Category:** End Devices (Nodes)\ **Created:** [August 29, 2018, 2:43pm UTC](https://www.thethingsnetwork.org/forum/t/moving-a-device-from-loriot-to-ttn/17295 "2018-08-29T14:43:45Z")\ **Posts on this page:** 11\ **Page:** 1
**Author:** ![mfalkvidd](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/mfalkvidd/32/46878_2.png) [@mfalkvidd](https://www.thethingsnetwork.org/forum/u/mfalkvidd)\ **Post date:** [August 29, 2018, 2:43pm UTC](https://www.thethingsnetwork.org/forum/t/moving-a-device-from-loriot-to-ttn/17295/1 "2018-08-29T14:43:45Z")
One of my clients has deployed a number of devices (using OTAA) that are currently working with Loriot. Now they have set up a TTN gateway and added the devices with keys to the TTN console. The TTN gateway sees the messages from the devices, but the messages are not routed to the application. I have read [Different LoRa Servers](https://www.thethingsnetwork.org/forum/t/different-lora-servers/13237) which discusses a similar topic. From what I understand, moving a device from one network (Loriot in this case) to another (TTN in this case) will require reprogramming of the devices to use new device IDs, because the Loriot device IDs are (naturally) not in the TTN address range. Is this correct? If not, is there some other limitation, or how can we move the devices? ---
**Author:** ![arjanvanb](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/arjanvanb/32/46626_2.png) [@arjanvanb](https://www.thethingsnetwork.org/forum/u/arjanvanb)\ **Post date:** [August 29, 2018, 3:21pm UTC](https://www.thethingsnetwork.org/forum/t/moving-a-device-from-loriot-to-ttn/17295/2 "2018-08-29T15:21:02Z")
> [@mfalkvidd](#): > > moving a device from one network (Loriot in this case) to another (TTN in this case) will require reprogramming of the devices to use new device IDs Not for OTAA. Assuming the devices have been deleted from Loriot, a new OTAA Join Request will only be handled by TTN, and then TTN will supply new session keys and a new DevAddr (with the proper prefix for the TTN network) in its Join Accept. However, your problem is: how to make the devices initiate a new OTAA Join. See also [How can an operational node be triggered to join a different network?](https://www.thethingsnetwork.org/forum/t/how-can-an-operational-node-be-triggered-to-join-a-different-network/1106) but that’s too late for existing devices. ---
**Author:** ![mfalkvidd](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/mfalkvidd/32/46878_2.png) [@mfalkvidd](https://www.thethingsnetwork.org/forum/u/mfalkvidd)\ **Post date:** [September 26, 2018, 1:57pm UTC](https://www.thethingsnetwork.org/forum/t/moving-a-device-from-loriot-to-ttn/17295/3 "2018-09-26T13:57:59Z")
Thanks for your reply arjanvanb. Sorry for the late response. We have now gotten information from the vendor that the devices use ABP. The vendor also claims the following: - the dev addr is optional when using ABP - the vendor has delivered devices with this dev addr prefix (0x14) to multiple networks, including Loriot and Blink Services and the devices work in those networks. 0x14 is KPN according to [this list](https://www.thethingsnetwork.org/docs/lorawan/address-space.html#device-address-assignment) The vendor’s information conflicts with the following: From The Things Networks [documentation for adding devices](https://www.thethingsnetwork.org/docs/devices/registration.html) using ABP: _“The device address **will be assigned by the network server** and is not customizable”_ [Laird documentation](https://assets.lairdtech.com/home/brandworld/files/LoRaWAN%20Keys%20and%20IDs%20Overview.pdf) states that DevAddr is _“End device address - Identifies the device **within the current network** ”_ I don’t see any reason for the device vendor to be intentionally misleading. Could it be that Blink Services and Loriot route all messages, regardless of dev addr prefix, but TTN doesn’t? In any case, does anyone have a suggestion on how to move these devices to TTN? Doing a new ABP (or reprogramming the devices to use OTAA) is the only solution that comes to my mind. ---
**Author:** ![nestorayuso](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/nestorayuso/32/35697_2.png) [@nestorayuso](https://www.thethingsnetwork.org/forum/u/nestorayuso)\ **Post date:** [September 26, 2018, 3:04pm UTC](https://www.thethingsnetwork.org/forum/t/moving-a-device-from-loriot-to-ttn/17295/4 "2018-09-26T15:04:20Z")
A device with an active session in a Network Server (Loriot in this example) can be migrated to another Network Server (TTN in this example) without the need of a new join or reprogram IDs or KEYs on the device. This is not the cleanest way to migrate devices to a new server but it can be done if the donor Network Server (LORIOT) can provide the current session parameters DevAddr, NwkSKey, AppSKey… and importing it to the new Network Server (TTN) as an ABP device. Steps in TTN: 1- In the web console add it as a new device, OTAA mode is only possible, type DevEUI, AppEUI and Apkey with correct values or whatever values. 2- Change the thevice settings to ABP mode, and type NwkSKey and AppSKey values provided from loriot. (DevAddr value can’t be changed from console). 3- use ttnctl to change device’s DevAddr with the value provided from loriot. And that’s it. Now you can start receiving data in TTN server (even in both servers simultaneously). BUT, there are some problems: 1- Downlink won’t work because the downlink counters will mismatch. 2- Some lorawan settings can be different between TTN and Loriot, for example channel plan, DL2 datarate… ---
**Author:** ![mfalkvidd](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/mfalkvidd/32/46878_2.png) [@mfalkvidd](https://www.thethingsnetwork.org/forum/u/mfalkvidd)\ **Post date:** [September 26, 2018, 3:21pm UTC](https://www.thethingsnetwork.org/forum/t/moving-a-device-from-loriot-to-ttn/17295/5 "2018-09-26T15:21:19Z")
Thanks nestorayuso! We do have access to all keys so we’ll try this. ---
**Author:** ![arjanvanb](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/arjanvanb/32/46626_2.png) [@arjanvanb](https://www.thethingsnetwork.org/forum/u/arjanvanb)\ **Post date:** [September 26, 2018, 3:42pm UTC](https://www.thethingsnetwork.org/forum/t/moving-a-device-from-loriot-to-ttn/17295/6 "2018-09-26T15:42:42Z")
> [@nestorayuso](#): > > use ttnctl to change device’s DevAddr with the value provided from loriot Did you (recently) try that? Even if it works today, I’m quite sure it’s not a future proof way to do this. @htdvisser has been very clear about this: > [@Can I register an ABP device that has fixed DevAddr, NwkSKey and AppSKey?](https://www.thethingsnetwork.org/forum/t/can-i-register-an-abp-device-that-has-fixed-devaddr-nwkskey-and-appskey/3831/17): > > @htdvisser wrote in Slack […]: > > > […] > > > > But uplink for anything else than `00` / `01` / `26` / `27` will just be dropped before it’s even considered by the backend Also, no downlink also implies no ADR. And this is bogus: > [@mfalkvidd](#): > > The vendor also claims the following: > > - the dev addr is optional when using ABP And, yes: > [@mfalkvidd](#): > > Could it be that Blink Services and Loriot route all messages, regardless of dev addr prefix Of course, but they should not? > [@mfalkvidd](#): > > We have now gotten information from the vendor that the devices use ABP. Bummer. For ABP, TTN’s answer is clear; see [Can I register an ABP device that has fixed DevAddr, NwkSKey and AppSKey?](https://www.thethingsnetwork.org/forum/t/can-i-register-an-abp-device-that-has-fixed-devaddr-nwkskey-and-appskey/3831) Also beware that the [backend network stack version V3](https://www.thethingsnetwork.org/forum/t/the-things-network-stack-v3-webinar-by-johan-stokking/12031) is due, so don’t rely on hacks that work in the current V2… ---
**Author:** ![mfalkvidd](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/mfalkvidd/32/46878_2.png) [@mfalkvidd](https://www.thethingsnetwork.org/forum/u/mfalkvidd)\ **Post date:** [October 8, 2018, 1:31pm UTC](https://www.thethingsnetwork.org/forum/t/moving-a-device-from-loriot-to-ttn/17295/7 "2018-10-08T13:31:40Z")
We’ve tried nestorayuso’s suggestion. There were no error messages during the process, and the DevAddr is now the address starting in 0x14: > ``` > ttnctl-windows-386.exe devices set 140024be --dev-addr 140024BE --override > INFO Using Application AppEUI=70B3D57ED0011CB1 AppID=export_data_watermeter_lora > INFO Discovering Handler... Handler=ttn-handler-eu > INFO Connecting with Handler... Handler=eu.thethings.network:1904 > WARN Manually changing the DevAddr of a device might break routing for this device > INFO Updated device AppID=export_data_watermeter_lora DevID=140024be > ttnctl-windows-386.exe devices info 140024be > INFO Using Application AppEUI=70B3D57ED0011CB1 AppID=export_data_watermeter_lora > INFO Discovering Handler... Handler=ttn-handler-eu > INFO Connecting with Handler... Handler=eu.thethings.network:1904 > INFO Found device > Application ID: export_data_watermeter_lora > Device ID: 140024be > Description: 00115261 > Last Seen: never > LoRaWAN Info: > AppEUI: 70B3D57ED0011CB1 > DevEUI: 33530118126701B7 > DevAddr: 140024BE > AppKey: <nil> > AppSKey: 6897E9...1418275 > NwkSKey: 78D8DB...858C031 > FCntUp: 0 > FCntDown: 0 > Options: FCntCheckEnabled, 32BitFCnt > > ``` However, messages are still not routed to out TTN application so it seems this workaround didn’t work. Thanks anyway for the suggestion. ---
**Author:** ![arjanvanb](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/arjanvanb/32/46626_2.png) [@arjanvanb](https://www.thethingsnetwork.org/forum/u/arjanvanb)\ **Post date:** [October 8, 2018, 3:23pm UTC](https://www.thethingsnetwork.org/forum/t/moving-a-device-from-loriot-to-ttn/17295/8 "2018-10-08T15:23:50Z")
As you wrote your client has deployed a TTN Gateway, you should be able to see some debugging information in TTN Console. Like: > router ttn-router-eu **drop** _reason_: no brokers ![image](https://www.thethingsnetwork.org/forum/uploads/default/original/3X/0/f/0f03fc543ac8cebe219acfe53e99e02ac887da22.png) ---
**Author:** ![mfalkvidd](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/mfalkvidd/32/46878_2.png) [@mfalkvidd](https://www.thethingsnetwork.org/forum/u/mfalkvidd)\ **Post date:** [October 19, 2018, 3:11pm UTC](https://www.thethingsnetwork.org/forum/t/moving-a-device-from-loriot-to-ttn/17295/9 "2018-10-19T15:11:42Z")
Yes, no brokers is what we’re getting. ![image](https://www.thethingsnetwork.org/forum/uploads/default/original/3X/9/4/943cd4469b21a1f765b4985766f0a22f0961e70b.png) ---
**Author:** ![mfalkvidd](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/mfalkvidd/32/46878_2.png) [@mfalkvidd](https://www.thethingsnetwork.org/forum/u/mfalkvidd)\ **Post date:** [October 22, 2018, 2:50pm UTC](https://www.thethingsnetwork.org/forum/t/moving-a-device-from-loriot-to-ttn/17295/10 "2018-10-22T14:50:41Z")
We’ve verified that we’re getting “no brokers” also with a different gateway and two different devices. ![ambiductor%2000115258](https://www.thethingsnetwork.org/forum/uploads/default/original/3X/0/6/063c95e5e07140fa34e40dbb461b20de58d5f0b8.png) ![ambiductor%2000115259](https://www.thethingsnetwork.org/forum/uploads/default/original/3X/5/b/5b0c022c70babe4ec28c208092967624cc1ecd0a.png) Is there a way to further troubleshoot “no brokers”? Does it simply mean the device address is out of TTN’s address range? ---
**Author:** ![htdvisser](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/htdvisser/32/45312_2.png) [@htdvisser](https://www.thethingsnetwork.org/forum/u/htdvisser)\ **Post date:** [October 22, 2018, 3:37pm UTC](https://www.thethingsnetwork.org/forum/t/moving-a-device-from-loriot-to-ttn/17295/11 "2018-10-22T15:37:07Z")
> [@mfalkvidd](#): > > Is there a way to further troubleshoot “no brokers”? Does it simply mean the device address is out of TTN’s address range? As the Console also shows, the DevAddr of that message belongs to the KPN network. The “no brokers” message means that the DevAddr is from a range that isn’t currently assigned to any TTN cluster. We only route addresses from TTN-assigned sub-ranges starting with `26` or `27` and the “testing” ranges starting with `00`, `01`, `02` or `03`. Also note that DevAddrs must be assigned by the network server. The only way application developers can assign DevAddrs of their choice, is to use the testing range. This is however not recommended, and the usual advice is: use OTAA.