Hello.
I have an application where i importet a few devices a few weeks ago. Now I wanted to rename them all, but when i try to acces them i get this:
I cant delete them because i cant access them, also i cant replace them/import them again because they already exist.
Can anyone help me?
Thanks in advance
Moved your post to the thread that was at the top of the list so we don’t have two of the same.
The forum is entirely run by volunteers so we ask people to use the forum search to see if something has been answered already - or multiple times.
In this case, something, somehow, has got in to the database that the web front end can’t cope with. The simplest solution, given there is no SLA or support for the free service, is to use the CLI tool to delete the devices and re-enter them from either the CLI (preferable) or via the web console which works 99% of the time for me, but just occasionally I manage to confuse the browser enough that I break it all. That said, the CLI is more of an atomic commit to the database, so if I’m doing a fair number of devices I use that.
Sometimes editing a setting can cause this issue.
If I get any form of detail (both EUIs) that can help the TTI developers trace such situations I do pass it on.
I have been using the CLI with command ttn-lw-cli end-devices create to make new devices with the TTN V3 stack, and it is generally working well. However, the devices I create show in the “End devices” list in the Console, but when I try to click on the devices created through the CLI, I get the error An unknown error occurred. Please try again later. If the error persists, please contact support.
Have anyone else encountered this? Are there some properties on the device I need to set for it to display properly in the console? I have tried with the --lorawan-version flag, and had problems with the --frequency-plan-id if with for US_902_928_FSB_2.
As above, having merged your topic in to the current thread, if you could share details - the CLI command would be critical to checking this - we can make progress.
The Dev & Join EUI’s are of public record in gateway logs, so NO NEED to redact anything unless your app & device ids are rude or contain privileged information.
I’m particularly interested in the options that you, @rbney or @claudiormrosa are using.
And as we have a collection, I’ll start warming up the TTI team with a shout out to @kschiffer
The exact command I am running (for example) is this: ttn-lw-cli end-devices create ensemble-dev-nam 935-test-id --request-dev-eui --lorawan-version "1.0.3"
Gives me the output:
INFO JoinEUI empty but defaults flag is set, fetch default JoinEUI of the Join Server {"join_server_address": "nam1.cloud.thethings.network:8884"}
INFO Successfully obtained Join Server's default JoinEUI {"default_join_eui": "0000000000000000"}
INFO Successfully obtained DevEUI {"dev_eui": "70B3D57ED00531F1"}
{
"ids": {
"device_id": "935-test-id",
"application_ids": {
"application_id": "test-dev-nam"
},
"dev_eui": "70B3D57ED00531F1",
"join_eui": "0000000000000000"
},
"created_at": "2022-07-12T15:54:40.611Z",
"updated_at": "2022-07-12T15:54:41.173972986Z",
"attributes": {},
"network_server_address": "nam1.cloud.thethings.network",
"application_server_address": "nam1.cloud.thethings.network",
"join_server_address": "nam1.cloud.thethings.network",
"lorawan_version": "MAC_V1_0_3",
"supports_join": true
}
You’ll need to tell it what frequency band you want it to use and what regional parameters.
Because it’s not specified, using the power of Google Protocol Buffers, the entry for the band is null which isn’t something the web console can use to look up its name. So it falls over.
PS, I’d be wary of using all zeros for the App/JoinEUI - it works on some things and sometimes not at all, just keep that in the back of your mind whilst debugging!
Excellent, it works now! Seems that --frequency-plan-id and --lorawan-phy-version both must be specified at the same time for the command to complete if any of them are used. For others with the same issue, this command worked for me in the end: