When I send a enqueue downlink message ( base64 encoded) form the LNS to my device, I am not receiving the message in my sensor. But When I tested using another LNS , I can see the downlink message in my sensor. The only difference I am seeing here is the other LNS is sending the message in HEX and chirpstack is sending as base64 encoded. Should I need to add some encode codecs under my device profile ? please assist how can I solve this issue, Thanks in advance
Not sure if its relevant but I had a similar issue and it turned out to be the encoding.
For example if I send “1” in the send a message box in the application server it encodes it in base64
When that “1” arrives it actually arrives at the lora sensor as the ascii set number which coincidentally is 49, 2 is 50, 3 is 51 etc. I fully expected it to send the integer “1” and not the ascii reference number… threw me for a bit I’m still not sure why that is but I suspect its because the box in application server is meant for sending strings as opposed to hex and thats why its using base64. If ur code is relying on a 1 or 0 as mine did then this could throw u a bit.
Thanks for the reply bro, ya my scenario is something similar to your case but the problem I am facing here is I am not receiving the downlink payload at all in any format. But I can receive in other LNS. That’s why I am quiet confused and strucked… plesae do share if you know the reason for such cases
Did you track the logs to see where your downlink message arrives to?
- Mqtt downlink topic
- Gateway Bridge log
- Gateway Lora Packet Forwarder.
Ya, I can see the downlink message coming upto the gateway when I check the gateway logs…but it’s not reaching the end node. When I used the other LNS, I can see the same logs in the gateway but the downlink message can be seen at my end node. Please assist if you have any idea to fix this !!
In that case it would be very useful to see the both logs in the gateway, the one from ChirpStack and the other one, in order to compare and see what information is arriving.
Thanks for the advice, we managed to solve this issue by adjusting the firmware of the device to accept base64. If chirpstack supports both HEX and base64 directly it would be helpful as most of the end devices are supporting HEX. If there is any other easy way to solve this data format issues, please do share !! Cheers !!
You should be receiving the data as bytes. Perhaps you are double-encoding the downlink by mistake?
What @bconway says is just what I was thinking about.
I guess that the device is transparent to the format that the Network Server sends the messages.
I guess the Network Server can communicate with the Gateway Bridge in Base64 but when it is “translated” to the LoRa Packet Forwarder and this one communicates with the end device, it doesn’t depend on the format HEX or Base64.
If it is like that, the sensor should know which is the format that the Network Server “understand” and would send the payload depending on that, but actually it is not like that.
I think that this workaround makes no sense.