I’ve done some tests with confirmed downlinks which are not being acked by the device (for whatever reason).
- When you schedule a confirmed downlink it will show up when you run a
ttn-lw-cli end-devices downlink list. - When the device transmits an uplink, the downlink is sent to the device, and the
ttn-lw-cli end-devices downlink listreturns an empty list. This is also the case if the device did not acknowledge the downlink (!) - TTN will retransmit the confirmed downlink in reply of each device uplink, as long as the device doesn’t ack.
- When a device rejoins, TTN keeps retransmitting these downlinks (!)
- When you schedule a new downlink, even with
ttn-lw-cli end-devices downlink replace, the pending downlink is not removed and will be retransmitted again (!)
The only way to get rid of this confirmed non-acked downlink, is to either:
- let the device ack the downlink (duhhh)
- issue a
ttn-lw-cli end-devices reset
In the later case the device must detect the session vanished and must rejoin. I was hoping that we could flush such a downlink without loosing the network session at TTN.
@kersing wrote that using confirmed downlinks is considered bad practice (How to clear downlink queue programmatically? - #4 by kersing), although I could not find posts explaining why.