Library not usable for a "once in a lifetime OTAA join"

[Alex9779]

Think I have to explain what I mean with the title...
As far as I recall it is best practice to join a network as few as possible maybe just once when the device is provisioned.
That is why certain values can be saved by the module in EEPROM to survive a power cycle.
So the default join method of the lib is OTAA, the values are saved and yes they are stored on the EEPROM and when I call again to join with no keys passed the stored one are used. But the module actually joins the network again, getting a new device EUI.
But sending data after a power cycle is not possible without a join!
What I found is that it is possible by joining with ABP on subsequent power ups.
When joining with OTAA the module also receives needed values for subsequent ABP joins where actually no data is transmitted, it is just loading the keys for encrypting the communication. But actually this does not work out of the box, no idea if this is a firmware bug or something. As you can't read those values you have no idea if they are really there or just stored temporarily, fact is that a simple OTAA join works until the next power cycle but then you can't join by ABP because the module tell you it has no keys.
I found a clue here: https://www.thethingsnetwork.org/forum/t/otaa-join-status-showing-not-joined-after-power-cycle-rn2483/23948/11
So what you have to do is to network session key and app session key with zeros before joining with OTAA, then the module saves the values in EEPROM and they survive a power cycle.
This enables you to do an ABP join with the stored values.

Any thoughts?

When I get time, I might prepare a PR with a proposal of changes...

[Alex9779]

Just went over the PRs, it seems to me that #66 is doing this, got to have a look at this...

[jpmeijers]

Hi Alex, thanks a lot for these comments.

I was under the impression that one can just simply do an ABP join which will load the previous keys from eeprom which was stored during the previous otaa join. But I have never tested this myself. Thanks for explaining the extra steps necessary.

Originally this library had the goal of trying to be as simple as possible, getting connected with TTN with the least amount of effort. But with time the requirements of the most users changed. This requirement of being able to "sleep" and come back and continue where you were is one of the more advanced use cases which weren't originally taken into account. Adding support for it would indeed be great.

For some reason I missed PR #66. If you could review that PR it would be great. Then I can reliably merge it in.

[Alex9779]

Thanks for your quick answer, I will see what I can do.
I have a hobby project I am working on at the moment for which I need this and your lib is a perfect starting point to improve what I already have, so improving the lib helps everyone...