OTAA and DevEUI confusion

Hello,
I am just starting and informing myself about TTN and waiting for the first devices (TTGO T-Beam) to arrive.
I‘m a little bit confused about OTAA activation regarding the DevEUI. In the Device Registration and Quick Start Tutorial you have to retrieve the DevEUI from the Device which seems to be straightforward. Since I will use a ESP32 Device I searched for Hello-World sketches to start. I found manuel’s ttn-esp32 library as a good start. In the Get-Started guide you have to let TTN generate a DevEUI for you.
So my question: Do you have to get you DevEUI from the device or can you just generate one for OTAA. If you can do both, what is the method to go with and why?

Are there other good esp32 libraries for starters? Just Hello-World stuff.

Thanks!

Many of the hobby ESP modules don’t come with a device EUI so you’ll have to let TTN generate one for you.

In theory you can create your own at the risk of it clashing with someone else’s. Or you can buy a block of official EUI’s. I suspect letting TTN solve the problem for you is the best.

1 Like

But the best way is to look if there is a DevEUI and use that? Does the T-Beam come with one? I saw that MAC-Addresses are used for the DevEUI or even IS the MAC the DevEUI? As it is unique, too.

A MAC Address is too short to be an EUI-64 DevEUI. Earlier, there was an officially IEEE supported way to increase their length, but that has been deprecated as it clashed with official EUI-64 assignments. But still then: doing so is unlikely to cause conflicts within their usage in a specific network…

See also DevEUI for non-hardware assigned values. And just for the sake of completeness, but also unlikely to create problems: Generated Device EUI clashes with officially assigned EUIs.

Ok, just to make it clear: Best way is to use the DevEUI which already is on the device (when it’s assigned) or second way let TTN generate one for you? Do I have disadvantages when I set a new DevEUI for a device which already got a DevEUI from the manufacturer?

I think I already answered this, but just to make it clear:

Yes

If you don’t have one on the device, then let TTN make one for you

Why would you do this anyway - at the least, you run the risk of confusing yourself, you have a device with an EUI on it but you get a computer on the internet to generate a different one, making it harder on yourself to debug things …

Sorry for maybe asking too much, but as a beginner it is not that straightforward.
The reason why you maybe would do this is when you do not exactly know how to retrieve the DevEUI from the device.

I would try to go with Manuel’s Provision Example and try to find the DevEUI.

When I would just go with the Hello-World example with generating a DevEUI like mentioned in the linked tutorial, would I overwrite the manufacturer‘s DevEUI?

But your device doesn’t have a DevEUI, there is a script that makes one up from the WiFi MAC address which, as noted above, has complications. The provisioning script is for saving a DevEUI in flash, so you don’t have to put it in to your source code.

If you just take the generated DevEUI from TTN, you will have a working node and will have some success to celebrate. After that you can look at the provisioning script.

The key with learning complicated things is Baby Steps - get your node working first, then add on to it.

Thanks for the help! Now it is more clear. I will go with generating the EUI by TTN first.

Then for future projects I will try to generate it from the MAC address.
I’ve found two ways to do this in a Paxcounter tutorial.
I see the version which is mentioned deprecated above, where you add FFFE in the middle of the MAC to get an EUI-64.

// DevEUI generator using devices's MAC address
void gen_lora_deveui(uint8_t *pdeveui) {
  uint8_t *p = pdeveui, dmac[6];
  ESP_ERROR_CHECK(esp_efuse_mac_get_default(dmac));
  // deveui is LSB, we reverse it so TTN DEVEUI display
  // will remain the same as MAC address
  // MAC is 6 bytes, devEUI 8, set middle 2 ones
  // to an arbitrary value
  *p++ = dmac[5];
  *p++ = dmac[4];
  *p++ = dmac[3];
  *p++ = 0xfe;
  *p++ = 0xff;
  *p++ = dmac[2];
  *p++ = dmac[1];
  *p++ = dmac[0];
}

But that code even is commented out.

The code which is used for creating the DevEUI is the following:

// DevEUI generator using devices's MAC address
void gen_lora_deveui(uint8_t *pdeveui) {
  uint8_t *p = pdeveui, dmac[6];
  int i = 0;
  esp_efuse_mac_get_default(dmac);
  // deveui is LSB, we reverse it so TTN DEVEUI display
  // will remain the same as MAC address
  // MAC is 6 bytes, devEUI 8, set first 2 ones
  // with an arbitrary value
  *p++ = 0xFF;
  *p++ = 0xFE;
  // Then next 6 bytes are mac address reversed
  for (i = 0; i < 6; i++) {
    *p++ = dmac[5 - i];
  }
}

As far as I can see FFFE comes first and then the MAC address is added in reverse, correct?
Is this the best current way to create a DevEUI from the MAC address and avoid duplicates?

It is frustrating that you haven’t moved on to having a working node rather than trying to do something that’s not necessary or recommended. DevEUI’s derived from a devices MAC address are not proper, I think that was made clear above, so I doubt you’ll get the reassurance you need. If your device doesn’t come with a properly issued EUI, just use the one that TTN provide.

1 Like

Since the hardware is still on it‘s way from China I can‘t make a working node just yet.
I just wanted to ask if the „new“ method for generating a DevEUI with the MAC address is the one you could use without getting problems. I will NOT use it, I just want to know that because it is another way for creating a DevEUI from MAC besides from the deprecated method.

Please search google as this is not limited to LoRaWAN.

Because you don’t seem to pickup on the frustration from other forum users that do have hardware and more valuable things to do with their time than repeatedly answer the same question I suggest you research this yourself return to the topic when you’re able to share some information on the subject (with links please). I suggest you also check the standard to see if FFFE at the start of an EUI-64 might have a special meaning or if the assignments just have not reached that part of the available space yet.

1 Like