I successfully created a poll task using the AT command. The device started polling as expected based on the configuration (non-transparent mode), and it transmitted the uplink correctly.
However, when we attempted to add the same polling task remotely using a DTU command via a downlink (topic: application/<appID>/device/<devEUI>/command/down, payload:
), the RAK7431 received the downlink message successfully (SYSLOG:4:LoRa Rx : [14] 030001000901010300000002C40B - 2), but no further action was observed:
The poll task did not execute
No uplink was transmitted
The task was not listed in the poll task list
Request:
Can anyone explain what the issue might be? Is there anything wrong with the DTU command format or process?
Thanks for your detailed description and test result. Here’s a breakdown and analysis of the issue you encountered when trying to add a polling task to the RAK7431 via LoRaWAN downlink:
Summary of Your Situation:
Device firmware: 1.1.0069_Release
LNS: ChirpStack v4
Polling task via AT command: Works correctly
Polling task via LoRaWAN downlink (fPort 129):
The RAK7431 receives the downlink (SYSLOG confirms it), but:
Task does not appear in the poll list (AT+POLLTASK)
No uplink is generated
No polling is performed
DTU Command Decoded:
Your data base64 payload:
AwABAAkBAQMAAAACxAs=
After base64 decoding:
03 00 01 00 09 01 01 03 00 00 00 02 C4 0B
Breakdown:
Field Value Meaning
03 CMD Add Polling Task
00 01 MSER Sequence ID
00 09 Length 9 bytes of MDATA
01 TASK_ID Task ID = 1
01 03 00 00 00 02 C4 0B DATA Task configuration payload
Analysis – Why It Didn’t Work via LoRaWAN:
Based on our internal knowledge of the RAK7431 firmware and DTU logic:
1.TASK_ID conflict: already exists
You already created a polling task with TASK_ID = 01 via AT command.
When the same TASK_ID is reused via DTU downlink, the RAK7431 will silently reject it if the ID already exists and the device does not allow overwrite by default.
Recommendation:
To confirm this, please try one of the following:
1.Option A – Use a new TASK_ID
Send the same payload with a different TASK_ID, e.g., 02. Example payload:
2.Option B – Manually delete the old polling task
If the device supports deleting polling tasks, you can remove the existing TASK_ID = 01 before re-sending.
Final Notes:
The DTU format and base64 encoding are correct.
The issue is most likely due to duplicate task ID rejection silently.
Please test with a different TASK_ID and confirm whether the polling starts.
If the operation is correct, you should receive the following log：
Thank you for your prompt response on this matter.
I have reviewed the current polling task configuration on the device, and I can confirm that Poll Task IDs 3 and 4 are active and functioning as expected. However, ID 1 appears to be empty and has not been assigned any task.
Thank you for the follow-up and for sharing the screenshot of the current polling task list and the downlink message.
After reviewing the information, we would like to confirm a few key aspects to help isolate the issue:
Observations:
According to your screenshot, Poll Task ID 1 is currently empty, which indicates that the task was not successfully created.
The downlink message format looks correct in terms of structure and payload.
However, based on the logs from the RAK7431, it seems that the downlink command was not recognized or parsed correctly by the device, since no task was added, no uplink was generated, and no error message was returned.
To proceed, could you kindly help us confirm the following three points:
Is the downlink message being sent to fPort 129?
This is required for DTU command parsing. If it’s sent to a different port, the device may ignore it.
What LoRaWAN class is the RAK7431 currently operating in?
DTU commands require the device to be in Class C mode to receive downlinks at any time.
If it is currently operating in Class A, the downlink must arrive precisely after an uplink within the RX window. Otherwise, it will not be received.
What is the device’s transparent mode status?
Please run the following AT command on the RAK7431 and share the output:
AT+TRANSPARENT
It must return false for DTU commands to be recognized and acted upon.
From the current analysis, all your steps seem to be valid. However, the key difference is that upon receiving the downlink, the RAK7431 does not show any response or action, which is not expected behavior.
To further isolate the issue, we kindly suggest trying the following:
Send the same command via the ChirpStack Web UI
Please navigate to the device page in the ChirpStack UI.
Use the “Send command” or “Downlink**” feature.
Set fPort to 129 and use the same HEX.
Submit the downlink and monitor the device log for any response.
Works correctly
