Migrating from a different server product to Chirpstack - how do we force new joins?

Devices
#1

We are evaluating Chirpstack, intending to move from a different server product. we have seen some surprising behavior from our devices and it could inhibit our ability to do so.

We have a couple thousand deployed OTAA sensors (LoRaWAN 1.0.4) with gateways that point to our existing non-Chirpstack server. So, they are all joined with a network and have been assigned DevAddr’s. When one these devices is added to an application in Chirpstack, and is triggered to send a payload via a gateway that is now configured to point to the Chirpstack instance, we do not see it update in the device’s configuration or “lorawan frames” table. However, we can see the frame come in via the gateway “live lorawan frames” view. But once we manually reset the device and force it to request a join, the device appears as expected in Chirpstack.

So what we think is happening is that the device already has a DevAddr that was assigned by the old server, which it sends in its uplink. Chirpstack does not recognize this session and just ignores it. The problem is that we simply can not manually reset each and every deployed sensor to force a rejoin. Many of these sensors have FCNTs in the thousands and tens of thousands…so they’ve been up and running for some time without a reset.

Is there anything we can do to migrate these devices over to Chirpstack without having to physically access them?

#2

I don’t think it’s possible for LoRaWAN 1.0.x itself. Have you checked whether your devices have a command for getting reset/reboot? Perhaps the reset/reboot command will also involve rejoining the network.
If not, then what happens if the device has been unable to get any downlinks for some time? Some devices might attempt to rejoin the network under such conditions.

#3

Thanks! A reset downlink command is a great idea, and our manufacturer recommended that as well. Unfortunately, the device firmware does not automatically attempt a rejoin after a certain period of silence. The manufacturer says it’s not within the v1.0.2 spec so they did not implement it.

The problem with the reset downlink command solution is that the old LNS needs to be responsible for sending the downlink, but the new Chirpstack server has to handle the join. The time period between the downlink and when each device will wake up and receive it it will vary over 6 hours as that’s their wake-up and check-in cycle. So it seems as if we’ll need to locate an additional gateway for every one deployed…one configured for the old LNS, and the other configured for Chirpstack. We have about 50 gateways deployed in the field, so that could get pretty hairy!

#4

What if you reset the device and delete it from the old LNS after being sure that it has indeed begun on the reset process? If it’s deleted from old LNS, surely the JOIN ACCEPT will not be sent? And I guess you would then have time to bring it onboard Chirpstack?

#5

The real problem is that the downlink will have to be queued via the old LNS, and then transmitted via local gateways configured to use that LNS. (We’ll have disabled any new joins for those devices.) Then we’ll have to push new configs to the gateways to point to the new Chirpstack instance and hope they make a JOIN request. Presumably the devices perform JOIN requests on a periodic basis when rebooted and no network is found, so that if the configuration change happens they will still be looking to join a network.

#6

Please note that you can use the activate device API method for both ABP and OTAA devices. In the latter case it can be used to migrate devaddr, session-keys and frame-counter values, such that the device does not need to rejoin :slight_smile: