LoRaWAN_ESP32 Arduino library for RadioLib

I just released v.1.0.0 of an Arduino library that interfaces with the way the latest RadioLib version (6.5.0) exposes the LoRaWAN data that needs to be kept between sends.

It can’t only keep this session data, but can optionally manage all provisioning data, presenting a neat dialogue on the serial port if such data is not yet stored in flash. Here’s the output from using the library’s example, which periodically transmits the ESP32’s temperature and then goes back to deep sleep.

Temperature: 36.50 °C
Radio init
No provisioning data found in flash.
Please enter the provisioning information needed to join the LoRaWAN network.
Enter LoRaWAN band (e.g. EU868 or US915)  [EU868]
Enter subband for your frequency plan, if applicable. Otherwise just press Enter.  []
Enter joinEUI (64 bits, 16 hex characters.) Press enter to use all zeroes.  [0000000000000000]
Enter devEUI (64 bits, 16 hex characters)  [70B3D57ED0066DCD]
Enter appKey (128 bits, 32 hex characters)  [17BF330DAFA61F3E076123D97425C805]
Enter nwkKey (128 bits, 32 hex characters)  [490F9F1EB6326425BA1EA2D33CBFF372]
Thank you. Provisioning information saved to flash.
Now joining network.
Message sent
Going to deep sleep now
Next TX in 1193 s

How does this differ from GitHub - radiolib-org/radiolib-persistence: Utility functions for enabling persistence, mainly for LoRaWAN support in RadioLib ??

The provisioning looks handy, perhaps you should split it in to two libraries so each one can do one thing well?

The title implied that it is a necessity to enable use of RadioLib on ESP32 which, given the extensive pin configs supplied for Heltec & LilyGo boards as well as the pre-existing persistence example, would appear to be a little off. Adjustments have been made.

I’ll have a better look at the other one soon. I’m sure there’s a use for both.

This has not been tested (or even assumed to work) on 8266, the other one has. Like you mentioned, this one does something the other one doesn’t in the sense that it can optionally store the provisioning data also. Apart from the serial dialogue, it has an API that makes it possible to feed the provisioning data from other sources, e.g. a web interface or an app.