Wrong decoder data coming from devices after network server migration

1

Greetings!

I’ve been dealing with some issues here while changing devices from a network server to another.

I have some devices created in the internal network server of a gateway. This was done using the MQTT integration, uploading all the information through MQTT messages using the 8080 port. We had no issues so far. 90% of the devices were joining and sending data. We also used an internal decoder to send a data to another server.

Recently, we had to move all these devices to an external network server independent from the gateway, so that for devices that couldn’t join they might find another gateway to send data through. I did the “migration” by basically extracting the information for the devices (devEUI, AppKey, activation tokens, fCnt, devAddr) straight from the SQL of the gateway and importing it into the SQL of the new network server. After that I used the API deactivation command using MQTT to deactivate the devices in the NS of the gateway and activating them for the new external NS using the previously mentioned information. With this I was checking that devices were sending their messages through the external network server using the same gateway. Meanwhile the internal NS wasn’t showing these messages, as expected.

My issue is that apparently since then the data that has been coming in is wrong. The base64 message when translated to HEX is throwing values that are either too big or negative for a device that measures water volume. I don’t know what is causing it. As far as I understand there has been no changes to the decoder or the devices. I don’t know if maybe it was an issue during the migration process and one of the values like fCntUp/nFCntDown.

I have to mention that I did this same process with a couple of other devices for another gateway and we are not having this issue at all. The devices are the same type and are programmed the same and they are sending their messages properly. The devices with this problem were all sending the correct values until the migration was done and I am trying to do a rollback re-activating the devices on the internal NS while deactivating them from the new NS to see if the issue is somewhere else but at least keep the data.

Any ideas would be appreciated.

Thanks.

2

I’ve got some update on this as I tried reactivating devices on the embedded network server of the gateway and one device in particular apparently decided to reconnect by itself in the external network server and now that one is sending the correct payload.

My question is if the problem might be related to the frame counter.

I did an excel where I checked all SQL files while keeping the same number of the frame counter. Obviously because during that time frame the number kept increasing as they were still sending, the moment I “imported” the database into my external network server, the frame counter related to each device was the one from the day I did the extraction and most likely didn’t match the actual number.

Could this cause any issues?

3

Can someone confirm if the devices need to stay activated on the internal gateway network server before activating them on a new network server when using the API commands? Or if setting the frame counters to zero on this activation might be the cause of the devices sending a wrong Base64 payload? I activated in network server using the same keys and tokens and then deactivated from the internal network server of the gateways.