We’re currently testing downlink commands functionality of our device using the latest Chirpstack servers.
Particularly with multiple downlinks waiting in the network server queue to send.
Under some circumstances it seems that although downlinks frames are correctly being sent from the network server queue in response to an uplink (we can see them being processed), one downlink remains showing in the queue on the application server web console, which then disappears at the next uplink (although no downlink frame is actually sent).
So it appears that the network server isn’t always clearing queue entries in the application server gui.
Assuming that we’ve correctly understood the relationship.
Just to clarify a typical scenario. 3 downlink messages are waiting in the queue, the next uplink frame (sensor data) causes one downlink frame to be received. This frame contains a command that generates an application layer reply (requested parameter information) uplink frame, which causes the next downlink to be sent and received. Following that an empty message is sent when there is no application data waiting to go, due to the frame pending bit being set on the last downlink frame. However although the last downlink was sent it remains showing in the application server console. The next (sensor data) uplink clears the console but no downlink is sent, as might be expected if the downlink indicated in the console as waiting is a ghost.
Something similar occurs when there are more than 3 messages in the downlink queue, with a single “ghost” message remaining.