Device being seen by gateway but not updating status/data

Hi,
I had a couple of devices setup and working in the past. After a few months I went back to them, and it looks like they are not updating information. The strange thing is that if I go to https://console.thethingsnetwork.org/gateways/{name}/traffic I see downlink traffic coming from a specific device.

But if I then go to https://console.thethingsnetwork.org/applications/{name}/devices/{name}
The last seen status is 8 months ago, and inside the data tab, everything is empty.

What could be going on?

Thank you!

What counter values are the devices at?

This is what the Lorawan gateway is showing:
Screen Shot 2020-02-11 at 6.08.26 PM

And this what thethingsnetwork is showing on the device overview:
Screen Shot 2020-02-11 at 6.05.50 PM

Does that help answer your question? Sorry, I’m new at all this…

And this is what the gateway is seeing on thethingsnetwork
Screen Shot 2020-02-11 at 6.10.10 PM

The third one is the device in question

Starting with the basics -

  1. check and double check your keys.
  2. check your antenna connections
  3. make sure you have good coverage (but not too close to the gateway as well)

What kind of node are you using?
Are you trying with ABP or OTAA?

The counters are totally out of sync. You will probably need to restart the device to get it back in working order.
Then monitor if it keeps sending data to the application when the counter reaches 64k. I suspect it will not (device on TTN is probably set to 16 bit counters when the node is using 32 bits).

BTW, keep in mind TTN fair access policy allows for 30 seconds airtime for a node per day. You seem to be sending 100 packets in < 2 hours which will result in a lot more airtime.

1 Like

To see/confirm that the device has exceeded the limits of a 16 bits uplink frame count (65,536), one can paste a Base-64 encoded payload from the gateway’s Traffic page into an online decoder, and then also specify the AppSKey and NwkSKey. Using those secrets, the decoder will show the MSB of the frame count (which is not in the packet itself, but needs to be determined by the server, for which a real LoRaWAN server then assumes the counters are not too far out of sync).

See After resetting frame counters, payload is shown on gateway traffic but not in application to re-sync the uplink frame count in TTN and the device. That won’t work for the downlink counter though, so simply restarting the devices is surely easier, but maybe you want to know what’s happened.

Thank you all for your replies. I’ll make sure to check everything and get back to you all with more info/results

Hi,

We are experiencing the same problem.
We have a Things Indoor Gateway. We set up this gateway in the things network console and it’s working, its status is connected and in the traffic page we see join and uplink trames.

We created an application and set up 7 devices with their deveui and AppKEY (OTAA ), but we are not able to see their status, for any of the 7 devices.

We have already used these devices with another gateway without thethingsnetwork platform and it’s worked well.
But with the Things Indoor Gateway and the Things network console even when we reset the devices (they send a join command after restart) their status are still never seen.

Do you have any idea to understand and fix this problem ?

Thank you !

For those 7 devices? So, the OTAA joins succeeded and the devices are transmitting data uplinks, with a 0x26/0x27 TTN DevAddr? (Just to make sure they did not join the previous network.)

What about their AppEUIs?

Any cross-region involved? Are you seeing data through some integration, or when using the MQTT API?

Thank you for your response.

Not for the 7, for some devices I don’t see any traffic (join or uplink), for the devices appearing in the console their DevAddr are not prefixed with 0x26 or 0x27. See below the trafic.
gateway-traffic

Now I received data with a device, but I updated the device to set the AppEUI with the same AppEUI defined by TheThingsNetwork.
I’m little bit confused because I thought that the devEUI and appKey was enough. Does this mean we have to register all our devices in the TheThingsNetwork (we will deploy 300 devices), read the AppEUIs and set up each device with this AppEUI ?

Regarding the MQTT, for now we just want to test the reception of data. After that we want to send the data to AWS IOT (we already use that with Multitech gateway for MQTT broker)

If you are sure your’re seeing data from your devices (and not some other devices in your neighbourhood), then apparently they (re-)joined to the other network. If two networks know the same device, then both might receive the Join Request and might create a Join Accept, in which case it will be a roulette game as to which Join Accept is handled by the device, if any. So, make sure they’re no longer registered with the other network (at least not with the very same values for DevEUI, AppKey and AppEUI).

Indeed, you will need the DevEUI and AppKey (in the device’s settings) and the AppEUI (in the application’s settings; in V2 make sure to select the right AppEUI in the device’s settings, in V3 you will also be able to set this in the device directly). If the devices already have those assigned/programmed, then you can also copy these existing values from the device into TTN. For the AppEUI you can add one or more AppEUIs to an application, using either TTN Console or the command line ttnctl.

(Like written above: when not using a TTN-generated AppEUI then make sure the other network does not know the device with the very same values.)

I asked as sometimes TTN Console does not show data, while the other interfaces work just fine. Something to remember when troubleshooting. :slight_smile: Also note that the MQTT API has an error topic, which (sometimes) can help during debugging. So even a command line MQTT client can be very helpful.

I have the same issue. I have a device that has been online continuously for around six months. It holds the counter in non-volatile memory so that it can resume after a battery failure etc. Today I rebooted the device and now the data does not get through to the application. The device is on the gateway, and I can see the counter value is correct, but nothing on the application console.

There’s almost certainly a bug in the counter handling on TTN side. I’ve tried setting/resetting the counter flags, tried switching between 16 and 32 bit counters etc in the hope that it would reset something on TTN side, to no avail.

It seems the only remedy would be to re-flash the device to reset the counter to 0, which is ridiculous.

As the problems seem to have started when you restarted the device, why do think the problem is at the server? Why did you restart in the first place? We’ll need many more details if you want help.

(There is a bug for ABP devices: when editing an ABP device in TTN Console, then TTN resets both the uplink and downlink counters. But you did not make any changes before the problem started, right? Also, see After resetting frame counters, payload is shown on gateway traffic but not in application like already mentioned above as well.)

Thanks a lot for your response.

I don’t see the command to set the AppEUI in the console in the API Reference manual. Could you tell me how to do that ?

In TTN Console just go into Settings, and then EUIs, and click “add EUI”.

TTN Console

But you’re right, it seems ttnctl might not support that? I don’t have it installed on the machine I’m using right now; maybe its help shows more options?

The source code does not seem to implement some applications set command either. But for devices set it seems that the --app-eui flag changes the device’s AppEUI rather than selecting some application with that AppEUI. I don’t know if that AppEUI needs to be known to some application already then… In the Application Manager API, the AppEUI might also be part of SetDevice rather than SetApplication.

I’m quite sure that TTN Console uses some of the public APIs as well…

Hi Arjan,
I made no changes. The device has been running for over six months. I only powered it down to take it off the bench power supply so that I could put some batteries in it. The gateway sees the join and accepts the join. As far as I know, it’s still ‘joined’ to the network, but after one week still no data in the application. It uses OTAA, not ABP.
Regards
Mark

That just doesn’t make sense. For OTAA, a new join should reset the counters to zero. So, either persist the values and don’t do a new OTAA Join, or wipe all data and do a new join. Not some funny mix of the two.

Thanks for the reply. Well in that case it could be argued that my code is wrong, as it does not reset the counter to zero when it joins. However, it should not matter as I have counter checking disabled in the TTN console device settings. This is why I suspect a problem on the back end.

The current counter value is 45789 (I can see it on the gateway in the TTN console) but as I say, it shouldn’t matter as counter checking is disabled. Puzzled!

Regards
Mark

You should only disable the counter replay security during testing, and even then you should also implement the same in your device then, for the downlink counter.

However, 45,789 exceeds 16,384, which cannot be fixed by disabling the counter replay security. See: How much frame count deviation is allowed?