Device being seen by gateway but not updating status/data

[jlubeck]

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!

[kersing (Jac Kersing)]

What counter values are the devices at?

[jlubeck]

This is what the Lorawan gateway is showing:

And this what thethingsnetwork is showing on the device overview:

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

[jlubeck]

And this is what the gateway is seeing on thethingsnetwork

The third one is the device in question

[Paul_Stewart]

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?

[kersing (Jac Kersing)]

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.

[arjanvanb (Arjan)]

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.

[jlubeck]

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

[ThomasF]

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 !

[arjanvanb (Arjan)]

in the traffic page we see join and uplink trames

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.)

We created an application and set up 7 devices with their deveui and AppKEY

What about their AppEUIs?

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

[ThomasF]

Thank you for your response.

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.)

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.

What about their AppEUIs?

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)

[arjanvanb (Arjan)]

for the devices appearing in the console their DevAddr are not prefixed with 0x26 or 0x27

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).

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 ?

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.)

Regarding the MQTT, for now we just want to test the reception of data.

I asked as sometimes TTN Console does not show data, while the other interfaces work just fine. Something to remember when troubleshooting. 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.

[ThomasF]

Thanks a lot for your response.

Indeed, you will need the DevEUI and AppKey (in the device’s settings) and the AppEUI (in the application’s settings; in V3 you will also be able to set this in the device). 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 .

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 ?

[arjanvanb (Arjan)]

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

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…