How to avoid unwanted down link with null port and null frm_payload ?
Some of my sensor receive unconfirmedDataDown with port value as null, and frm_payload value as null too without I send something. I would like to know why, understand if I have done something wrong and how to control this if it's possible.Here are two examples of different sensors brought up by different gateways.
Unsolicited downlinks
Viewed 52
1 Answers
The first / left downlink contains a mac-command to re-synchronize the channel configuration. Normally within EU868 these channels are sent as part of the CFList in the join-accept, but if a device sends an uplink with adr_ack_req: true, ChirpStack will re-negotate these channels with the device.
THe second / right downlink contains an ack: true, most likely because the preceeding uplink was a confirmed uplink, and thus must be acknowledged by ChirpStack.
Related
fPort missing in Javascript Codec in encodeDownlink input (v5.14 to v5.15)
1 answers
Gateway not connecting to ChirpStack
1 answers
Issue running gateway-bridge in AWS with application load balancer and wss
2 answers
How to use SQLite with chirpstack-sqlite docker image?
Gateway Mesh / Rx delay configuration
1 answers
AU915 LoRaWAN OTAA: JoinAccept “sent/scheduled” by gateway but 50% of devices never join (stuck in a JoinRequest loop)
2 answers
Could you please edit your question and add a screenshot one of the unsolicited downlinks? Easiest would be taking a screenshot of one of the UnconfirmedDownlink in the LoRaWAN frames tab of the device.