TTN Console stopped showing downlinks for TTIG

You’re right. Most details are in the downlink, in the gateway Traffic, but that’s the one you do not even see…

What if you schedule a dummy application downlink? (That’s in the device’s Overview page in TTN Console.) If that shows as expected, then ACKs for confirmed uplinks might be broken.

Also, subscribing to the MQTT Data API might show more. Use the -v flag to include the topic in the output, and use double-quotes on Windows, like:

mosquitto_sub -v -h eu.thethings.network -t '#' -u my-application-id -P ttn-account-v2.kFd8<redacted>_il4

my-application-id/devices/my-device-id/up {"app_id": ...}
my-application-id/devices/my-device-id/events/down/scheduled {"message": ...}
my-application-id/devices/my-device-id/events/down/sent {"payload": ...}

If things are suddenly fixed when no longer using SF12, then I guess it’s related to your device not adhering to ADR commands that TTN has sent earlier (which it very likely has tried, as the network does not like SF12/DR0 either), which will make TTN stop sending ADR commands. That, of course, should not stop all downlinks, but who knows…

Am I right to assume this is ABP? If yes: did you set the correct EU868 RX2 parameters?

I tried it just now, but nothing appears on the gateway traffic.

My node is now emitting using SF7, and is showing accordingly in GW traffic, but still no downlink.

This is indeed ABP, and i set RX2 parameters with 869.525 MHz and SF 9, as requested by the documentation I found.

For the MQTT Data API thing, I have to install things on my computer if I understood correctly, and I cannot do that, as I am working on a locked companie computer…

Thanks again for your help!

Is it possible that my GW is actually physically broken and so cannot send LoRa messages anymore?

I doubt that the TTN network would be aware of such gateway failure. It seems TTN is not even delegating the downlinks to your gateway.

Do you only have a single device? Maybe delete that in TTN Console and add it again using the same DevAddr, AppSKey and NwkSKey? Oh, bummer, that needs the ttnctl command line interface to force using the existing DevAddr… (Or needs you to reprogram the device as well.)

At least something good comes out of this then: this should convince someone that you should be able to use more than just Windows Notepad and Clock.

I already tried to “delete and recreate” a device, using new keys (and devaddr), and indeed I had to reprogram the device. Changed nothing as well…

So, to summarize:

  • ABP node with correct settings for RX2.

  • The metadata shows that the uplinks are only received by the TTIG.

  • The TTIG’s Traffic page in TTN Console shows the confirmed uplinks, but since yesterday is no longer showing the network ACK/confirmation downlinks, nor application downlinks.

  • The application’s Data page shows the uplinks too, so TTN clearly accepts the uplinks. (So: no frame counter security problems.)

  • The Data page also shows downlinks, which I assume are the ACKs. However, even though on port 0 (so: even though those are not application downlinks) I wonder if the application/device should even know about those, as an ACK is really a network thing? I assume this part works as expected though.

  • We cannot be sure if the downlinks are really not delegated to the TTIG, as it seems the node did not receive/handle the ACKs before this problem started either. (It already kept repeating the confirmed uplink when the ACK downlinks were still shown in TTN Console before yesterday.)

In the gateway’s Overview page in TTN Console, does the counter for “Transmitted Messages” change?

Though I doubt the problem is with the TTIG, and just in case it helps others debug: what’s the TTIG’s firmware version? What did you select for the gateway’s router and the application’s handler? Likely unrelated: am I right to assume you disabled the device’s frame counter security?

@KrishnaIyerEaswaran2 can you think of anything else one can test?

If at all possible, I would try to handle regular application downlinks in your device. Maybe your LoRaWAN stack is just not handling ACKs correctly…? What LoRaWAN stack are you using? Anything that can validate that the TTIG is indeed not being told to transmit the downlink…

You are right on the problem description.

No, it doesn’t change.

I disabled the device’s frame counter security, my router is ttn-router-eu.

I am building my own module, something close (hardware wise and software wise) to the RN 2483 module.

I will look for the GW firmware version (but i have the auto update on, so it should be up to date) and add it here tomorrow.

image

My Application Data now shows the downlinks I simulated way earlier replacing the “normal” downlinks with no payload I usually see after an uplink. Is this supposed to happen?

Nothing changed in the GW traffic though, still no downlink.

Yes, that is normal. Well, except for the delay. Maybe you scheduled multiple downlinks? Then those will have been queued, and for each uplink one downlink would/should have been sent off to the gateway. TTN will then still add the ACK bit to confirm the last uplink to such application downlink.

(Aside: it’s not simulation but actual scheduling/queueing.)

I don’t have much to add @arjanvanb’s comprehensive answer.

The Data page also shows downlinks, which I assume are the ACKs. However, even though on port 0 (so: even though those are not application downlinks) I wonder if the application/device should even know about those, as an ACK is really a network thing? I assume this part works as expected though.

Yes indeed. This is Network layer only.

@Maxima: I think indeed MQTT is the best way to debug this. You don’t need to install anything locally. You can use this online MQTT client for testing MQTT Websocket Client.

The TTN MQTT broker does not support WebSockets… :slight_smile:

(The above website does not work for me when using the default non-WebSocket MQTT port 1883.)

Thanks for all your answers.

I can try any thing you think could help, but I have to confess I don’t know how to use a MQTT client. I am still trying to figure out why i do not get my downlinks, and if I must I will do what Arjan adviced me, but from my personal computer at home. This way I would not be blocked by my companie internet policy.
Anyway, I can try using the online MQTT client, but I don’t know how to use it…

Is there any way I could “reset” my gateway on TTN? I mean, I reset it manually, but TTN still show me the total of messages received, transmitted etc, even the ones before the reset, so I didn’t clean TTN’s memory about my gateway, and I have the feeling that it may help. Is that stupid?

I don’t know, but: DO NOT DELETE IT.

Aside: don’t focus too much on what you see the gateway Traffic in TTN Console. It’s just very unreliable. Like I wrote earlier: try to ensure your device is indeed not receiving the downlinks.

Did you do that when it was still using SF12? Now that you ABP device is using SF7, re-adding the device may ensure TTN has no history about the device ignoring any (possible) downlink in which TTN tried to make it use a sane data rate earlier. (Just a very wild guess, if TTN Console’s gateway Traffic page is indeed correct and TTN is really no longer delegating downlinks to that device.)

What device are you using?

I don’t think that the link @KrishnaIyerEaswaran2 posted works. Unless the TTN MQTT broker has some undocumented port that supports WebSockets… :thinking:

I guess not, but maybe the computer has, e.g., Python installed?

i have same problem, yesterday everything was working fine, today - downliks stopped working. looks like TTN network is not sending them to my gateway any more.
TTIG gateway (eui-58a0cbfffe801157)

app_data
gateway_traffic

There hasn’t been any noticeable change in traffic (UL/DL) over the last week. I suspect this has to do with reporting by the console
Screenshot 2020-07-02 at 09.09.46

@didzis / @Maxima: Can you use the gateway-data API to check if your tx/rx counters are being incremented?
https://www.thethingsnetwork.org/gateway-data/gateway/<your-gateway-id>

1 Like

for me that url does not return any data on tx/rx, just basic gateway information.
but in console Transmitted Messages parameter does not change, for my gateway it’s: 21317, after many downlink attempts it’s still 21317
p.s. Received Messages parameter increases correctly.

Ok but your devices are receiving downlinks right?