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.