Managing Joins

[wstallwood]

We are looking at deploying a good number (potentially 1000's) of devices we won't have easy physical access to on a private LoRaWAN network.

What is the best practice in terms of managing joins ?. Does "lora.has_joined()" reliably return the correct state if for example my loraWAN server has unjoined the device for some reason (I'm thinking in terms of if we had to recover from a backup and lost some of the joined sessions).

I'm trying to think of failure scenarios that would potentially render our devices inoperable until they were rebooted and cover them.

Should my code be periodically checking that and rerunning a join if required ? or does lora.has_joined() stay set to true after a successful join regardless of the actual state.

I am using this lorawan-server.
https://github.com/gotthardp/lorawan-server

[wstallwood]

Thanks, that makes sense and yes we are concerned with Gateway time on air.

So a confirmed uplink which feeds back into my join code if it doesn't get an ack might be sensible and we could have this repeat over a fairly large timeframe, as the scenario I am thinking about is really a DR situation where we somehow lost the database behind our LoRaWAN server and how we'd get nodes talking again.

[jmarcelino]

@wstallwood
The LoRaWAN protocol by itself does not transmit any regular state (or 'pings') between nodes and network server. Also by default nodes just send packets without acknowledgement. So has_joined only means the network keys have been set correctly (in the case of OTAA joins)

The only way to know if the server is still reachable is to send a regular downlink (which would need to follow an uplink) or a confirmed uplink which would send an acknowledgement downlink automatically.

But beware, downlinks (from network server to nodes) are usually extremely limited because they add to the gateway's time on air (which is usually restricted by regulations). Also when the gateway is sending a downlink it stops listening on all channels, so the more downlinks you send the more lost uplinks you'll encounter.

The usual approach is to send a confirmed uplink once in a while (maybe once or twice a day) and go from there. If you add a counter to your data you can also figure out which packets went missing.

Hope this helps.