# How to handle an automatic re-join process?

**URL:** <https://www.thethingsnetwork.org/forum/t/how-to-handle-an-automatic-re-join-process/34183>\
**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:** 18

<div class="post-metadata">

**Author:** ![cslorabox](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/cslorabox/32/35697_2.png) [@cslorabox](https://www.thethingsnetwork.org/forum/u/cslorabox)\
**Post date:** [February 14, 2020, 9:29pm UTC](https://www.thethingsnetwork.org/forum/t/how-to-handle-an-automatic-re-join-process/34183/18 "2020-02-14T21:29:17Z")

</div>

LoRaWAN confirmed uplinks probably don’t actually do what you want.

First, if you are using ADR (which is almost a given with OTAA) then the ADR state machine itself gives you some idea of confirmed connectivity.

Next, the confirmed message scheme is badly thought out - if you’re going to use it, then at least modify the node to never retransmit on failure, instead make the next ordinary message confirmed as well. That’s because if it’s the downlink side of the confirmation that fails, then no matter how many times you re-transmit the uplink, you will _never_ get a confirmation for that re-used frame count.

But ultimately, what do you hope to accomplish in the case of failure - how is resetting the MCU going to fix anything?

---

_[View the full topic](https://www.thethingsnetwork.org/forum/t/how-to-handle-an-automatic-re-join-process/34183)._