Connecting RadioBridge Sensors

Hey all,

We’ve recently taken delivery of a RadioBridge IP67-rated door sensor, however I’m struggling to get it working with Chirpstack.

I’ve managed to get it to connect, however the codec isn’t provided by the manufacturer as they would prefer that you use their own dashboard platform and have them decode the packets for you. Unfortunately they’d also prefer that you use TTN/Loriot/Orbiwise as the service provider, and as a result support for Chirpstack is near non-existent.

I’ve managed to get the sensor to connect, and it’s sending data when I trigger the “anti-tamper” alarm, however I can’t seem to work out from the PDF at https://radiobridge.com/documents/Common%20Sensor%20Messages.pdf how I might decode the messages into something a bit more meaningful.

https://radiobridge.com/documents/Wireless%20Door%20Window%20Sensor%20User%20Guide.pdf has more details on the type of message that one can expect to receive, however I’m really struggling to work out how to convert the information in these PDF’s into Javascript - does anyone have any pointers?

The important data appears to be the overall packet format:

RadioBridgeCommonPacketFormat

however whilst I can easily read the bytes in the console (even if I’m not sure exactly what they mean!), reading the bits is something I’m struggling to find documentation on!

1 Like

We’ve been testing a bunch of their sensors recently, and were pleasantly surprised with how quickly we got them connected, and their extensive documentation.

Our payload parsing is done outside of ChirpStack (and not in JavaScript), so unfortunately I can’t offer you much directly applicable advice. One thing we did notice compared to a lot of other sensors we work with is that they love to split data across bytes. I’m not sure what JavaScript offers in terms of bitwise operations, but chopping these payloads up was fairly straightforward in Go.

So the sensor itself seems to be great, it’s the “oh, you’re not using our platform, well, it’s up to you to figure it out, but here’s the links to the packet documentation” that’s a little disappointing, especially compared to Elsys.se who say “we don’t care who’s platform you use, but if you’re using TTN or another platform that allows bespoke decoders, here’s ours…”

I’ve got a very basic decoder up and running now as follows:

// Decode decodes an array of bytes into an object.
//  - fPort contains the LoRaWAN fPort number
//  - bytes is an array of bytes, e.g. [225, 230, 255, 0]
// The function must return an object, e.g. {"temperature": 22.5}
function Decode(fPort, bytes) {
  var tamper_alert = 0;
  var gate_status = 0;
  if ( bytes[1] == 2 ){
      tamper_alert = bytes[2];
  }
  else if ( bytes[1] == 3){
      gate_status = bytes[2];
}
  return {"message_type": bytes[1],
         "tamper_alert": tamper_alert,
         "gate_status": gate_status
         };
}

So hopefully that will help anyone who stumbles across the same issue…

I contacted RadioBridge about this same thing.

Here is their response. It was extremely fast response also.

Hello Kevin,

While we do not have any dedicated ChirpStack decoders, we have implemented a basic TTN decoder on JS which you may find helpful in decoding packets.

This script is not comprehensive, but covers about 95% of our current available product.

There are a few unsupported functions such as extended supervisory, what you will get out of this is basically packet decoder functions for most Radio Bridge sensor events.

[https://github.com/RadioBridge/TTN-Packet-Decoder]

Thanks Kevin,

Not sure why they didn’t send me the same link, but that’s great to know that it exists, I’ll add it to my setup later on today!

Kind regards,

Matt

This sort of “codec development” is something that just about everyone needs to do, regardless of what NS/AS you’re using. Would anyone be interested in taking helping with some common devices and coming up with robust open source codecs to get this started?

I think it would be in the best interest of the device companies to open source these codecs (even if standardizing on TTN interfaces) so others can more quickly adopt their devices. It seems like the Cayenne LPP is the closest there is to a “standard” of how to convert a LoRaWAN payload to a JSON object. However, device manufacturers often have data payloads that do not fit within the Cayenne LPP.

I had the same issue in the past and built out a decoder for the various radiobridge sensors I was using: