Open descartes opened 3 years ago
Hi @descartes,
Can you check if the following command does the trick:
$ ttn-lw-cli dev set $application $device --unset mac-state.pending-application-downlink
Will do - will need to setup a test device so will be a couple of days
Closing the issue, please re-open if https://github.com/TheThingsNetwork/lorawan-stack/issues/4289#issuecomment-865297441 does not solve your issue.
@neoaggelos, forum poster speeded me up, tested, all good, thanks.
I had a similar issue where an end device did not acknowledge the downlink, even though it received it. It's a COTS device, so I do not know which LoRaWAN stack they are using. But it seems like there is a bug where it does not handle confirmed downlinks.
I ended up having a confirmed downlink being sent after every single uplink.
My expectation was that if I clear the downlink queue using ttn-lw-cli device downlink clear
, or sending a new downlink from the console while choosing "replace", it will stop sending the original confirmed downlink. It did not.
Forum search later found these two comments by @descartes: https://www.thethingsnetwork.org/forum/t/how-to-clear-downlink-queue-programmatically/49212/6 https://www.thethingsnetwork.org/forum/t/abp-disable-mac-sending-of-commands/51276/26
So I did a: ttn-lw-cli device set --application-id redacted --device-id redacted --unset mac-state.pending-application-downlink
I'm waiting for the device to send another uplink to confirm this worked, but the description by other users indicate this is the cause for the problem I am seeing.
For me it does not make sense to have two commands to clear downlink messages. Shouldn't the standard downlink queue clear command also clear the mac state pending downlink?
Closing the issue, please re-open if #4289 (comment) does not solve your issue.
Please re-open. We don't have permissions to do it ourselves.
$ ttn-lw-cli dev set $application $device --unset mac-state.pending-application-downlink
I've tried this again now, and it does not seem to clear the stuck confirmed downlink message.
Hello,
We had the same issue, the following command doesn't do the job:
$ ttn-lw-cli dev set $application $device --unset mac-state.pending-application-downlink
Hello,
We had the same issue, the following command doesn't do the job:
$ ttn-lw-cli dev set $application $device --unset mac-state.pending-application-downlink
![]()
![]()
The commend that you have quoted and the command which you have ran are different - are you sure you ran the one you quoted ?
Summary
If firmware has a remote "reboot" command and the operator sends this 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