Create AppEUI

In the V3 console the AppEUI can be set to 0000000000000000 if my device has no AppEUI.
I am not using an external join server.

If I do not want to set AppEUI to all zeros, as a work around, I can goto V2 console (till end of 2021) and generate an AppEUI and use it in the V3 console.

My questions:

  1. Is there another way to self generate the AppEUI similar to DevEUI DevEUI for non-hardware assigned values. I know that AppEUI starts with 70B3D57ED.

  2. Will TTS CE developers implement autogenerate DevEUI and AppEUI in the V3 console somewhere in the future?

The questions are relevant for users creating their own DIY devices using Hope RFM95 LoRa modules

1 Like

Why would you not use the standard all zeros for the AppEUI?

For the DevEUI, there should be a GitHub issue for the V3 stack to implement generating one. Found it: Issue DevEUI from range with maximum per application · Issue #3750 · TheThingsNetwork/lorawan-stack · GitHub

Keep in mind your V2 work around stops working when V2 goes read only at the end of this month. Not at the end of the year.

Yes, very comprehensive answers to be found by searching the forum - it’s not just AppEUI, it’s DevEUI too.

That’s not a whole number - it’s 9 hex digits.

The MA-S block allocated to TTN is 70B3D57E 7ED000-7EDFFF but you can’t just create an EUI based off their purchase - mostly because the one you chose may be officially allocated by TTI to a device or application or join with consequences for you & the legitimate user of the EUI. This is even more important now the Packet Broker is routing packets between many parts of TTS - CE as well as paid editions.

People have asked but there is no motivation to provide official EUI’s for a free service.

The very best option is you can buy Microchip chips with an official EUI that you then have the right to use.

Or you can follow the advice in generating your own.

Hi Jac,
I did not know that using all zeros for the AppEUI is the standard if you do not have an AppEUI. In your given github link Johan Stokking also mentioned this: “For the JoinEUI: people can (and should) use all-zeros if they don’t have any.” Unfortunately in the V3 console in the AppEUI helptext it says “it is okay to use all-zeros” and that was the reason I asked the question. I was under the assumption users can put anything(?) in, even zeros. Better helptext should be: “It is highly recommended to use all-zeros if you do not have an AppEUI” or “You should use all-zeros if you do not have an AppEUI”.

I have read the “Issue DevEUI from range with maximum per application”. I am confused why The Things Industries want to generate devEUIs from THEIR IEEE MAC block; i.e. 70B3D57ED. Why not generate local administered MAC addresses as mentioned in the “DevEUI for non-hardware assign values” post?

Thanks for reminding me that V2 goes to read only at the end of this month!

Hi Nick,
This is useful information.

  1. From what I gathered from information from Jac Kersing, users with devices with no AppEUI should use all zeros.
    Messing around with a self created AppEUI is NOT a good idea.
    You also clearly explained why this is.
  2. I have my own DIY end device with no devEUI. If there is no autogenerate DevEUI of course I will generate my own Local Administered MAC (DevEUI).

Mostly because TTI have moved to a firm compliance model - they would like everyone to have the right EUI’s for their stuff. For the smaller user / Maker this will raise an eyebrow but we are not blocked from anything, just encouraged to make it so.

Because they have 800+ million EUI’s in that block, so they will have bigger problems to deal with if they end up using even half of them on live devices.

But they do pay handsomely for the DevAddr’s - $20,000 a year - but they are only used on devices with a session, so less wastage - but again, will be an interesting workload with 33,554,432 addresses potentially available - the split across various instances will erode that somewhat, but still 20+ million devices is a goodly number!

Small correction:
MA-S block uses OUI-36 (70B3D57ED), which means 64 - 36 = 28 bits can be used by TTN
2^28 = 268,435,456 EUI-64 addresses

But your point is still valid.