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?
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.
explanations of what?
we are don’t know what is your node, what are you trying to send.
is your endnode joined to the ChirpStack ? Is your endnode sends any data from itself?
Are you read endnode manual which format of downlinks it recognizes?
P.S. I suppose you need to start new topic b-cos your issue is not related to this topic.
my end node sends voltage and current to the chirpstack server, then when i enque a downlink i can see it on my webserver and also on the gateway log as being transmitted on 869.525MHz. but it does not get to my device. why is this so