Unable change wrong dev-eui / join-eui in TTN V3

TTN V2 to V3 Upgrade V3 Devices
1

Created manually a new device in TTS V3 Community Edition. I made a mistake at the dev-eui. Now I can’t find a way to correct the wrong dev-eui! This was possible in TTN V2! What am I doing wrong? Deleting the device also makes no sense, since in contrast to TTN V2 the dev-id will then no longer be used again in V3! Somehow I feel like the V3 is a big step backwards …

2

It can be changed via the CLI but not via the console.

This would reflect the move to a more secure, professional environment - if the Device ID is important to your database of devices, then a more formal process of registering that precludes EUI data entry errors would be indicated.

If it’s a maker device, deleting and finding a new Device ID shouldn’t be a bother.

3

Thanks for the quick answer and important information - I was afraid of something like that!
Where can I find a good description for commissioning and using the CLI?

I have a clear systematic structure for the dev-id. Therefore, when replacing a defective sensor, the new sensor should have the same dev-id. In addition, even the most experienced user can make input errors. In my case, losing the dev-id would be catastrophic and I really want to avoid it.

According to TTS V 3.12 it is possible to reuse deleted dev-id → ID and EUI Constraints | The Things Stack for LoRaWAN → " * When an end device is deleted, the ID and EUI are released and can be reused"
This is in contradiction to the warning message when pressing the delete button on the web interface. What is correct now?

Thanks for your help

4

The documentation is always a good place!

https://www.thethingsindustries.com/docs/getting-started/cli/
https://www.thethingsindustries.com/docs/reference/cli/

However in this instance, it’s fairly turgid stuff so I find this helps:

http://descartes.co.uk/TTSv3CLI.html

I’m not staff, so the very best way to find out is try with some dummy data. Do let us know the result and if there is a discrepancy, post an issue on GitHub

5

Now I installed the CLI and it connects perfect!
My attempts to change the dev-eui via CLI fail because I obviously do not specify the HEX string to be transferred correctly. Unfortunately I couldn’t find any examples in the documentation or other sources to solve my problem.

I entered the following line in the bash shell:

ttn-lw-cli end-devices set my-app-id my-dev-id --dev-eui “A8404104D181A749”
error message → flag needs an argument: --dev-eui

ttn-lw-cli end-devices set my-app-id my-dev-id --dev-eui “A8 40 41 04 D1 81 A7 49”
error message → encoding/hex: invalid byte: U+0020 ’ ’

What am I doing wrong??

6

That’s a space

Of the combinations left, I’d try the first but without the " marks

7

Sorry, but this was also my first idea - no success :-(((

ttn-lw-cli end-devices set my-app-id my-dev-id --dev-eui A8404104D181A749
error message → No fields selected, won’t update anything

8

I’ll have a look at the source shortly

9

thank’s a lot!

10

I have a rough idea why the CLI help says it can set EUI’s but the code doesn’t allow for it:

// EUIs can not be updated, so we only accept EUI flags if they are equal to the existing ones.
if device.JoinEUI != nil {
	if existingDevice.JoinEUI != nil && *device.JoinEUI != *existingDevice.JoinEUI {
		return errEndDeviceEUIUpdate
	}
} else {
	device.JoinEUI = existingDevice.JoinEUI
}
if device.DevEUI != nil {
	if existingDevice.DevEUI != nil && *device.DevEUI != *existingDevice.DevEUI {
		return errEndDeviceEUIUpdate
	}
} else {
	device.DevEUI = existingDevice.DevEUI
}

From lorawan-stack/end_devices.go at c26671e1eb844ad207702fc5b9fb3535b7cdc3a7 · TheThingsNetwork/lorawan-stack · GitHub

So that’s not going to work.

Have you tried checking the documentation’s idea - create a dummy device, delete it and then see if you can re-create it? The primary reason for stopping some IDs being reused as they are the key in to the database and someone reusing one could access data from another users data for a deleted entity. Devices can only be referred to via an Application ID which is why it is potentially feasible to delete & recreate.

11

Thanks for the great effort in analyzing the problem and finding a solution! In the meantime I have deleted a test device and created it again. That worked with the new dev-eui value! However, based on previous experience with other restrictions in V3 compared to V2, I am not sure, whether this test is reliable.
Can you please suggest to the V3 developers whether at least the V2 functions will not be made available again? I cannot see the additional security provided by the change restrictions on the devices.
Let’s see how the user community gives feedback in the course of the switch to the new conditions of the V3. I’m curious…

In any case, thanks again for your help in the middle of the night !!!

12

No, I do enough suggesting of the other issues and I am no more than you in terms of usability issues, so you can suggest on the GitHub repro.

My tests show that you can add, delete & remove the device & still recycle the id & EUI as I suggested before we went off on the CLI tangent and as I said when I looked at the code, I understand the why’s & wherefore’s of the restrictions on gateway & application ids based on the API calls, so at present, I’m happy this is OK.

13

You are absolutely right and thank you again!
Should another question arise with V3, I would be grateful, if you would again support me with your specialist knowledge.

14

I have a rough idea why the CLI help says it can set EUI’s but the code doesn’t allow for it:

Is it the same for --join-eui? Because my attempt:
ttn-lw-cli devices set vodomery 450-xx-sv --join-eui 0000000000000709
ends with: WARN No fields selected, won’t update anything