# How to purge a scheduled confirmed downlink **URL:** \ **Category:** The Things Stack v3\ **Created:** [May 4, 2022, 11:42am UTC](https://www.thethingsnetwork.org/forum/t/how-to-purge-a-scheduled-confirmed-downlink/56849 "2022-05-04T11:42:36Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![markruys](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/markruys/32/38705_2.png) [@markruys](https://www.thethingsnetwork.org/forum/u/markruys)\ **Post date:** [May 4, 2022, 11:42am UTC](https://www.thethingsnetwork.org/forum/t/how-to-purge-a-scheduled-confirmed-downlink/56849/1 "2022-05-04T11:42:36Z")
Is it possible to purge a scheduled confirmed downlink in case the device does not acknowledge the downlink? TTN will retransmit the downlink after each uplink as the device reboots before it acks. Of course the device should ack the downlink, but it doesn’t. Or we should stop using confirmed downlinks, but we do have a few devices in this (reboot) loop. How to break it? I tried `ttn-lw-cli end-devices downlink clear` _(edited)_, but that only works if the scheduled message hasn’t been tried to send to the device. I find it strange that `ttn-lw-cli end-devices downlink list` _(edited)_ doesn’t show the downlink which the device gets over and over again. ---
**Author:** ![descartes](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/descartes/32/47220_2.png) [@descartes](https://www.thethingsnetwork.org/forum/u/descartes)\ **Post date:** [May 4, 2022, 11:52am UTC](https://www.thethingsnetwork.org/forum/t/how-to-purge-a-scheduled-confirmed-downlink/56849/2 "2022-05-04T11:52:14Z")
Did you try the options in my post which you ❤ ?? > [@How to clear downlink queue programmatically?](https://www.thethingsnetwork.org/forum/t/how-to-clear-downlink-queue-programmatically/49212/6): > > Yes, general problem with sequencing, no, there is no general solution, it’s very much situational. Whilst we now have a potential 3 or so seconds to process an uplink and queue a response, this is ambitious and as we need to code for up or downlinks not arriving as expected, prone to some interesting failure modes. This possibly indicates you are thinking of downlinks as a thing. Downlinks should be treated as an exception. Everything and anything - but again, it sounds like a scheme pre… It also refers to your last statement - I’d find it odd if I typed a command to get a list of devices and got back a list of downlinks. ---
**Author:** ![markruys](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/markruys/32/38705_2.png) [@markruys](https://www.thethingsnetwork.org/forum/u/markruys)\ **Post date:** [May 4, 2022, 12:19pm UTC](https://www.thethingsnetwork.org/forum/t/how-to-purge-a-scheduled-confirmed-downlink/56849/3 "2022-05-04T12:19:38Z")
Ah, I made a typo in my post, I omitted the `downlink` keyword. You wrote: > I think I ended up resetting the MAC state after it had joined but before it had uplinked so it didn’t have a session so didn’t connect so didn’t get the downlink. Sounds a bit flaky, but I’ll give it a try. ---
**Author:** ![descartes](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/descartes/32/47220_2.png) [@descartes](https://www.thethingsnetwork.org/forum/u/descartes)\ **Post date:** [May 4, 2022, 2:29pm UTC](https://www.thethingsnetwork.org/forum/t/how-to-purge-a-scheduled-confirmed-downlink/56849/4 "2022-05-04T14:29:06Z")
> [@markruys](#): > > Sounds a bit flaky, but I’ll give it a try. Really? Flakey how so, it resets the device. Bit brutal but as at the time I was clearing a reboot command that would always lead to a rejoin, clearing the MAC state wasn’t an issue. And that would have been part of me figuring out the solution, the correct solution being provided in the quoted CLI command if you just need to clear the queue and want to leave the device online. ---
**Author:** ![markruys](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/markruys/32/38705_2.png) [@markruys](https://www.thethingsnetwork.org/forum/u/markruys)\ **Post date:** [May 5, 2022, 1:49pm UTC](https://www.thethingsnetwork.org/forum/t/how-to-purge-a-scheduled-confirmed-downlink/56849/5 "2022-05-05T13:49:07Z")
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 list` returns 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](https://www.thethingsnetwork.org/forum/t/how-to-clear-downlink-queue-programmatically/49212/4)), although I could not find posts explaining why. ---
**Author:** ![Jeff-UK](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/jeff-uk/32/35697_2.png) [@Jeff-UK](https://www.thethingsnetwork.org/forum/u/Jeff-UK)\ **Post date:** [May 5, 2022, 3:04pm UTC](https://www.thethingsnetwork.org/forum/t/how-to-purge-a-scheduled-confirmed-downlink/56849/6 "2022-05-05T15:04:39Z")
> [@markruys](#): > > using confirmed downlinks is considered bad practice > [@markruys](#): > > find posts explaining why Simples…every time a GW transmits your or another users downlink it goes deaf to ALL other users uplinks for the duration. As you have seen using confirmed downlinks if something goes wrong it may just keep trying…vastly exacerbating the problem and potentially perpetuating it until cleared. Also, as a Radiator itself, in many parts of the world the GW’s also have a TX duty cycle limit, which if reached will remove key GW functionaity until channels ‘free’ again - stopping other devices receiving e.g. Join info, ADR updates etc…Obvious really! For this reason there is a downlink limit (confirmed or otherwise) of 10 DL/day/device, including e.g. Join Accepts, system generated MAC commands, etc., though a simple search and read of the forum will tell you we consider that to be extreme use on the Community network…think more like 10 per week, maybe even 10 per month! If your application is dependent on frequent DLs (or the other potential sin of regular confirmed uplinks - that then trigger a corresponding downlink!) the Community network may not be the best place for you - consider a self hosted, TTI hosted, or enterprise instance of TTS so you can work ‘privately’, without impacting other TTN users… ---
**Author:** ![kersing](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/kersing/32/44777_2.png) [@kersing](https://www.thethingsnetwork.org/forum/u/kersing)\ **Post date:** [May 5, 2022, 6:12pm UTC](https://www.thethingsnetwork.org/forum/t/how-to-purge-a-scheduled-confirmed-downlink/56849/7 "2022-05-05T18:12:03Z")
> [@markruys](#): > > although I could not find posts explaining why. There are a number of discussions where this is explained, in short: Confirmed downlinks depend on all uplinks to get through. If the uplink with the ack is missed there will be another downlink with whatever data was sent before. Now your embedded device needs to deduplicate those downlinks or process the same information twice. Then there is the issue you encountered where the downlink causes the device to reset (the stack or all of it doesn’t matter) so no ack will ever be arriving. You are stuck in a loop… The best way to handle downlink acknowledgment is at application level. When a downlink is received and handled update a field that will be in all your uplinks so even if a couple of uplinks are missed your application still knows the device got its instructions and processed them. ---
**Author:** ![jpmeijers](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/jpmeijers/32/44875_2.png) [@jpmeijers](https://www.thethingsnetwork.org/forum/u/jpmeijers)\ **Post date:** [August 19, 2022, 10:07am UTC](https://www.thethingsnetwork.org/forum/t/how-to-purge-a-scheduled-confirmed-downlink/56849/8 "2022-08-19T10:07:44Z")
Just leaving this here, as it will help find the correct command: > [@ABP: Disable mac sending of commands](https://www.thethingsnetwork.org/forum/t/abp-disable-mac-sending-of-commands/51276/26): > > The magic flush command is: ttn-lw-cli dev set $application $device --unset mac-state.pending-application-downlink > > > \#### Summary > If firmware has a remote "reboot" command and the operator sends t…his as a confirmed downlink, both the device & stack end up in a perpetual loop as the downlink doesn't get ack'd so the stack resends the downlink, repeat ... > > \#### Why do we need this? > So when an operator fails to follow instructions, we can get them out of the mess > > \#### What is already there? What do you see now? > I tried adding a downlink to the queue with replace - didn't clear the expected ack, wasn't really expecting it to. > I tried a reset with --mac-state.pending-application-downlink but that didn't do what we needed > I tried resetting the MAC state but that means the join session was lost & we had to wait for the device to realise it was offline. > > \#### What is missing? What do you want to see? > CLI option to flush the entire downlink state > > This may exist but I can't see which field is the way to go > > > \#### Environment > TTS CE > > \#### How do you propose to implement this? > Sorry, above my pay grade > > \#### How do you propose to test this? > Once it's implemented > > \#### Can you do this yourself and submit a Pull Request? > No