# How to handle an automatic re-join process? **URL:** \ **Category:** Hardware\ **Created:** [February 8, 2020, 10:49am UTC](https://www.thethingsnetwork.org/forum/t/how-to-handle-an-automatic-re-join-process/34183 "2020-02-08T10:49:23Z")\ **Posts on this page:** 1\ **Showing post:** 22
**Author:** ![arjanvanb](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/arjanvanb/32/46626_2.png) [@arjanvanb](https://www.thethingsnetwork.org/forum/u/arjanvanb)\ **Post date:** [February 15, 2020, 11:05am UTC](https://www.thethingsnetwork.org/forum/t/how-to-handle-an-automatic-re-join-process/34183/22 "2020-02-15T11:05:31Z")
> [@ledi007](#): > > If TTN does not lose my keys (worst case) and […], there is actually no reason to assume why data transmission should fail It could very well still fail. It’s radio after all: even if the transmission is okay, it might collide with transmissions from other LoRa-devices or it might not be received by any operational TTN gateway. And even if received, the gateway might not be connected to the internet, the network servers might be down, and so on, and so on. But: such failure would not be caused by some mismatch in the secret keys, so would not be fixed by a new OTAA Join. (If such join would even succeed at that point in time.) ~~Your last flow seems to be the standard flow for an RN2483, I think. In Arduino terminology, the reset, configuration, Join OTAA and the first `mac save` would be in some `setup()`, and the Join ABP and subsequent `mac save` would be part of some measure-transmit-sleep `loop()`. So: the arrow after `mac save` should probably go to some sleep, and then go to Join ABP rather than to `tx uncnf`. I’m sure there are many OTAA examples for RN2483 (including many _bad_ examples…).~~ Recent RN2483 devices [should support `sys sleep` rather than completely powering off the device](https://www.thethingsnetwork.org/forum/t/how-often-should-a-node-do-an-otaa-join-and-is-otaa-better-than-abp/11192/48), not requiring the `mac save` and `mac join abp` in some measure-transmit-sleep `loop()`. And beware: > [@How often should a node do an OTAA Join, and is OTAA better than ABP?](https://www.thethingsnetwork.org/forum/t/how-often-should-a-node-do-an-otaa-join-and-is-otaa-better-than-abp/11192/28): > > Keep in mind the eeprom used to save the values in the RN module might be first to go due to the write limit of eeprom cells… Your example settings, showing SF11, **require** ADR as [it’s not allowed to use a fixed SF11 or SF12](https://www.thethingsnetwork.org/forum/t/can-i-register-an-abp-device-that-has-fixed-devaddr-nwkskey-and-appskey/3831/16). Also, you’ll save quite some time on air, and hence lower the chances for collisions and improve battery life, when using a much better data rate. So ADR is really the way to go. All said: of course it’s good to be prepared for disaster and [human error](https://www.thethingsnetwork.org/forum/t/node-credentials-accidentally-invalidated-any-possibility-to-force-re-join/34328) ( **back up both the fixed keys, and the session keys, DevAddr and counters!** ), or for an explicit wish to join a different network, like if TTN runs out of funds or coverage is poor. (Either when the current network and TTN Console are still operational and downlinks can be used to send commands to the device, or when it’s totally dead. Beware that switching to a _private_ network also needs a different LoRaWAN sync word, I think.) Even a simple [magnetic switch](https://www.thethingsnetwork.org/forum/t/lora-nodes-with-over-the-air-firmware-update/3135/8) to allow for resetting without taking the device apart might already help if the devices are easily reached. But something automated might surely be better for some/many use cases. But then use ADR as a base: only when ADR has made the device use its worst data rate, somehow try to determine if it is not getting a response _for a very long time_ (think _days_, not hours). --- _[View the full topic](https://www.thethingsnetwork.org/forum/t/how-to-handle-an-automatic-re-join-process/34183)._