Now that it is clear that all devices will need to rejoin the network during the V2 to V3 upgrade, could you please update your best practices to include exactly what you expect here? ie if the network is upgraded to v4 next year, what rejoin behavior would you expect devices to have so that people don’t need to physically go out to these non-rejoining devices?
As is, the original best practices for v2 implies that rejoining shouldn’t ever really occur, and many of the “rejoin if link check failure” or “rejoin if confirmed uplink failed” strategies proposed actually directly contradict the advice which was given in the past (ie don’t rejoin on network failure). So if you followed this advice, you would be in quite a pickle right now… For example:
When a device performs a network join, a DevAddr is attributed and sent to the device. DevAddr are designed to be kept in the long-term, from days to years - The Things Network is designed to keep activations in memory for years, even in the event of an outage.
For this reason, the LoRaWAN documentation specifies clearly that devices should perform join operations the less possible in their lifetime. The LoRaWAN specifications warn especially against systematic rejoin in case of network failure. A device should keep the result of an activation in permanent storage if the device is expected to be turned off during its lifetime.
I’m not involved in writing the best practices, but what I think I personally will do from now on, is to implement a downlink command that triggers a hard reset of the node which includes doing a new OTAA.
I’m not sure that would be enough unfortunately, as the downlink power on some gateways is much lower than the uplink power on the device, so the downlinks often can’t be delivered without falling back to a much lower data rate.
Rejoin after N link check failures is also not good, as some devices only send data very infrequently. And for devices that send data often, if the network goes down temporarily and they all change to rejoin mode, your gateway is going to be hammered by joins when it comes back (not to mention the battery life implications).
I think the only real option is to rejoin once per month (using an RTC or similar). Sucks for battery life though and adds cost to keep time.
As per the migration path in Migrating OTAA Devices from V2 to V3 you can modify the AppKey slightly in v2 (e.g. change one byte), so the current session stays alive, but new OTAA joins will be rejected by v2 (due to key mismatch) and be accepted by v3 (which has the correct key). So what I would do then:
make sure the device is still on v2
copy all node setting from v2 to v3, then change the AppKey in v2
send the custom ‘reset’ downlink command in the v2 console
wait for the OTAA to happen successfully on the v3 console