It’s been said before: devices don’t “connect” to a network. They simply transmit, and hope one or more gateways receive their packets and forward those to the operator (TTN) at which you registered that device.
I think that getting the join status bit from the RN2483 will tell you if it has ever received a DevAddr and the secret session keys in an OTAA Join Accept, and still knows those. (Those details are persisted between reboots using
mac save.) If this status would also change if the device somehow knows its uplinks are no longer being processed, then I’d expect the RN2483 to already have initiated a new join itself? Or have a setting for that? This would invalidate the old secrets.
So, I’d expect that querying that status bit is of no use to you (after you once joined successfully).
Using ADR or using a confirmed uplink every now and then (say, every few days) might enable the RN2483 to figure out that the network no longer responds. For ADR this would take much longer than one day, if the device transmits once per hour. That could make it decrease the SF, or maybe increase its transmission power if the network ever told it to decrease that, and after a lot of tries decide its uplinks are no longer being processed. You’d have to get information from Microchip’s documentation to see if that indeed would get it to a point where it decides to re-join by itself (or only change that status bit, which I doubt).
To extend on what has already been written about the need to re-join, I feel there’s only 3 reasons why a re-join would ever help:
When the frame counters overflow; I think it’s documented that for this the RN2483 will re-join automatically.
To change to a different operator. This is not limited to a network stopping its operations, but is something you might also want if the current network is still operational; see How can an operational node be triggered to join a different network?
If the network (TTN) lost its keys in some disaster. For that, a TTI developer once wrote:
Still, I feel you should backup those details yourself too.
If the network does not receive/process a device’s uplinks for other reasons (like: poor coverage) then re-joining will not help, as that will fail too.
It’s already received in the OTAA Join Accept. But the DevAddr will change for every new OTAA join. So, there’s no point in setting it when you’re going to do a new OTAA join? Also, the DevAddr does not suffice to restore a session: you also need the secret NwkSKey and AppSKey, which I think the RN2483 keeps a secret from the application code. Anyway,
mac save will save all those details, including much more state, such as the network channel settings, the device’s frame counters, and its ADR states.