How can I reuse hardcoded AppEUI and AppKey after I deleted an application?

I try ADEUNIS RF node to get the TTN network, but so far this does not succeed.
I want to create a test setup.

When purchasing I got the DEVEUI, AppEUI and AppKEY

All codes have filled in, but received no activation of the device.
I live 2 km from a gateway.
I have also tried to put the node closer.
I deleted the application;
If I want to re-create the application, I can not use the same codes.
There is a report that is already in use, while I remove the application.

How can I solve this

Could you send me your AppID, DevID, AppEUI and DevEUI in a private message, then I might be able to help you out.

@htdvisser, two years later, but this seems to be the proper topic to tell people how to proceed if things have changed:

  • Can one delete an application that still has devices registered to it?

  • If yes: would not deleting the devices before deleting an application orphan those devices, or would they be unregistered on the fly?

  • Would re-using the same AppEUI, AppKey and DevEUI work when an earlier device registration with the same details once existed?

I know you once wrote on Slack:

@htdvisser [Jan 11th 2019 4:24 PM]

We use the AppEUI+DevEUI combination as identifier for a device, so as long as you use different AppEUIs for devices with the same DevEUI, you should be fine for now (but you may encounter problems in v3 if you would use LoRaWAN 1.1 ReJoinRequests)

Also, when not deleting an application, one cannot register the same AppEUI and DevEUI twice:

error message

failed to register device
Device with AppEUI and DevEUI already exists

Deleting an application that still has devices registered to it, does not mention those devices in its confirmation message, but I’ve not tried to see what happens when proceeding:


Finally, on GitHub I see about ttnctl, emphasis mine:

ama9910 commented on 21 Aug 2017

The issue I observed is that when deleting an application with ttnctl, the devices remained active. There is now no way to delete those devices using ttnctl, without first selecting the now deleted application - which can’t be done.

johanstokking commented on 21 Aug 2017

Yes, these are two separate things. We will take unarchiving into account for the next version of the account server. When an application is deleted, it should be unregistered from the handler, which invokes deleting devices.

1 Like

Devices need to be deleted in order to release their IDs/EUIs for future registrations. Due to the way our registries work, deleting an application does not implicitly delete devices under that application, so users need to delete their devices explicitly before deleting an application. The v2 console tries to delete devices, but there are not guarantees that this succeeds. The v2 CLI (ttnctl) does not try to delete devices.

The reason for all this is that in our v2 backend, applications are registered in the account server while end devices are registered in the networkserver (through the broker) and in the handler. The account server doesn’t know anything about end devices, so it also can’t check if a user deleted all their end devices before deleting the application. The networkserver and handler don’t know anything about applications other than the fact that a user is authorized to manage end devices with a certain application ID and read their traffic. As a result of this, the only effect of deleting an application is that a user is no longer authorized to manage those end devices or read their traffic. The end devices will not disappear, and the routing services will keep handling traffic for those devices

In our v3 stack, the situation is very similar to v2. Users (or clients like the CLI or console) will still be responsible for deleting registered devices before deleting an application. We will however be better able to detect if there are still devices registered, and refuse to delete the application if we do.

For v3 we are also thinking about some kind of mechanism for releasing identifiers of orphaned end devices or end devices that have exceeded their lifetime, but we don’t have anything concrete for this yet.