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.
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.)
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.
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.
My GW suddenly started showing downlinks again, without any obvious reason. It seemed quite slow to boot when I plugged it on today, maybe because of an update occuring? I really don’t know, but my project is now working like a charm (even if I have a terrible RSSI, as if my antenna wasn’t connected, but that’s another problem I’m on my way to solve!)
Anyway, thanks for the help, everything is now working as intended, even if I did not change anything hardware nor software wise.
