Downlink queue not clearing when messages sent

xyloidhead · August 31, 2021, 5:39am

Hi

I’m running the Chirpstack Docker installation and using it to talk to simulated devices. The simulated devices can join and send data and all appears to work as it should.

Using the gRPC interface I’m trying to send an unconfirmed message to the simulated device. The message enqueues correctly and sends when the device send data up. I can see the command is received by the simulated device. The problem is that the message is not cleared from the message queue and it is sent every time the device uploads data. I have to flush the queue to remove the message.

The same happens on the web interface on the panel where you can Enqueue downlink payload. If I don’t tick the confirmed downlink option the message will remain on the queue until manually cleared.

In this link, No downlink visible in Live Loraframes, brocaar says

Blockquote
ChirpStack will only consider a downlink as transmitted when it receives an acknowledgement from the gateway. Really old packet-forwarder versions did not send back these acknowledgements. You could validate this in the ChirpStack Gateway Bridge if any tx ack was received from the gateway.

Is there anyway to simulate the gateway acknowledgement on a docker installation? Or some other way to tell when a message has been sent.

Or have I made some other neophyte mistake?

I don’t currently have access to the hardware, it is sitting at work and I’m in covid lockdown 90 minutes away.

Thanks in advance

brocaar · September 6, 2021, 3:42pm

This is the TX_ACK packet that is expected (assuming you’re using the UDP protocol):

github.com

Lora-net/packet_forwarder/blob/master/PROTOCOL.TXT#L322


      
          That packet type is used by the server to send RF packets and associated 
          metadata that will have to be emitted by the gateway.
          
           Bytes  | Function
          :------:|---------------------------------------------------------------------
           0      | protocol version = 2
           1-2    | random token
           3      | PULL_RESP identifier 0x03
           4-end  | JSON object, starting with {, ending with }, see section 6
          
          ### 5.5. TX_ACK packet ###
          
          That packet type is used by the gateway to send a feedback to the server
          to inform if a downlink request has been accepted or rejected by the gateway.
          The datagram may optionnaly contain a JSON string to give more details on
          acknoledge. If no JSON is present (empty string), this means than no error
          occured.
          
           Bytes  | Function
          :------:|---------------------------------------------------------------------
           0      | protocol version = 2

xyloidhead · September 8, 2021, 8:31pm

I’m to new to be sure what you think I should do with this information.

I don’t have a gateway so I imagine the Chirpstack moves the message to the MQTT server where it is delivered to the simulated device. So should the simulated device be returning this packet to the MQTT server?

I’m using the simulated device from https://github.com/iegomez/lds I would have prefered to use yours but the go code was beyond my current knowledge to work out how it was operating so I could modify it to deliver the data I needed it to.