Looking at the console screen shot that clearly has another gateway in the meta data but is not on view and taking the description of:
and the change in format of the JSON in the quoted message, perhaps the issue isn’t that both gateways aren’t appearing in the meta data (hard to tell without seeing the entire of the console event details) but that the original opening description was referring to the data as it appears in TagoIO.
As this has only just come to light and because the device is hammering TTN way beyond anything reasonable for the Fair Use Policy, I’m closing this thread because it has, as a notable Python would say, got silly.
@claudiormrosa, can you look at how you originally presented the information, what we asked you to try that as yet hasn’t been actioned, read up on the Fair Use Policy and look at the entire of the device JSON. It is still not clear to us if both gateways are on TTN, if only one is, then you should only expect to see data for one.
If it transpires that both gateways are on TTN and being heard as seen in the device meta data, you’ll have to take up the issue about why they only keep the first gateway entry with TagoIO. This is a common JSON processing error - device health & mapping is all about having more than one gateway hearing a device.
After you have reduced uplink interval inline with FUP and the RSSI to a reasonable level as detailed above, if you are still only getting one gateway entry in the TTS meta data, then please open a new fresh topic with a more considered description, copy & paste text carefully formatted, only use screen shots when you can’t, show both gateway logs, both gateway console entries, the device console JSON and the TagoIO JSON for the same point in time - this takes a few minutes to setup the browser windows but if your device is only uplinking every 3 minutes, you will have about 90 minutes to capture all the information before it all scrolls off the end.