Recently we discoverd that it appears the device_activation table in the Application Server is not populated with device activation data (dev_addr and app_s_key specifically). We are wondering if this is a recent change that is part of an update and if so, when did the change take place?
We have a private LoRaWAN infrastructure and use a central ChirpStack server to make configuration changes to multiple replica ChirpStack servers in remote rural areas with inconsistent WAN connections back to our campus for data gathering via Postgresql Logical Replication. Previously we were able to update device configuration information on our master configuration server such as Variables and Tags without and the changes would replicate to all our remote servers without issue. Recently we noticed when we make a change to a device on our master server, the Device Address and App Session keys are now overwritten. When setting up the replication we specified tables to replicate rather than the entire database, leaving out certain tables in the NS and APP server dabases (device_activation being one of them) that contain more dynamic configuration generated at each remote site. This allows our researchers to move device between sites and only have to re-join the device to continue their work. The concept is similar to Domain Controllers in Active Directory.
Re-joining the device regenerates the necessary keys to allow the data objects to be decoded and processed as normal, but now any change overwrites those keys. Previously we believe the keys to be stored in the device_activation table on the app server and referenced by the device table. Leaving the device_activation table from replication left the keys intact but they are now ovewritten when replicating changes to the device table resulting in no data decoded or recorded.
For the time being we believe we will need to revert back to the Chirpstack version before the table changes and are trying to identify this version.
Information and ideas are greatly appreciated!