Thingsboard PE downlink integration to Chirpstack V4 failed

Today we made integration on thingsboard PE (V3.3.2 and V3.4.1) with Chirpstack V4 by http integration as the document said ChirpStack Integration | ThingsBoard Professional Edition. Uplink works well, but downlink can not work.

  1. The thingsboard PE integration sendout below data.
    “metadata”: {
    “fPort”: “3”,
    “DevEUI”: “7cf95720fc015fef”
    “payload”: “ODAwMQ==”

  2. From the chirpstack log, we found that info like below. It seems that the thingsboard PE already post to Chirpstack successfully. But no action on the queue tab of Chirpstack. Neither the node get the downlink data.
    ^[[35mchirpstack_1 |^[[0m ^[[2mSep 24 07:22:14.818^[[0m ^[[32m INFO^[[0m ^[[1mgRPC^[[0m^[[1m{^[[0muri=/api/devices/7cf95720fc015fef/queue^[[1m}^[[0m: chirpstack::api: Finished processing request status=“200” latency=36.39μs

  3. In Feb 2022, we tested with the Chirpstack V3 and the Thingsboard PE V3.3.2, it works well for the downlink. Keeps the rule chain /integration/convertor no change, the thingsboard PE can not trigger the Chirpstack V4. Even we update the thingsboard PE to 3.4.1, it still does not work.
    Is there any change for the interface between thingsboard/chirpstack V4?

The format of all payloads are changed in V4.

Thanks Datnus,
Can you give me some example of the downlink for V4? Or link about the description?

Thanks for your response!
After checking the document and capture the packet, we found that Thingsboard did not send the ispending,fCntDown fields, maybe this is the problem. Will simulate it to verify!

@Justin did you manage to get this working?

Unfortunately I did not make it work

i need to do a proper bug report on why integration+downlink converter doesn’t work for V4, but I am short on time, instead I will post here a method to do this for both TB CE and TB PE.

short: setup a rule chain to handle the downlink mqtt post to CS V4.

  • listen to attribute update (I use a widget that update attribute to trigger manual payload)
  • use the MQTT node in the rulechain
  • use a script to format the expected CS V4 payload
  • dynamically populate the devEUI in the MQTT Topic
  • dynamically populate app ID in the MQTT topic (can set application ID as attribute on the triggering device and dynamically populate app id in the topic)
    ** I am using static app id in this post


here is the mqtt node setup, i am using static APP ID for now and dynamic devEUI

here is the script node setup:

var msg = 
    "devEui": msg.deviceid.toLowerCase(),             
    "confirmed": true,                       
    "fPort": 6,                              
    "data": btoa(msg.payload),


return {msg: msg, metadata: metadata, msgType: msgType};

and final result in CS V4

1 Like

Great idea! I will try on our server! Thanks for your great support!!! :+1:

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.