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:
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.
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.
@htdvisser almost two years after I bump the topic again. As far as I understand (still a rookie though) v3 is out by now. I dont find a solution for revitalizing orphaned devices? My situation is that I have a Things Gateway, someone tried to set up some time ago. Since this happened in a school, its hardly possible to find that person. Is there any chance I can liberate the device?
The community network still runs V2 and will stay on V2 for months to come.
My bad, I saw v3 published on Github. So I understand there is no chance to get the device back and I have to throw it away?
For a node the old application must be deleted to be able to reuse the existing values. I understand you can’t program new EUI and key?
Oh - I realized I might post in the wrong topic. I actually tried to register The Things Gateway as Gateway. I am ending with the error a gateway with id XXXXXXX already exists. So there is no application, but the error message stays the same?
For The Things Gateway you can choose your own ‘name’ while registering so you shouldn’t have any issues with old registrations.
My bad, I entered the code on the RF-Module into the id field. Now I chose a different ID and it works. Thank you!
