Problem with sending downlink via MQTT

Hello,

I have loraserver up an running (GW bridge, loraserver and lora appserver on one physical host). I can see Uplink and downlink in appserver GUI - all looks working fine.

I need to send downlink manually via mosquitto_pub command.
I found several threads already on similar topics, but I think my issue is simpler, I’m missing something.

https://forum.loraserver.io/t/sending-data-to-lora-node-with-mqtt/1196/9
https://github.com/brocaar/lora-app-server/issues/73.

I am publishing as:

mosquitto_pub -t “application/1/#” -m “hello world” -u {loraserver mqtt username} -P {loraserver mqtt pwd}

also tried particular node:

mosquitto_pub -t “application/1/device/333934376c356214/tx” -u {loraserver mqtt username} -P {loraserver mqtt pwd}

publish output:

Client mosqpub/25000-vps590769 sending CONNECT
Client mosqpub/25000-vps590769 received CONNACK
Client mosqpub/25000-vps590769 sending PUBLISH (d0, q0, r1, m1, ‘application/1/device/333934376c356214/tx’, … (2 bytes))
Client mosqpub/25000-vps590769 sending DISCONNECT

and then listening on:

mosquitto_sub -v -t “application/+/device/+/+” -u {loraserver mqtt username} -P {loraserver mqtt pwd} --debug

subscribe output below, but nothing else.

