As I mentioned in another thread, I’m very much a newbie, and I’m in over my head! Right now all I’m trying to do is get information from my device through a gateway, through ChirpStack, and into a REST service (using an HTTP integration). This much is all working. However, the REST service is receiving an encrypted (or maybe just encoded) payload. I get the impression that ChirpStack should be able to decode that payload before passing it to the REST service, but I have no idea how.
There are plenty of posts here about this topic, but they all seem to assume a lot more knowledge than I have. For example, I understand there’s a great “package” for doing what I think I need to do, found at https://pkg.go.dev/github.com/brocaar/lorawan?tab=doc. There’s also a nice project at https://github.com/anthonykirby/lora-packet together with an online utility at https://lorawan-packet-decoder-0ta6puiniaut.runkit.sh/ that does a great job interactively. However, I have NO IDEA how to use any of those to decode the packet in ChirpStack before passing it along to my REST service.
Any help would be much appreciated!
If the payload is getting to the application server and then out to an HTTP integration, chances are good it is already decrypted (at the LoRaWAN level). The next question is, what do the bytes that your device is sending actually mean? Most/all devices will have a spec that will explain this. Many devices will have additional decoders that can translate those bytes into something meaningful to a human (frequently in JavaScript, but there are many options).
No, the payload is not getting to my REST server decrypted, or at least not decoded. I can paste the data that the REST service is receiving into this site and it decrypts/decodes it just fine.
Prior to attempting to get ChirpStack up and running, I had the same device sending data via LORIOT. LORIOT was, indeed, sending the data to the REST service decrypted, but ChirpStack is not.
Yes, I know I have to decode the meaning of the payload after I receive it. Yes, it is binary and not easily human-readable. However, I have that part working just fine for packets coming through LORIOT, but I have to decode the ones coming from ChirpStack. Obviously I could use a utility to decrypt/decode the data after it is received by the REST service, but that seems like the wrong place to do it, especially given that I don’t need to do that when using LORIOT.
You haven’t posted what the data looks like. Perhaps it is base64-encoded?
Base64 is actually very close, but not quite. For example, if I send the string “010203040506070809”, I get the string “AQIDBAUGBwgJ”. If I base64-decode that, I get the following bytes: [0]: 1; [1]: 2; [2]: 3; [3]: 4; [4]: 5; [5]: 6; [6]: 7; [7]: 8; [8]: 9. It’s tantalizingly close, but not good enough. Here are some other examples:
- 00 -> AA== -> [0]: 0
- 0000 -> AAA= -> [0]: 0; [1]: 0
- 0102030405 -> AQIDBAU= -> [0]: 1; [1]: 2; [2]: 3; [3]: 4; [4]: 5
- 123456 -> EjRW -> [0]: 18; [1]: 52; [2]: 86
- 1234567890 -> EjRWeJA= -> [0]: 18; [1]: 52; [2]: 86; [3]: 120; [4]: 144
Still, the question remains: should it be ChirpStack or my REST service that does this decoding? Since LORIOT does the decoding, I’m still leaning toward it being the responsibility of ChirpStack. That means that even if/when I get the decoding figured out, I have to figure out how to do it in ChirpStack.
Thanks again for your help!
Those look pretty good to me.
$ echo '010203040506070809'|xxd -r -p|base64
AQIDBAUGBwgJ
$ echo '1234567890'|xxd -r -p|base64
EjRWeJA=
In reverse:
$ echo 'AQIDBAUGBwgJ'|base64 -D|hexdump -C
00000000 01 02 03 04 05 06 07 08 09 |.........|
00000009
I’m not sure what I was missing, but it’s all working for me now. 
1 Like
Thanks, @bconway. This worked!