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… 
(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… 
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)
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
@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>
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?
no, that’s the main problem. i can’t send commands to irrigation station because of this.
update: i restarted station side electronics, and magically - downlinks are working again. not critical to me, but they do not show up in the gateway traffic, even Transmitted Messages counter stays frozen.
and confirmed ack empty message comes from my gateway
If TTN was using lower downlink counters than the last downlink counter known to your device, then your device would have silently dropped those downlinks. Did you ever explicitly reset the counters in TTN Console, without resetting your device? That would cause this problem for both OTAA and ABP, like its confirmation dialog explains.
But for ABP devices TTN Console may also unexpectedly reset its counters: making any change in the ABP settings (even just changing its description) will erroneously reset its counters.
If the counters were reset on TTN but not on the device, then resetting the device today will have reset the counters on that device as well, hence making it accept low downlink counters again. (An OTAA device will then re-join, and reset all state in TTN. Good. For ABP I assume you also have the frame counter checks disabled, for otherwise resetting the device would have made TTN start rejecting the device’s low uplink counters.)
Aside: for the LoRaWAN protocol a device is not required to send an empty uplink for an ACK after receiving a confirmed downlink; it can postpone such ACK until its next regular uplink, even if such is days or weeks later. Of course, your use case may have different needs. (If I understand correctly that the 12 bytes 20:30:10 uplink is such ACK for an earlier downlink. Actually, I don’t understand what the 20:30:08 ACK is.)
Also, it seems you’re sending a lot.
Of course, all of the above does not explain why the uplinks are shown just fine, but downlinks are not visible in TTN Console’s gateway Traffic page anymore. Or why neither the transmitted nor received counters are increased.
@Maxima, any luck in checking if your device (or another device using that gateway) receives the downlinks, despite TTN Console not showing them?
The Magic did not last for long, downlinks are down again, restarts do not help this time either.
I use OTAA / frame counter is disabled. Empty message comes from ESP32/LMIC (LMIC_setLinkCheckMode(0); LMIC_disableTracking(); LMIC_setAdrMode(1)) I guess, that’s by default then, right after ‘confirmed ack’. ACK in my screenshot, was just example of successful / confirmed downlink, with my gateway id and superb RSSI. I’m clueless, what to do now. Have to get rid of that TTIG. and get gateway with options to check logs and change configuration.
Aside:
(More details in that post.)
For OTAA, disabling frame counters is not needed. (But won’t cause the problems you’re seeing either.)
Beware: to avoid crosstalk, don’t be too close to the gateway!
thank you, I’ll try out that UART port.
yes, devices should be at least 4x Lambda apart. in my case distance to the station is about 180m.
Also, ttnctl gateway status <gateway id> may show some details. (That status is not listed on https://www.thethingsnetwork.org/docs/network/cli/)
i found no use for ttnctl. but from UART I got at least a clue.
2020-07-05 09:35:29.180 [S2E:VERB] RX 867.5MHz DR2 SF10/BW125 snr=7.0 rssi=-73 xtime=0x2E0000066761C4 - updf mhdr=40 DevAddr=26012DC3 FCtrl=80 FCnt=729 FOpts= 0128E85D…266F mic=1335538791 (44 bytes)
2020-07-05 09:35:29.715 [SYS:DEBU] Free Heap: 18720 (min=16928) wifi=5 mh=7 cups=8 tc=4
2020-07-05 09:35:30.450 [S2E:DEBU] ::0 diid=28568 [ant#0] - next TX start ahead by 707ms471us
2020-07-05 09:35:30.718 [SYS:DEBU] Free Heap: 18720 (min=16928) wifi=5 mh=7 cups=8 tc=4
2020-07-05 09:35:31.148 [S2E:VERB] ::0 diid=28568 [ant#0] - starting TX in 19ms849us
2020-07-05 09:35:31.163 [S2E:INFO] TX ::0 diid=28568 [ant#0] - dntxed: 869.525MHz 27.0dBm ant#0(0) DR3 SF9/BW125 frame=A0C32D01268577020355FF00…DFDDEA94
2020-07-05 09:35:31.323 [S2E:DEBU] Tx done diid=28568
that TX started 1983ms, ended 2143ms after RX. LMIC default Downlink windows are 1+1 sec, I think. I’ll try to widen those. to see what happens.
Sorry for my silence, I’m quite busy right now but I’m still checking this topic from time to time.
Unfortunately no, I only have my own devices that I didn’t manage to make work properly for downlinks before the strange behaviour happened, so I cannot be sure that the fact my device is not receiving messages is coming from the gateway and not from a bad configuration of my device.
Looks like, I found the root of my downlink problems. The station uses ESP32 LoRa module. Before data transmission, a function to read sensor data is called, it contained delay() functions to give some inputs time to stabilize, well… it must be stupid idea to use delay() function in such place and time, looks like it messes up LoRa timings as it freezes CPU and parallel tasks are affected. I removed delay’s and at this time downlinks are working flawlessly, there are still some problems with OTAA Join process, as there are still some delay functions to replace. I’ll test it for few more days to be sure. but Yea - don’t use delay functions in your LoRa projects, as I did. Replace them with some millis / yield loops instead.