Hello,
Now that I have the RFM95 working with a WeMos D1 Mini, I am trying find out the Dev EUI of the device. I understand that it is a 64bit address hard coded or programmed into each radio chip. Is that correct?
Using the lmic library, is there an easy way to display the address? I tried using the showStatus method in the TTN DeviceInfo example but it just hangs and does not display the Dev EUI.
Any pointers are greately appreciated.
Mark
As far as I know, there is no unique id in an RFM95.
There is however one in the ESP8266 (which is inside the Wemos D1 mini). You can access it as follows:
ESP.getChipId()
See also
https://github.com/esp8266/Arduino/blob/master/doc/libraries.md#esp-specific-apis
The unique id is 4 bytes long. This id is also used to create the default ESP wifi MAC address by adding the ESP vendor id before it.
replying to myself:
It looks the unique id of an ESP8266 is actually only 3 bytes long, the one in my esp8266 has 0x00 as the first byte. This might still be unique enough for your use case.
Apparently the first few bytes of the MAC address are not always the same, so if you can somehow read the MAC address of the ESP8266 module, that would be the closest thing to a unique id.
DId you get the EUI of RFM95? if yes, just let me know how? I am using Arduino UNO as a micro controller with RFM95.
Since in the last 4 years no-one seems to have discovered a EUI in the LoRa devices, and its not mentioned in the datasheet, one presumes there isnāt one.
If your using a 5V UNO with the RFM95, dont forget the need for logic level conversion circuits.
There is no unique ID in either the RFM95 or an ATmega based Arduino; youāll need to generate a Dev EUI (I believe you can have one generated when you register a device in the TTN console) and then include that in your sketch.
Beware that the Uno isnāt a very good host platform for bare-radio LoRaWAN - not much memory so it can be challenge to fit code versions recent enough to include key bugfixes, and yes, the signal voltage level is also wrong needing translation.
Most LoRaWAN nodes use ARM core processors (even if under Arduino), a few use ESP8266 or ESP32.
A method that Iāve used for management of OTAA parameters on Arduino platform:
Advantages:
This is valid for TTN V2 but in V3 (TTS) it asks for device EUI. Can we write whatever we like?
You should use a valid EUI you own of course to avoid conflicts with those assigned by vendors.
It would be nice if TTN could generate one as available in V2. (@johan)
Generating DevEUIĀ“s would be really helpful. I dont know what to fill in there for self-programmed devices.
By migrating devices to V3, I also want to change from ABP (which most of my devices do) to OTAA. But I canĀ“t do this without knowing what to use as DevEUI.
I guess, using DevEUIĀ“s generated in V2 are not reasonable in V3?
You should be fine using the generated values from V2. When people migrate OTAA devices for which the values have been generated thatās what happens as well.
Ah, I see. Great! 
V2 doesnāt issue DevEUIs, only AppEUIs. V3 doesnāt do that, because V3 supports the all-zeros AppEUI/JoinEUI 0000000000000000.
Sorry, in V2 Iām able to have the console generate a DevEUI, note āthis field will be generatedā in the DevEUI field.
Yeah OK, randomly generated, indeed. Fair enough. Thatās a bad practice anyway.
We could start issuing DevEUIs from our MAC-S block and purchase a new one when we ran out, with some sort of maximum per application or something.
I had a hiccup getting my auntieās LMiC Adafruit Feather RFM95 with all zeros - no worky.
Iāll revisit it now I know more about breaking things less.
Mmm, I guess that getting a valid DevEUI is what most users were expecting (for years already) when they request the V2 Console to generate a DevEUI for their device.
Automatic creation of DevEUI in V2 Console has been the standard procedure for almost all DIY nodes (most use hardware that provides no DevEUI).
Are DevEUIās created in the current V3 console still randomly generated?
Aha! Well, at least we can blame The Things Network for applying that bad practice. 
I would suggest a maximum per user. If a user needs a lot of them they can buy their own MAC-S, those are not that expensive for a commercial entity but too much for hobbyist. (I would rather have the hobbyist spend money on decent hardware that is capable of LoRaWAN compliance 
)
Isnāt this the same as the pre-programmed EUI-64 in Microchipās 24AA025E64 I2C Serial EEPROM? @Charles included support for that EEPROM in his Mini-LoRa design for providing a unique DevEUI for every device.
The EEPROM costs around ā¬ 0,40 (in low volumes) and that includes the hardware so the EUI-64 should only be a fraction of that price.
Itās valid LoRaWAN, but indeed I can imagine some lightweight end device libraries donāt see a difference between zeros and ānot setā.
Makes sense. Issue is filed, you can subscribe here: Issue DevEUI from range with maximum per application Ā· Issue #3750 Ā· TheThingsNetwork/lorawan-stack Ā· GitHub
Not really though, because in The Things Network V2 and V3, only the combination of AppEUI/JoinEUI and DevEUI is unique. Since V2 did issue a globally AppEUI to each application, it didnāt really matter what the DevEUI is. With V3, since we donāt issue an AppEUI/JoinEUI, so then it does matter what the DevEUI is, and it shouldnāt be random.
Agreed, but in the context of applications we donāt have users, only a bunch of collaborators, and keeping maxes across all of them is not feasible.
Itās really cheap indeed. 28 degrees of freedom costs USD 780, so roughly 0,000003 cts per DevEUI. And it gets much cheaper in volume, like the OUI / MAC-L blocks that most vendors have.
