Hi,
I have a problem with the downlink queue. I have configured the ChirpStack network server in the way that the message interchange between my device and the IoT platform is atomic. That means that the uplink is always replied with the proper downlink, that is processed by the device. The problem is that sometimes and due to random problems (i.e. a transmission delay in the network or a delay in the IoT platform) the device closes the recieve window without any response and then, the (delayed) downlink is retained in the ChirpStack device downlink queue. In the next communication, the request uplink is followed by the (previously) enqueued downlink, that is not the one that the device is waiting for processing… and so on. The solution to this problem is to manually flush the queue through the ChirpStack API but this is not always possible. So, the question is if there exist any javascript code to program into the ChirpStack device encoder in order to programmatically flush the queue.
Thanks in advance!
So, the question is if there exist any javascript code to program into the ChirpStack device encoder in order to programmatically flush the queue.
This does not exist. While I do understand your use-case, I don’t think the codec function should be the place to implement this.
Hi @brocaar , I have the same problem described here.
In mi case I have class C actuators that wait for commands from the application. The problem is that for example after some power outage where the gateways were offline for some time and in that time the application sent downlink commands, after power recovery and gateways reconnection the actuator will receive all the queued messages. This behaviour is not desirable because at the recovery time they are old messages and not relevant anymore.
Is this feature already implemented?
If not the a proposal could be something like this:
Can a feature be implemented were we can configure a TIMEOUT parameter for downlink messages? In this way if the queued message was not able to be transmitted after X time then the network server flush it from the queue.
@pabmitor have you working around this in some way?
Thanks!