Dear,
I would like to utilize the function of the DEVEUI created by ChipID but it looks like the parameter is not initialized when changed.
I tested the function: LoRaWAN.generateDeveuiByChipID(); this seems to work when activated a self-made parameter.
#if(LORAWAN_DEVEUI_AUTO )
LoRaWAN.generateDeveuiByChipID();
I think the LORAWAN_DEVEUI_AUTO is not set when changing the parameter in the tool menu:
Do other people encounter the same problem?
Yes it is being set but for whatever reason its wrong in code
LoRaWAN.generateDeveuiByChipID();
only delivers a 8 bit integer array for the DEV EUI it has no nested function to change the join functionality.
Unless im missing something the example should be:
#if(LORAWAN_DEVEUI_AUTO )
devEui[] = LoRaWAN.generateDeveuiByChipID();
Reconnect the board and try again.
I am also having issues with this. My dilemma is that it will be difficult to maintain a tidy development environment if the plan is to simply duplicate source files and change the devEui, appEui, and appKey every time.
Theoretically, I could write some sort of script that goes into each file and replaces these fields with my input ones… but this seems like overkill if “generateDevEuiByChipID()” is a function that just exists for me to use!
I tried JackBonnell’s solution but it was incorrect syntax. The only way this compiles is with:
LoRaWAN.generateDeveuiByChipID();
and even then, using the CubeCell Configurator, I am not able to check that the DevEUI is properly generated. No idea why.
You can add print function to see EUI.
See, I did that eventually. But my issue was one of design – automatically generating the DevEUI meant that it would not save it inany meaningful way between boards.
My strategy has been to write a bash script that automatically generates the DevEUI from ChipID based on a different algorithm (not just generateDevEuiByChipID(); from LoRaWAN_APP.c) to avoid collisions, then this is copied to clipboard, a new .ino file is created based off of the “testing/development” .ino file.
The idea is to have a single “Heltec CubeCell AB02S App” file for each LoRa application, and then when I need to flash 5 boards in quick succession, the filesystem doesn’t get crazy hard to organize. This way, there will be one “root” copy that can then be quickly flashed to 5, 10, 100 boards and have them all generate unique DevEUIs once the test is done, and then hard code them into new files to flash.
The benefit of this over just calling generateDevEuiByChipID (); is that the generated DevEUI can be made available to the user without much twiddling around with Serial – you run a script, get the DevEUI, then go on to copy your AppEUI/AppKEY, and your device works. As opposed to juggling 100 sets of 3 keys apiece… I’ll take my way.
LoRa sensor network is rarely just one node too. I’m just trying to avoid something like:
“Device 1.ino” “Device 2.ino” … “Device 99.ino” oh crap!! something needs to be changed in the base code for this sensor!
A little bit of automation can go a long way.
Writing a bash is a good idea.