RAK7258 phypayload decode

Issue: RAK7258 data change to phypayload after upgrade firmware

Setup:

LoRa® Server:

Details:I update the firmeware of my RAK7258 to LoRaGateway_1.1.0062_Release_r202. before the message of my LAIRD Temperature and humity sensor was like this
mensaje=str(b’{“applicationID”:“1”,“applicationName”:“Data_Pig”,“devEUI”:“0025ca0a00003e42”,“deviceName”:"/TH/Modulo_1",“timestamp”:1588433208,“fCnt”:1,“fPort”:1,“data”:“AWcA7wJobAMBBA==”,“data_encode”:“base64”}’)
Now the message is like this
TOPIC gateway/60c5a8fffe7615f7/event/up
PAYLOAD b’{“rxInfo”:{“mac”:“60c5a8fffe7615f7”,“timestamp”:575969940,“frequency”:868500000,“channel”:7,“rfChain”:1,“crcStatus”:1,“rssi”:-64,“size”:23,“codeRate”:“4/5”,“loRaSNR”:6.8,“dataRate”:{“modulation”:“LORA”,“spreadFactor”:7,“bandwidth”:125},“board”:0,“antenna”:0},“phyPayload”:“AC5D78JeT9WOQj4AAArKJQB1Tlqc0l8=”}’

I dont know how traslate the phyPayload to Temperature, Humidity and Batery… ¿How Can I do it?

These are two distinct types of records.

The first example is a validated, decrypted and decoded application packet output from the LoRaWAN network server.

The second example is a still-encrypted raw signal report that would be input to the LoRaWAN network server.

You can only decode this externally if you have the applicable session keys, typically you would only want to do it yourself for debug purposes, because converting the raw packet into an application message is a key part of what the network server does for you.

You may either now be subscribed to different topics, or may simply not have the network server enabled to run on the new configuration.

Hi. Thanks for tour answer

I would like to configure the router so that the message is encoded … How should I do it?
Thanks

Where did you get the first example you gave?

If you look in the same place, you should see similar information, that is the data you need to decode from Base64.

How did you decode it previously?

As previously explained, in LoRaWAN it is the job of the network and application servers to decode raw packets to any application level meaning which they may have.

Surely you already knew that?

Hi i didn’t know
The previous message I do not remember how I got it and I would like to have it again. I had problems with the wifi connection and restart the rak device and update the firmware. Try to configure it again and I could not get the connection to send me an unencrypted message … I don’t care because the network will be in a remote and isolated environment

Yes, I have a reasonable handle on the different elements.

I was referring to the OP’s application - there is/was an implication that the data was previously arriving as expected, somewhat evidenced by the copy of the first message. If he can find that, which I see he can’t, problem solved.

As Chris mentioned above, you have quoted two different types of the message.

Your first one is the unencrypted one - it will need decoding - but that’s the format of message you are looking for.

The second one is the encrypted message that is passing through the different parts of the gateway - whilst it gives useful information, this is not the data you are looking for.

So if you locate the output that has something similar to

“data”:“AWcA7wJobAMBBA==”,“data_encode”:“base64”

and you can tell us what the device is and what sensors it has, we may be able help you get going again.

Hi
I have a RAK7258 Minigateway and a Laird Sentrius RS186 Integrated Temperature/Humidity Sensor

Thanks

Sorry, yes, you did say - there is a wealth of technical information on the Laird website about the data format - is this the information that you used to decode the data previously?

Or did someone else set it up for you?

I used the technical information in laird web

So do it again - we’ve not established yet that the upgrade has caused any issues with decoding the payload as you gave us two different message formats - if you look at the application server output (the first one) on your gateway, it may well be that you have all you need to resolve this.

Hello
My main question is: Why does the message arrive encrypted now? How can I configure the gateway to NOT encrypt the message?

You have show us TWO DIFFERENT sorts of messages.

It always arrived encrypted at the network level - that is the second message you showed us.

When it is processed at the application level it is decrypted - that is the first message you showed us.

If you look in the application logs, you may well find that it is decrypted - a firmware upgrade is deeply unlikely to start encrypting things but we can’t establish that until you look at the application logs.

But right now, you have compared TWO DIFFERENT things and we don’t appear to have moved forward to looking in the right place (application level) to see if the messages being received are similar to the one you gave us earlier.

Please look at the newly received messages in the application log.

Hello
I understand what you’re saying
Maybe I have not explained everything: I have configured the gateway to forward the information to an external MQTT broker and that is the message I receive at the broker. The python application that I had in the broker received data: AWcA7wJobAMBBA == and decoded the following bytes b ‘\ x01g \ x00 \ xef \ x02hl \ x03 \ x01 \ x04’. Then convert each byte to a decimal to get the measurements

I have made a test: I have erased the data of the application to try to avoid the codification of the message. I attached the current configuration

If I cannot receive the message without encryption, how can I decode the message?

Are you subscribing to the gateway or the application? It looks in your first message like you are accessing the gateway messages, not the application messages.

You’ve got the MQTT configuration mixed up and essentially backwards.

The gateway part of the system / gateway bridge should be pointing to the internal MQTT broker at 127.0.0.1 so that the raw traffic on the gateway/ topic goes to the internal network server.

The network server gateway MQTT will need to point there as well so that it gets data from the gateways.

But then the network server application MQTT should be pointing at your real external MQTT broker where you want it to publish the decrypted and validated payloads to the application/ topic

Ultimately it would be better to use a cloud broker for everything and move the network server component to the cloud.

1 Like

Hello
I have already wasted two weeks trying to replicate the configuration that I achieved two weeks ago. I have already tried thousands of convinations and the only way to receive the message in the external broker is encrypted.
Now the best thing is for me to focus on decoding that message.

Thank you for your patience and help.

Can you recommend a topic to decrypt this message? I need to modify my python program to decrypt the message before translating it to temperature and humidity values

Best Regards

No, that is ENTIRELY wrong.

It is the job of the network and application servers to validate and decode messages and to interact with nodes, including encoding both network and appliction level downlinks to send back to them.

What you need to do is to take time to understand the block diagram of how the gateway and the chirpstack network and appliction servers and your application are supposed to communicate by means of one or two MQTT brokers, and to set things up correctly for that.

What you are proposing would amount to throwing away chirpstack and writing your own network server. (I’ve actually done that - but for good reasons of implementing capabilities LoRaWAN does not have). You want to do it simply out of ignorance of how the system is supposed to work. You definitely will not get anywhere in implementing a LoRaWAN network server until you understand what a LoRaWAN network server is supposed to do and how that differs from what a LoRaWAN gateway does.

You have a small problem of configuration. Re-inventing the wheel is not the answer.

Even if you decide you don’t want to use LoRaWAN but rather implement some other scheme on top of LoRa, you’d still probably need to modify your node firmware, and to understand the typical LoRaWAN infrastructure block diagram enough to figure out how your custom code would interact with the gateway instead.

OK, I will take time to review the block diagram
My project is in environments with difficult internet access and being able to have my own network server is very useful.
The data must be received by my MQTT broker (raspberry pi) without coding and include it directly in my database, avoiding the TTN server. I already got it once, so I know it’s possible.
I will check everything again because I can only get data using the Lora Gateway part
I will draw a schematic of my network and review the paths of the data.
Thanks for your advice