Schedule downlink payload

This is the response that we are fetching when we achieve in a downlink . As mentioned it comes with the status 200 with an empty result set also.


Although we are trying to check a confirmation from the gateway side,Could you please tell us the right approach for this .

{
{
{
“id”=“1”,
“devEUI”="…"
“pending” = “false”


}
}
}
What does the pending parameter in the JSON body of api https://localhost:8080/api/nodes/[MAC]/queue mean??

The 200 status means that the payload has been added to the queue. It will stay there until a receive-window occurs. For Class-A devices a receive-window occurs after an uplink transmission (thus your node needs to send data before the network can send data to your node). For Class-C devices the data will be transmitted directly.

When sending confirmed data, the payloads gets pending: true when it has been transmitted, but the system is waiting for an acknowledgement from the node. Please refer to the LoRaWAN specification for more details on how this works.

Could I get some help with a problem with how downlinks work? When i queue a downlink using mosquitto_pub, the downlink is broadcast immediately instead of waiting for an uplink and then replying in the RX1 slot. Is there a configuration setting that causes this behaviour?
Does loraserver know when the node is in Class A or Class C?
Thank you

You define the type of device at the device-profile configuration.

Thanks for the suggestion.
I find that only allowing Class A causes the downlinks to be timed corectly for the RX1 slot just fine. When enabling Class C in the device-profile, “immediate” downlinks are sent as soon as the server can manage.