Hello, I am working with the ChirpStack Gateway Bridge and received this payload over MQTT. I am looking to read the raw sensor data that was forwarded using the bridge, does the gateway bridge add another layer of encoding? I have all of the sensor information such as the keys and EUIs.
I tried to convert the Base64 in the phyPayload to hex to read bytes based on the sensor documentation like I have done before on different gateways, but I am unfamiliar with how the ChirpStack Gateway Bridge formats the payload as it is my first time using it.
Is the phyPayload the sensor data that I can convert and read from, or does that need to be decoded further before I can access the raw sensor Base64 data?
Any assistance would be much appreciated.
this decodes fine to: 0x00,0x00,0x00,0x00,0x00,0x20,0x57,0xf9,0x8c,0x18,0x00,0x15,0xd4,0xa4,0xd5,0xb3,0x70,0x43,0xda,0x86,0xcf,0x03,0x18
Have you tried to match that up against device documentation to decode each byte? Once you had a decoder, beat it into format chirpstack requires and include it in the device profile for that particular family of devices. Then, adding new devices using this device profile would get their data decoded.
If that’s not working (ie. hex data isn’t valid per device documentation), then you’d come on the forums and provide your existing code, any errors from the logs, and information on device you’re dealing with. It REALLY helps to start with a commercially available device that is known to work with chirpstack, if you want to avoid stress.
P.S. I’ve been away from chirpstack forums in a holding pattern, waiting for the great news that came recently. However, I don’t know what to do with “docker” so will need to find some time to figure that whole thing out (under ubuntu - if anyone can point me to a good tutorial).
phyPayload contains the LoRaWAN payload. Please refer to the LoRaWAN specification how to decode this. In summary, it contains the LoRaAWAN mac-layer fields + the application payload (sensor data) in the
frmPayload field. Please note that this field is encrypted using the AppSKey. You will find more information about this encryption scheme in the LoRaWAN specs. In short, this is typically why you need a NS