# Should off-the-shelf devices use a unique AppEUI/JoinEUI for each device? **URL:** \ **Category:** End Devices (Nodes)\ **Created:** [September 8, 2020, 11:05am UTC](https://www.thethingsnetwork.org/forum/t/should-off-the-shelf-devices-use-a-unique-appeui-joineui-for-each-device/39755 "2020-09-08T11:05:47Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![arjanvanb](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/arjanvanb/32/46626_2.png) [@arjanvanb](https://www.thethingsnetwork.org/forum/u/arjanvanb)\ **Post date:** [September 8, 2020, 11:05am UTC](https://www.thethingsnetwork.org/forum/t/should-off-the-shelf-devices-use-a-unique-appeui-joineui-for-each-device/39755/1 "2020-09-08T11:05:48Z")
So far, I very much felt that off-the-shelf 1.0.x devices should have a unique AppEUI (and DevEUI) for each device. Quoting myself: > [@Dragino LHT65 and network coverage](https://www.thethingsnetwork.org/forum/t/dragino-lht65-and-network-coverage/31434/12): > > From [the LoRaWAN specifications](https://lora-alliance.org/sites/default/files/2018-05/lorawan1_0_2-20161012_1398_1.pdf#page=32): > > > **6.1.2 Application identifier (AppEUI)** > > > > The AppEUI is a global application ID in IEEE EUI64 address space that uniquely identifies the entity able to process the JoinReq frame. > > By definition, an EUI-64 address should be unique. In this case: unique per application, but [the manufacturer] should not expect customers to share an application, so **each off-the-shelf device should have its own unique AppEUI** (and DevEUI). In real life, at least on TTN things seem to work if a non-unique AppEUI is shared among multiple devices, registered by different users. (Also a single TTN user can use the same AppEUI in multiple applications in TTN Console, at least in V2.) Again quoting myself, while I was quoting myself: šŸ˜Š > [@Dragino LHT65 and network coverage](https://www.thethingsnetwork.org/forum/t/dragino-lht65-and-network-coverage/31434/12): > > Iā€™m a bit surprised that multiple users can apparently add the same non-unique AppEUI to TTN Console, but it seems TTN only uses _the combination_ of AppEUI and DevEUI: > > > [@Registration of node with pre-configured LoRaWAN keys](https://www.thethingsnetwork.org/forum/t/registration-of-node-with-pre-configured-lorawan-keys/8716/7): > > > > Hylke 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) > > > > > > Things might be different for other networks, so Iā€™d just make sure the AppEUI and DevEUI are unique (and comply to the rules of an EUI-64, so are either purchased or [crafted using specific rules](https://www.thethingsnetwork.org/forum/t/deveui-for-non-hardware-assigned-values/2093/23)). So it seems at least TTN V2 can handle sharing an AppEUI (though [someone reported](https://www.thethingsnetwork.org/forum/t/dragino-lht65-and-network-coverage/31434/10) that programming a new, unique AppEUI fixed their problems). And weā€™ve seen quite a few devices use a single or non-registered AppEUI. (Like Dragino [LHT65](https://www.thethingsnetwork.org/forum/t/dragino-lht65-and-network-coverage/31434/11) and [LGT92](https://www.thethingsnetwork.org/forum/t/lgt-92-is-not-working-as-supposed-and-all-devices-use-identical-app-eui-a000000000000102/35309), [RadioBridge](https://www.thethingsnetwork.org/forum/t/noob-issue-connecting-radiobridge-sensors-to-ttn/36050/9), [Nke Watteco](https://www.thethingsnetwork.org/forum/t/join-requests-receive-but-not-accept/34402/4), [Axioma Qalcosonic](https://www.thethingsnetwork.org/forum/t/noob-setting-up-heat-monitor-device-all-preconfigured/38554/12), ā€¦?) But if things work, then why did the LoRaWAN specifications even bother about defining the AppEUI? Surely the network servers could have used just the DevEUI and MIC to find the right configuration. This makes me feel that things work because of implementation choices, despite the devices not being compliant. Any thoughts, opinions? ---
**Author:** ![PhilippRe](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/philippre/32/35697_2.png) [@PhilippRe](https://www.thethingsnetwork.org/forum/u/PhilippRe)\ **Post date:** [September 22, 2020, 7:17am UTC](https://www.thethingsnetwork.org/forum/t/should-off-the-shelf-devices-use-a-unique-appeui-joineui-for-each-device/39755/2 "2020-09-22T07:17:58Z")
Hi, thats a thought I stumbled upon when recently purchasing 10 Elsys CO2 sensors. They all have the same AppEUI 0000000000000000. In LoRaWAN 1.1, I totally understand the use of AppEUI (renamed to JoinEUI): It identifies the Join Server keeping the root keys for this device. In LoRaWAN 1.0.x however, I do not really get the initial usage for AppEUI as there is no Join Server yet. It also is not used in key generation: ![lorakeycalc](https://www.thethingsnetwork.org/forum/uploads/default/original/3X/4/5/45de657305e2a396ba3eecdf2fc4e701c68b2586.png) So, from my current knowlegde (which might change), I see no reason why non-unique AppEUIs should be a problem. However, it feels somehow wrong to me to register 10 devices with the same AppEUI šŸ™‚ Best regards ---
**Author:** ![bluejedi](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/bluejedi/32/44639_2.png) [@bluejedi](https://www.thethingsnetwork.org/forum/u/bluejedi)\ **Post date:** [September 22, 2020, 9:44pm UTC](https://www.thethingsnetwork.org/forum/t/should-off-the-shelf-devices-use-a-unique-appeui-joineui-for-each-device/39755/3 "2020-09-22T21:44:35Z")
Short answer to topic title: NO Below the longer version: > [@Dragino LHT65 and network coverage](https://www.thethingsnetwork.org/forum/t/dragino-lht65-and-network-coverage/31434/12): > > From [the LoRaWAN specifications](https://lora-alliance.org/sites/default/files/2018-05/lorawan1_0_2-20161012_1398_1.pdf#page=32): > > > **6.1.2 Application identifier (AppEUI)** > > > > The AppEUI is a global application ID in IEEE EUI64 address space that uniquely identifies the entity able to process the JoinReq frame. > > By definition, an EUI-64 address should be unique. In this case: unique per application, but [the manufacturer] should not expect customers to share an application, so **each off-the-shelf device should have its own unique AppEUI** (and DevEUI). The specification says ā€œAppEUI is a global application ID in IEEE EUI64 address space that uniquely identifies the _ **entity** _ able to process the JoinReq frameā€. You write ā€œIn this case: _unique per **application** _ā€ which is an understandable but incorrect assumption. The specification explicitly says _the entity able to process the JoinReq frame_ and not _application_. The specification also says ā€œ_the_ entityā€ and this is where I think the specification is not precise enough because (based on current implementation) this probably should read ā€œ_an_ entityā€.In which case multiple applications can serve as an ā€˜the entity able to process the JoinReq frameā€™. Off-the-shelf devices must be able to be used right out of the box without having a user to configure any keys on the device first. To make this possible they must be pre-configured with DeviceEUI, AppKey and AppEUI (all three of them). DeviceEUI and AppKey are end device specific (properties of the end device). AppEUI is a property of _an_ entity/application that can handle the join request for this device, but only if the end device is registered for that application and an end device can only be registered to a single application. From the perspective that a(n off-the-shelf) device must be _able_ to be registered to _ **any** _ application (but only one at a time) it makes sense that any application can be enabled to handle a join request of that device by adding the AppEUI (configured in the device) to that application. The device must be registered for an application to be able to join, but technically this does not require the AppEUI to be unique for that application and hence an AppEUI can be shared by different applications (possibly even by applications from different accounts). Giving each device their own unique AppEUI as some suggest would not be useful and not be logical. The device is already uniquely identified by its DevEUI. The devices of an application _can_ all share the same AppEUI (unless they come hard/pre-configured with different AppEUIā€™s). This is exactly the same as when an application only has a single (its default) AppEUI which is then automatically used during device registration (when the user does not explicitly enter an AppEUI) and the user then configures that AppEUI on the end device(s). > [@arjanvanb](#): > > But if things work, then why did the LoRaWAN specifications even bother about defining the AppEUI? Surely the network servers could have used just the DevEUI and MIC to find the right configuration. Why do you mention MIC here? Did you mean DevEUI and _AppKey_ instead? In which case only DevEUI and AppKey would have to be specified when registering a device, without needing to bind it to an AppEUI (that must have been added to the application in advance)? ā€œwhy did the LoRaWAN specifications even bother about defining the AppEUI?ā€ Maybe @johan knows the answer to this? Possibly with future extensions in mind (e.g. Join Server like)? Or maybe speedup the handling of join requests? Can it be related to that NetworkSKey and AppSkey are not yet known during the join request? > [@Registration of node with pre-configured LoRaWAN keys](https://www.thethingsnetwork.org/forum/t/registration-of-node-with-pre-configured-lorawan-keys/8716/7): > > @htdvisser [Jan 11th 2019 4:24 PM] > > > We use the AppEUI+DevEUI combination as identifier for a device The application name appears to be the primary key of applications. This explains why two different user accounts cannot use identical application names. It also explains why applications can share AppEUIā€™s, because it is not their primary key. The name AppEUI which is usually referred to as ā€˜Application IDā€™ gives a wrong impression and puts us on the wrong foot because AppEUI is **not** the unique primary key of an application. This is probably (one of) the reason(s) why it was renamed to JoinEUI in later versions of the spec. _(In database design itā€™s bad practice to use name as primary key. This is probably a V2 design flaw)._ ---
**Author:** ![arjanvanb](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/arjanvanb/32/46626_2.png) [@arjanvanb](https://www.thethingsnetwork.org/forum/u/arjanvanb)\ **Post date:** [September 22, 2020, 11:45pm UTC](https://www.thethingsnetwork.org/forum/t/should-off-the-shelf-devices-use-a-unique-appeui-joineui-for-each-device/39755/4 "2020-09-22T23:45:53Z")
Sorry, Iā€™m not convinced. šŸ™‚ Sure, we already established it seems a unique AppEUI is not needed with TTN, at least not with V2. But: that may be considered an implementation detail? Do things still work when registering a 1.0.x device on V3? Or when using another network? Or when networks start peering? (Aside: just peeking in the code, it seems things also work when running oneā€™s own handler in V2. In that case TTN does not know the deviceā€™s AppKey, but TTN simply [delegates an OTAA Join Request to all handlers](https://github.com/TheThingsNetwork/ttn/blob/v2.11.0/core/broker/activation.go#L139). It also seems devices should then still be registered with TTN itself, as TTN [seems to expect to find it using the AppEUI and DevEUI](https://github.com/TheThingsNetwork/ttn/blob/v2.11.0/core/networkserver/activation.go#L47). At that point it seems it even already knows the TTN App ID, and as [handlers announce the App IDs they know](https://discovery.thethingsnetwork.org/announcements/handler), TTN may only need to delegate to a few handlers. Iā€™ve not truly investigated, but that looks solid and Iā€™d assume it works. For TTN V2.) > [@bluejedi](#): > > Why do you mention MIC here? Did you mean DevEUI and _AppKey_ instead? The AppKey is not in an OTAA Join Request. But indeed, the AppKey is used to validate the MIC of an OTAA Join Request, so theyā€™re interchangeable in this context. > [@PhilippRe](#): > > They all have the same AppEUI 0000000000000000. Aside: this AppEUI has not even been registered by Elsys. It almost looks like they forgot to provision the devicesā€¦ ---
**Author:** ![james\_L](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/james_l/32/35697_2.png) [@james\_L](https://www.thethingsnetwork.org/forum/u/james_L)\ **Post date:** [October 1, 2020, 5:25am UTC](https://www.thethingsnetwork.org/forum/t/should-off-the-shelf-devices-use-a-unique-appeui-joineui-for-each-device/39755/5 "2020-10-01T05:25:27Z")
Here is some relevant info: > **[LoRa best practices Provisioning for Maximum Compatibility Join EUI |...](https://lora-developers.semtech.com/documentation/tech-papers-and-guides/the-book/joineui)** > > Provisioning for Maximum Compatibility Join EUI > When you introduce a new JoinEUI, use the manufacturerā€™s OUI for the first bytes of the JoinEUI. Consider separate JoinEUIs per frequency band or per brand. There is no problem having multiple JoinEUIs point to the same join server. Do not create a unique JoinEUI per device and do not use a random sequence. If an OUI is not available, use all zeros to indicate that a join server is not available. The intention is to consolidate devices. ---
**Author:** ![arjanvanb](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/arjanvanb/32/46626_2.png) [@arjanvanb](https://www.thethingsnetwork.org/forum/u/arjanvanb)\ **Post date:** [October 1, 2020, 12:50pm UTC](https://www.thethingsnetwork.org/forum/t/should-off-the-shelf-devices-use-a-unique-appeui-joineui-for-each-device/39755/6 "2020-10-01T12:50:27Z")
Too bad I cannot find any mention of off-the-shelf devices anywhere in the developer portals. I wonder if the above applies to such devices, considering the [LoRaWAN Backend Interfaces 1.0 Specification](https://lora-alliance.org/sites/default/files/2018-04/lorawantm-backend-interfaces-v1.0.pdf#page=9), emphasis mine: > Join Server: > > The Join Server (JS) manages the Over-the-Air (OTA) End-Device activation process. **There may be several JSs connected to a NS** , and a JS may connect to several NSs. > > **The End-Device signals which JS should be interrogated through the JoinEUI field of the Join-request message.** Each JS is identified by a unique JoinEUI value. Note that AppEUI field of the Join-request in LoRaWAN 1.0/1.0.2 [LW10, LW102] is renamed to JoinEUI field in LoRaWAN 1.1 [LW11]. The term JoinEUI is used to refer to the AppEUI in the context of LoRaWAN 1.0/1.0.2 End-Devices in this specification.