I tried to move a sensor from an application in one organization to another application in another org. We noticed that it wasn’t joining so we tried to move it back to the original org but we couldn’t make it work there either.
Does the sensor think that it’s still in a session and keeps the session key instead of joining a new application with the provided appKey? This has happened to multiple devices and we’re not sure why. Does anyone know why this happens? Is any manual changes required physically with the device?
How do you “move” the device, are you just deleting it and then recreating it in the new “org” (does this mean a new tenant, or a new application?). If so, the device has no knowledge of the Chirpstack side of things, so yes it would still be using the session keys from it’s previous join. if this is the case you just need to force a rejoin on the device or input the previous sessions keys into the device (on Chirpstack) again using the gRPC API.
That’s correct. We delete them and recreate them in a new Application inside another organization.
So we have to force a join through downlink messages? Would this work even though it’s stuck with the previous keys, while being deleted from chirpstack?
Do we find these messages inside of the API documentation? This one for example:
[/api/devices/{device_keys.dev_eui}/keys]
I’m sorry for the overwhelming amount of questions.
No this would not work, Chirpstack can’t downlink with the wrong keys.
You have two options:
manually force the device to send a join (typically power cycling the device will do this) after deleting it and creating it in a new application.
Use the Api to move the session keys.
For the API, you would need to retrieve the keys with a getKeysRequest (or just copy them from the “activation” tab on the device’s page) before deleting the device, and then use the ActivateDeviceRequest to put the session keys back into Chirpstack after recreating the device.
You could also streamline the entire process using the api: retrieve device info, get its keys, delete it, add it to a new application, activate the session keys - are all supported in the API, although it would be quite a few calls.
As for the devices you have already moved their session keys are lost and your only option is to have them re-join.
I tried this by reactivating it with the old keys and I got a response code of 200 which is good and also device data. Unfortunately, it says " * error:“invalid MIC”". Any ideas of what is failing here?
Invalid MIC is almost always because the keys are wrong. Was this a device you just moved now? Or is it one that has been offline for a while and there is a chance it has attempted another join since?
Also I was wrong the getKeys request is not what you want. Still necessary to input the keys of the device but you should use the GetActivation request rather than the getKeys to get the actual session data.
Precisely! It could be that I’ve inserted the wrong key. I’m trying the same thing again but with another device.
How do you know what properties are compulsory to fill out under deviceActivation? Could there originate a mismatch if we for example write the wrong value under the following parameters?
“fCntUp”: 28,
“nFCntDown”: 17,
“aFCntDown”: 0
I believe all of them are mandatory for the activation, but they do not specify what variables mandatory are in the documentation, typically it takes a bit of trial and error.
If the f_counts were causing an issue though it would be throwing a different error. I’d suggest just setting them all to 0 though because when the device does get back online it will likely start from 0.
But you should be able to use the whole response from getActivation as the body in the activateDeviceRequest and not worry about any formatting / copy pasting issues.