Client mosqsub/29322-vps590769 sending CONNECT
Client mosqsub/29322-vps590769 received CONNACK
Client mosqsub/29322-vps590769 sending SUBSCRIBE (Mid: 1, Topic: application/1/#, QoS: 0)
Client mosqsub/29322-vps590769 received SUBACK

I’m watching the journalctl in paralel for Bridge, loraserver and lora app server, but all I see is the normal messages sent by the node uplink/downlink.

mosquitto client seems to work fine also, as I can subscribe for the gateway topics and I can see the packets arriving from the node.

mosquitto_sub -t “gateway/#” -v -u {loraserver mqtt username} -P {loraserver mqtt pwd}

I would appreciate if anyone can point at the problem, I can send the logs is necessary.

thanks in advance,
Sergi

Gents, no one? I would appreciate some hints

Are you subscribing prior to publishing? Your message says “and then”, which implies you publish and then connect to subscribe.

Thanks bconway,
No, actually I am subscribing first and then trying publishing…

Hi Guys,

I’m sorry i am limited to send you an unique picture but i would like to explain my problem as best possible. You can click and zoom the picture.

Thanks for you help

Adrien

When i try with the following file :

Capture8

I get the frame in the Live Device Data Topic but it’s an error.

I get the error : “value must be an array”

There is the same error indicated in the lora-app-server logs.

My JSON File seems OK so is there any bug in parsing Json Data into lora-app-server application ?

I have the 2.6.0 version.

Thank you guys.

Example:

mosquitto_pub -t "application/1/device/0101010101010101/tx" -f /tmp/test.json

The content of /tmp/test.json is:

{
    "confirmed": true,
    "fPort": 10,
    "data": "AQID"
}

(AQID == 010203 in HEX encoding).

2 Likes

Hi Brocaar,

Thank’s for your help !

I tried your json example but i always receive no data on my RN2483.
All my settings for RX1 and RX2 seems to be good.
I receive an ack packet on the live device data view from my RN2483 :


I begin to suspect my gateway, which is a Dragino LG01 with only 1 channel. It can work with this hardware (LG01)? On my RN2483, i set only one channel 861000000 which is the used by LG01, the uplinks are ok.

Thank’s

I don’t have experience with single-channel gateways, but I know many people run into issues with these kind of gateways. Why not buy one of the available SX1301 based Raspberry Pi shields? That might save yourself some trouble :slight_smile:

1 Like

Thanks for the example brocaar. My gateway is not with me at the moment, will try that soon

a quick test meanwhile:

running below on loraserver. subscribing to application topic (tried also particular application/node like "
“application/1/device/0101010101010101/tx”). subscribed ok:

root@vps:~# mosquitto_sub -t “application” -v -u “loraserver_as” -P “********” --debug
Client mosqsub/31026-vps590769 sending CONNECT
Client mosqsub/31026-vps590769 received CONNACK
Client mosqsub/31026-vps590769 sending SUBSCRIBE (Mid: 1, Topic: application, QoS: 0)
Client mosqsub/31026-vps590769 received SUBACK
Subscribed (mid: 1): 0
Client mosqsub/31026-vps590769 sending PINGREQ
Client mosqsub/31026-vps590769 received PINGRESP

Then publishing on same level. contents of mqtt file is same as in your previous post. Do not see any warnings while publishing. But I don’t get anything in subscription (separate terminal window)

root@vps:/home/lora# mosquitto_pub -t “application” -f mqtt.json -u “loraserver_as” -P “********” --debug
Client mosqpub/31027-vps590769 sending CONNECT
Client mosqpub/31027-vps590769 received CONNACK
Client mosqpub/31027-vps590769 sending PUBLISH (d0, q0, r0, m1, ‘application’, … (66 bytes))
Client mosqpub/31027-vps590769 sending DISCONNECT

thanks

Hello everyone,

Short update on my initial topic, I did a clean install of all Lora modules from scratch and now it is working fine.

I am publishing a json file (mentioned in this thread earlier, thx for the example btw) to application topic. content of the file are:

{
“confirmed”: true,
“fPort”: 10,
“data”: “AQID”
}

Publish command

lora@vps:~$ mosquitto_pub -t “application” -f mqtt.json --debug
Client mosqpub/18036-vps sending CONNECT
Client mosqpub/18036-vps received CONNACK
Client mosqpub/18036-vps sending PUBLISH (d0, q0, r0, m1, ‘application’, … (66 bytes))
Client mosqpub/18036-vps sending DISCONNECT
lora@vps:~$

Topic subscription.

Lora@vps:~$ mosquitto_sub -t “application” -v --debug
Client mosqsub/18028-vps sending CONNECT
Client mosqsub/18028-vps received CONNACK
Client mosqsub/18028-vps sending SUBSCRIBE (Mid: 1, Topic: application, QoS: 0)
Client mosqsub/18028-vps received SUBACK
Subscribed (mid: 1): 0
Client mosqsub/18028-vps received PUBLISH (d0, q0, r0, m0, ‘application’, … (66 bytes))
application {
“confirmed”: true,
“fPort”: 10,
“data”: “AQID”
}
Client mosqsub/18028-vps sending PINGREQ
Client mosqsub/18028-vps received PINGRESP

Looks there was something brokeნ during my config tuning.
thanks all for your responses.

Hi everyone
I am trying to send downlinks to a class C node. Are there other fields needed in the json file to do this?
Thanks

No, you are “just” scheduling a downlink. It is up to LoRa Server to decide if Class-A / B or C is used for the actual transmission.

Hello,
I am sending the downlink to my node using

mosquitto_pub -t "application/3/device/1234567891234567/tx" -f /etc/lora-app-server/test.json

and the following is content of test.json file:

{
    "confirmed": false,
    "fPort": 2,
    "data": "QW1hemluZyBMb3JhQXBwU2VydmVy"
}

I see the downlink data in Lora-App-Server under Applications / AppName / Devices / DeviceName / Lorawan Frames. But I don’t see the same under Device Data. Should it not be there? since the data is sent to that node? And also under Lorawan Frames - the data under "frmPayload: 1 item bytes: “dj2swnNZE1wHJXIhIYHRhteg5SPi” - this data looks different than what was transmitted, should it not be same as in the json file? I am confused, can someone please help me…

Thanks

Can anyone help me out please?
Thanks

1 Like

Hi,

Try below format cmd…
mosquitto_pub -h localhost -p 1883 -t “application/1/device/a840410001818901/rx” -m {}

e.g.
mosquitto_pub -h localhost -p 1883 -t “application/1/device/a840410001818901/rx” -m ‘{“applicationID”: “x”, “applicationName”: “xxxx”, “deviceName”: “xxxx”, “devEUI”: “xxxx”, “adr”: true, “fCnt”: 0, “fPort”: 2, “object”: { “BatV”: 2.00, “State”: “xx”, “TempC”: “22.16” },“tags”: {“docID”: “xxx” }}’

2 Likes

Did you try it? Does it works?

I followed this instruction and it worked for me. The only difference for me was that my MQTT broker was running in the gateway and my mosquitto_pub command was given from my laptop. So, I ran the following command and it worked for me. In my case it was turning a motor ON/OFF which was connected to a lorawan end device. The command I ran is:
mosquitto_pub -h 192.168.0.105 -t “application/1/device/0101010101010101/tx” -f /tmp/test.json

EDIT: FIXED. Absolutely unbelievable! The ENTIRE problem was caused by copying the example JSON text from the web page, which has double-quotes that LOOK like “real” double-quotes (ASCII 0x22), but are in fact 0x9c. You would think that using pre-formatted text in MarkUp means “Use the text I typed”, not “Replace some characters with something that looks the same but is not”.

Running into this same problem here. Chirpstack is running in a container on port 11883. I subscribe to the MQTT server, and the device sends a message, and we see the message.

$ mosquitto_sub -h localhost -p 11883 -t 'application/+/device/+/rx'
application/1/device/e00227005046162e/rx {"applicationID":"1","applicationName":"thing-handler","deviceName":"thing-1","devEUI":"e00227005046162e","rxInfo":[{"gatewayID":"00800000a0005872","uplinkID":"333a511e-2237-4f20-aaeb-191e330cf90d","name":"Multitech-MTCDT-L4N1-247A","time":"2020-02-23T19:11:04.436671Z","rssi":-50,"loRaSNR":9.2,"location":{"latitude":34.19129,"longitude":-83.94138,"altitude":374}}],"txInfo":{"frequency":903300000,"dr":3},"adr":true,"fCnt":3,"fPort":9,"data":"oAAc"}

So following the above, to send data to the device, I should do:

mosquitto_pub \
-d \
-h localhost \
-p 11883 \
-t “application/1/device/e00227005046162e/tx” \
-m '{ “confirmed”: true, “fPort”: 3, “data”: “AAAACg==” }'

And we see this:

Client mosq-HgJc53NKVySjJucfic sending CONNECT
Client mosq-HgJc53NKVySjJucfic received CONNACK (0)
Client mosq-HgJc53NKVySjJucfic sending PUBLISH (d0, q0, r0, m1, '“application/1/device/e00227005046162e/tx”', ... (69 bytes))
Client mosq-HgJc53NKVySjJucfic sending DISCONNECT

But I never see the data get queued or sent. If I send the same string to the same port via the web UI, it works fine. So what am I doing wrong when I use mosquitto_pub? I have tried putting the JSON string in a file and using the -f option, but that made no difference.

If I subscribe to the topic with mosquitto_sub -p 11883 -t '#' -v, I see

application/1/device/e00227005046162e/tx {“confirmed”:true,“fPort”:3,“data”:“AAAACg==”}

returned by mosquito_sub

Also, where does the 1 in the application/1/device/e00227005046162e/tx string come from? I presume it’s the applicationID we see in the received string, based on a sample of one.