Using a device's own DevEUI

Hi all,

Since OTAA became an option I’ve started to look at the Things Connected dashboard.

I went to add some devices but discovered that the DevEUI can’t be entered and must taken from Things Connected. To set this on the end device seems impractical based on my limited experience of devices.

Most of my devices aren’t user-configurable (Elsys ELT-1, Multitech mdot, Multitech mdot box). I ended up with some firmware which allows me to re-write the DevEUI on the Multitech mdot but this firmware is only available via a support ticket.

Any ideas why the DevEUI is enforced? Each DevEUI is already unique to the manufacturer, so are you using reserved address space or is it from the locally administered EUI range?


Hey Ben,

there was a small issue that prevented you from entering your own DevEUI for OTAA but you should be able to enter it again.
We just give you one in case you don’t have one yet.

However you can just enter it on device creation so you might have to delete your existing device and create a new one.
When you create a new one you’ll be offered the chance to ‘edit the defaults’ which include the DevEUI if you choose OTAA as activation type.

Let me know if there are still any problems.

Hi Benjamin,

Thanks for getting back to me quickly.

I’ve gone through the process again, setting up a new device and using the defaults. When I went to edit them I wasn’t able to. So, instead I copied the appEUI of the Sandbox (is this my unique sandbox appEUI?) and the appKey of the sandbox, then created a new device using my physical devEUI and the appKey from above.

The appKey should be unique for each device (see LoRaWAN spec section 6.2.2 Application key (AppKey)) but I’m having to do this myself by incrementing the key (not a secure method ;-)). When using The Things Network I create an app which generates the appEUI. Then within that app per-device I add the devEUI. TTN uses the appEUI and my devEUI to generate a unique appKey for that device. This key can be regenerated.

So I’d like Things Connected to let me enter my devEUI but calculate the device’s appKey from the sandbox appEUI, rather than manually entering both. Is this possible?



I’m not sure I follow which appKey you are copying from the sandbox?
Would you mind taking a screenshot from what you specifically you copy?

You can however create a device and enter your devEUI, just leave the appKey field empty and it will still generate it for you. You just need to enter it manually if you need to use a specific appKey.

Hope that makes sense!

Is there any resolution to entering your own DevEUI in ABP mode.
AllThingsTalk maker only accepts devices in ABP mode, so anything with its own DevEUI won’t work with it.



Hi there,
I added a device using ABP last week - I was able to click edit on the credentials when I was adding the device and type in the necessary IDs.
So I think it will work for you - please can you try, and let me know how you get on? We may need to go through the problem together.
Cheers, Mark

When creating a device with OTAA you can enter:
Application key
Device EUI

When you create a device with ABP you can enter:
Network session key
Application session key
Device addr

but not Device EUI, that is the missing parameter i’m after.

Thanks ,

Hi Steve,
I can put in a change request to get the form updated to include Device EUI on an ABP device, but please can you explain to me why it is necessary? I can’t figure it out from this thread.

In the meantime if you want to email me the details of your device and app I can try to add it manually through the backend.

Cheers, Mark (

Hi Mark,
It comes down to the first message on this thread from Ben, in which most devices are already configured with their unique DevEUI (DeviceEUI) and are not configurable.
When you create a device in ABP you can change
Network session key
Application session key
Device addr
but when it is created it forces you to use a ThingsConnected generated DeviceEUI.

I think (may be totally wrong here) that DevEUI was configurable in ABP mode initially, but got taken out (perhaps by mistake) when it was added to OTAA mode.