We have an application that uses the ttn-handler-eu (current handler) and no data has been coming through for the past 5 days.
We have another application using the ttn-handler-us-west that is still working.
Please note that the person that setup our application and programmed our prototype devices is no longer available to help us with this so we are looking for help in this community.
From reading other posts, we understand that if we change the Handler in the existing application, this will delete all of our current devices.
If we recreate the devices in this application, do all of the information stays the same as before?
Device EUI
Application EUI
Device Address
Network Session Key
App Session Key
If we create a New Application, my understanding is that we would have to reprogram the physical devices with the new Network Session Key and App Session Key.
FYI, we can not get access to these devices as they are out in the field, literally.
My question is, are we able to save these devices as they are still functioning and if so, do we change the handler in the existing application and recreate the devices.
Check this thread for a solution to move your devices to a new application.
BTW, application handler for EU is working fine for EU devices with EU gateways. Your message suggests your application and the gateways receiving the data are in different regions, may-be you could update the subject to reflect that?
A similar problem might have been posted in @disk91’s Strange behavior on US915, which also started 5 days ago, so maybe there was some recent change in the distribution of data to the different regions?
Just in case it helps others investigate: what are the first 5 digits of the DevAddr you see? (As per the other topic, 0x26012... might indicate EU OTAA, and 0x26022... might indicate US OTAA.)
That would suggest ABP. Does TTN Console show the devices as OTAA or ABP?
Re-registering might not be easy, so I’d first try @htdvisser’s script that @kersing mentioned, so hopefully you’ll get some help with that. Or maybe whatever changed 5 days ago will be resolved.
If all fails, then for both ABP and OTAA one could try the ttnctl command line tool to register the devices as ABP and then force the known DevAddr, NwkSKey and AppSKey. (In LoRaWAN 1.0.x, when OTAA is done, there is not much difference between OTAA and ABP devices; both types use DevAddr, NwkSKey and AppSKey for their transmissions.) Or maybe one can even force these settings onto a newly registered OTAA device as well. However:
If the current DevAddr starts with 0x2601 (for EU) then I don’t know if it can be moved to the US region with that very same DevAddr. Likewise, I don’t know if a 0x26..2... OTAA DevAddr (if I guessed that address scheme right) can be used for ABP.
You’d need to update the security counter values to match the ones that each device knows. Again, the ttnctl command line tool allows for that, as shown in After resetting frame counters, payload is shown on gateway traffic but not in application - #12 by arjanvanb (that only shows --fcnt-up; you’d also need --fcnt-down and TTN Console will show you the current values). I assume the script would also somehow do that. (Disabling the counter security in TTN Console only applies to uplinks, which might suffice for you, but not if you also need downlinks.)
If the devices are actually OTAA, then re-registering them as ABP will be troublesome as soon as a device decides to re-join some day in the future, unless one can force the settings on an OTAA device too, or unless one can change from ABP to OTAA without the keys being wiped (until the device decides to join again). One could easily test that, I guess.
How many devices are we talking about? Could you test with a single one, even if that would render it useless?