A few observations:
-
You’re not telling us which device you’re using? Please tell us, so future users can find this post. Also please add a link to the documentation so people don’t need to guess to help you.
-
As for “I guess the payload is a hex string”: no. LoRaWAN devices basically transmit bits, a.k.a. binary data. In your payload
4104
is a hexadecimal representation of two bytes, each having 8 bits:01000001
and00000100
. (Often such presentation is prefixed with0x
to indicate it’s shown as hexadecimal, like 0x4104.) But that is just a way to display the bytes. Most often, computers decode the above 2 bytes to the decimal number 16644. Please see How to send payload in Hex-format? and its links, like to Working with bytes, to make sure you understand. -
It’s really weird to decode those hexadecimal numbers 0x04 and 0x41 to the decimal 44.1 °C. But we’ve seen that before in Decoding Smart Waste Bin Detector DF702 payload:
(This encoding, when indeed true, makes handling unnecessary complex and makes the payload unnecessary long. The payload you’re showing is 42 bytes. The maximum at SF12 is 51 bytes; sending 42 will take a whopping 2.5 seconds.)
-
To use something like the above, you’d need to change the order, but above all you still need to find the specific bytes you need in the above calculation. You could try to find the hexadecimal pattern 0x0A5E, but the user manual should explain how to truly know how many bytes to skip.
-
As for:
In programming, the “index” for arrays (lists) is often zero-based, so for the above it should be
bytes[3]
(andbytes[0]
would give you 0x0A). But there’s a lot more data before that0A5E 4104
, which you need to take into account for that index too.