Hello everyone,
is it possible to send the payload to the application not encrypted.
For example, that the payload comes as Hex value?
What configurations has to be made within the application and node?
Thanks in advance
Denis
Hello everyone,
is it possible to send the payload to the application not encrypted.
For example, that the payload comes as Hex value?
What configurations has to be made within the application and node?
Thanks in advance
Denis
The payload is binary data. Hexadecimal is just a way to show bytes in a human-readable way, just like, for example, Base64. But when being sent as radio waves, it is neither hexadecimal nor Base64.
See Working with bytes.
Also, the payload is always encrypted, but your node’s library should take care of that automatically, and when TTN knows your keys (that is: when you use TTN Console, not some private Handler) then you’ll get the decrypted value.
See also My node data is undecodable, What to do with the raw payload via MQTT? and Advantage of Base64 encoding in MQTT?
Hello arjanvanb,
thanks for the response. That helped me a lot to explain my problem more precise.
You mentioned the topic “My node data is undecodable”.
In this topic the user asked about data_raw.
Your answer was, that “data_raw” is always Base64 encoded.
What do I have to do that “data_raw” doesn’t get Base64 encoded?
Do you know the answer or can point me to someone who could know the answer?
Thanks in advance
denis
You cannot change that. But why would you? Just decode it, and you’ll get the binary data, exactly as the node has sent it.
Like, for example, the 32 bits binary data 00001001 10100110 00001100 11010010
2:
cannot be printed on the screen as plain text, as in the ASCII standard binary 00001001
2 is the tab character, 00001100
2 is a form feed, and 10100110
2 and 11010010
2 are too large and not defined (but in ISO/IEC 8859-1 could be ¦
and Ă’
, or in ISO/IEC 8859-2 would be Ĺš
and Ň
, and in ISO/IEC 8859-5 be І
and в
; even for “plain” text, one would need to agree on the exact encoding that is used)
could be two unsigned 16 bits integer numbers 2470
and 3283
, when assuming MSB (or 2470
10, or 2470
dec to make it very explicit it’s decimal)
could be four unsigned 8 bits integer numbers 9
, 166
, 12
and 210
could be four signed 8 bits integer numbers, 9
, -90
, 12
and -46
could be a single 32 bits integer number 161877202
for MSB, or either 3524044297
or -770922999
for LSB
could be a 32 bits floating point value 3.997510e-33
, or 0.0000000000000000000000000000000039975
could be any combination of the above, like one 16 bits signed integer, a 8 bits unsigned integer, and a signed 8 bits integer, and in any order
could be written as hexadecimal 09A60CD2
16, 09a60cd2
16, 09a60cd2
hex, or 0x09A60CD2
and so on (much shorter and easier to read than ones and zeroes, isn’t it?)
could also be written in Base64 as CaYM0g==
, and that is what TTN uses
…and could be written in many other ways in many more encodings
But no matter how you print it on the screen, when being transmitted and in your computer’s memory it’s still the binary ones and zeroes 00001001 10100110 00001100 11010010
2.
Decoding the Base64 value will give you the binary data again, which you can then decode into, for example, the two integer numbers 2470 and 3283 (which could be temperature and humidity).
Like to see the hexadecimal representation of the Base64 encoded binary data, on a Mac one could type:
echo -n CaYM0g== | base64 --decode | xxd
0000000: 09a6 0cd2 ....
or:
echo -n CaYM0g== | base64 --decode | hexdump -C
00000000 09 a6 0c d2 |....|
00000004
…or to see it in bits:
echo -n CaYM0g== | base64 --decode | xxd -b
0000000: 00001001 10100110 00001100 11010010 ....
The 4 dots ....
indicate that the Mac cannot print the given bytes as plain text. That would be different if your node would send plain text (which it should never do):
echo -n MjQ3MDszMjgz | base64 --decode | xxd
0000000: 3234 3730 3b33 3238 33 2470;3283
or:
echo -n MjQ3MDszMjgz | base64 --decode | hexdump -C
00000000 32 34 37 30 3b 33 32 38 33 |2470;3283|
00000009
How the Base64 decoding is done in your application depends on the programming language you’re using; Google Search is your friend for that.
Hello @arjanvanb
thank you very much for this explaination. But I have another question regarding the encryption/decryption.
Is the a way to stop the decryption between the node and TTN Backend?
For example: I want that the information from the node gets saved encrypted in the TTN Backend. The decryption should be made somewhere else.
Do you know if there is a way to do that?
Thank you in advance
Denis
That would need additional payload encryption in the node†, or Setting up a Private Handler connected to the Public Community Network.
†Where the node’s LoRaWAN library would encrypt it again before transmission, and TTN would still decrypt the LoRaWAN payload, but that encrypted LoRaWAN payload itself would already have been encrypted on the application level in the node as well.
Hello @arjanvanb,
thank you very much for your help.
This helped me a lot.
Thank you many times!!!
Denis
Hello,
My payload is raw and my API received only Base64, how do I encode my raw payload to have it in Base64? Via the payload format…