DevEUI and internal chip ID

[battosai30]

trafficstars

Hi,

I have some interrogations about DevEUI attributions and I hope you will help me clarifaying this point ...

So as I understand this, Murata ABZ doesn't supply a DevEUI (I pretty sure I read that on a Murata note ...) and it's on the developper to provide one in the code. For TTN network it's not a big deal at all as TTN provides it. But I'm working with private operators that doesn't provide it (Orange in France in my case). So, what's the best way to do ?

• For now, I use TTN to create "fake" devices and use the devEUI generated. Not very good as if TTN gateway is in the neighborhood it join it ... I managed that in my back end but it's not rigourous and I'm not sure TTN allows this borderline usage.

• I read in a forum that a guy used the internal chip ID of the STM32 on Murata ABZ to generate DevEUI : huumm ... For me it's not OK : it's a serial number that's unique only in the "Murata's world", not in LoRaWAN's world.

• I guess I need a membership in LoRa Alliance is the right way to do, but can't find informations on it ...

Thanks !

[GrumpyOldPizza]

It is a tad compicated. You are supposed to get a IEEE EUI64 for your devices. Then the DevEUI is unique.

On the other hand, the "DevEUI" needs to be only unique for all devices having the same "JoinEUI" / "AppEui".

It is my understanding that IEEE EUI64 has an exception for "locally administered" EUIs. With that it should be possible to have a local IEEE and still satisfy the LoRaWAN standard.

The bigger issue at hand is how to create (guess) such a unique number ... STM32 has a 96 bit unique ID that is derived basically from where the wafer came from, and where within the wafer the chip was located. But wiggling that down to a say 60 bit number, of 48 bit number does not seem to be possible.

[battosai30]

Thanks for your quick answer !

Ok so, unlike USB (with PID) or MAC Adresses, there is no authority to attribute vendor/productor IDs ? So I guess, the only form of authority which could require somthing is my operator ?

[hallard]

@battosai30 I'm using internal devEUI of Murata on Orange portal, as @GrumpyOldPizza wrote only the "trio" devEUI/appEUI/appKey need to be unique. If you let Orange to generate your appEUI (as TTN does) it should be no problem not? I selected Murata in Orange (LiveObject) device profile not sure it change anything

[battosai30]

Orange doesn't generate any key :s They also do something strange : they do not send appEUI on MQTT, so I can't make a universal code on my backend that is able to route data depending on the app ...

I'm curious, how do you get internal devEUI ? Basically, Murata cmwx1zzabz is just an assembly of a standard STM32L082 and a SX1276. Both are not design to manage LoRaWAN stack, so a deveui ...

[hallard]

I'm basic, just used api :-)

  char lora_deveui[18];
  LoRaWAN.begin(EU868);
  LoRaWAN.getDevEui(lora_deveui, sizeof(lora_deveui));

  DBG("LORA DevEUI:", lora_deveui);
  DBG("LORA AppEUI:", appEui);
  DBG("LORA AppKey:", appKey);

  LoRaWAN.joinOTAA(appEui, appKey, (const char *) lora_deveui);

And I agree, Orange API is just missing too much things, we can't even get back all the key we entered for a device, but you can try the other one, Bouygues with Objenious, they do not provide MQTT broker just HTTP api, what's a pity !!!

[battosai30]

And Objenious requires your device passes their certification : 5000€ ...

I did not see getDevEui(), but I check and it's what we discussed with @GrumpyOldPizza : it's a DevEUI generated from UID of the STM32, so it's not impossible to get two devices in the world with the same devEui. But as you said too, devEui + app key + appEui complicates the chance to statistically go against LoRaWAN requirements

[hallard]

Yeah I heard that about objenious certification. A customer has a account and he asked me to provision devices. I’ll check to see if I can add some murata boards

[battosai30]

You will be able to I guess, they have no way to know the chip sending the message