We are disabling an older Chirpstack server soon and have been moving devices to a new chirpstack server. I have been doing it by first disabling the device on the old server. Then copying the device-related records from the tables “device” and “device_keys” from chirpstack_as and “device” and “device_activation” from chirpstack_ns. Then used the API to activate the device on the new server. Everything works fine, except for one device.
For testing purposes we created the device on the new server back when the server was first created, just to get some data running. We later went on to use that sensor in a real production environment on the old server. Everything worked fine with the sensor on the old server. We deleted the sensor from the new server. However, now, we need to move the sensor “back” to the new server, but my method above is not working for that device. No data comes in, at all. If I disable the device on the new sensor, and re-enable it on the old server, data comes in fine on the old server.
My suspicion is that there is an old “ghost” record of the device hidden somewhere on the new server, maybe in Redis? Does anyone have any idea as to why this particular device won’t function properly on the new server?
Only 1 sensor, are all the other ones the same sensor? My suspicion is that the one sensor is an older version or something about it is not compatible with the new CS, maybe the device profile, I have no idea. If you really only have one sensor then install a new CS with the new version and add it and see if it can join. Have you tried resetting the devnonce? It sounds like you’re trying to do all this without rejoining, have you tried it with rejoining though, did it connect then and you saw the data?
The sensor is an Elsys EMS Door. It has about 20 siblings on the new server, all working fine. It is the same version as them, same device profile, which was copied to the new server from the old one, 1-to-1. The only difference between the lone sensor and the 20 others, is that this particular sensor was first created on the new server, then deleted, then attempted to be recreated.
I tried resetting the devnonce, no change.
You are correct, no rejoining has been made. We will have a guy at the site in a few days, and he will reset it manually. Then we will see if that solves it. We could try to force a rejoin “over-the-air” (I think Elsys devices can do that), but if that fails, my worry is we would have a malfunctioning sensor until our guy arrives at the site.
So one way or the other, it will be fixed. We could also install one of our spares, with a fresh DevEUI to install. However, I think it would be worth investigating if something is influencing the re-creation of formerly deleted devices.
Sounds good. The join-request / join-accept are extremely important. I’ve never moved an active session from one CS to another but if I did, and it did not work, then my next step would be to ensure there is a join and see if it works then (new session) and go from there.
If you recreated the device on the new sever but did not move the session, and there was no join, then your device thinks it’s still communicating with the old CS. The next problem is, if you can’t communicate, you can’t tell the modem to restart or rejoin. The guys I work with are pretty bad at keeping CS running and lose sessions all the time and our devices take days before they restart. I’ve been considering a secure backdoor to send a restart command, in case the session is lost.