Noob issue connecting RadioBridge Sensors to TTN

End Devices (Nodes)
1

I have two RadioBridge sensors that are sending data through my new TTIG - I can see the traffic on TTN/Gateways - and I’m getting messages in the RadioBridge Console, so my integrations there are working. My issue is that I can’t add the sensors to my Application. Every time I try to add one I get an error - "Permission denied: Broker did not set device:permission denied:NetworkServer did not set device:permission denied:No “devices” rights to Application “radiobridge-app-us-west”

I don’t have an application with that name, so of course I don’t have device rights.
Any suggestions?

2

The nodes are registered to another application which is not surprising as you are seeing the data in the radiobridge console. If the nodes would not have been registered with the radiobridge application the data could not have reached that console.
Basically you can not register them to another application.

1 Like
3

Jac could you clarify your answer for other Radiobridge noobs (like me)? I’d like to register a RadioBridge sensor (external Temp/Humidity) on TTN, and don’t expect to have RadioBridge infrastructure anywhere in the loop - do you have experience of doing this? The RadioBridge documentation seems to give options of adding a ‘RadioBridge’ integration to TTN, or registering your gateway to a RadioBridge network server, but I thought I bought a sensor, not a network service.

4

Hi @CambridgeSensorNetwo, I use RadioBridge sensors and had to puzzle my way through this at the start. My take on the situation is:

  • RadioBridge sensors are configured via downlinks. This is quite complex.
  • RadioBridge offers what might be best called a provisioning portal.
  • Set up a RadioBridge account on their web portal.
  • Add your device to your account and set it to use the “TTN Radio Bridge account”.
  • Power-on your device in TTN coverage and you should see it appear on your RadioBridge web console. It’s coming via the RadioBridge TTN account and application.
  • Now you can use the web portal to configure the device. It uses downlinks in the background.
  • When you’re done, delete the device from the RadioBridge web portal.
  • Add the device to your own TTN application.
  • Power-cycle the device.

Simples, huh! I believe that the RadioBridge portal is free to use this way but if you want to use it for more then there may be a cost.

2 Likes
5

Thanks Tim - pointers much appreciated. Unexpectedly, of the two RadioBridge sensors I have with me, one has the AppKey on the label so I could register that to TTN with the AppEUI given in the RadioBridge docs: https://radiobridge.com/documents/How%20to%20Connect%20LoRaWAN%20Sensors.pdf

To give RadioBridge a bit of credit their data protocol is well documented, see docs at the bottom of each product page e.g.

The other similar sensor (the one I started with) only has the DevEUI so I think I’m going to need to dive into the RadioBridge portal for that one. I suspect RadioBridge recently changed their AppKey policy and my two sensors straddle that change.

7

But that says:

:warning: Do not add devices to TTN directly. After this integration is set up, adding devices to the Radio Bridge console will automatically add devices to your TTN account.

(I hope they somehow re-program the device then, to get a unique AppEUI, but well…)

If that’s on the device then you should actually peel it off before deploying the device: it’s a secret…

8

Thanks Arjan - comment on keeping the AppKey secret accepted.

Re registering/AppEUI, I’m referring to “Section 8” in the linked RadioBridge docs, which is the generic “how to connect to without RadioBridge console support” rather than the “Section 2” “TTN connectivity but still using the RadioBridge console to register and manage the device” (which I don’t want or need).

If it helps others: RadioBridge don’t reprogram the AppEUI in the device from the generic 0101010101010101 (for the 306 sensor types), TTN uses both AppEUI and DevEUI to look up the application destination for data from the sensor, so AppEUI only needs to be unique within a TTN “Application” and (conveniently) a TTN “Application” can have multiple AppEUI’s. So the TTN “Application” isn’t exactly what was originally a LoraWAN “application”. I think this is generally useful hence LoraWAN AppEUI has been re-branded “JoinEUI” although nobody noticed.

9

Okay, so it does (should) support registering it to, e.g., TTN? Then I should not have deleted my earlier answer after I ran into that warning text. :slight_smile:

I disagree. Yes, in V2 using the same AppEUI among multiple applications seems to work. (Or does it?) But will it still work if the community network migrates to V3? Or if you want to move to another network? I don’t know.

I’d say that the following:

1.3. AppEUI / JoinEUI

The LoRaWAN AppEUI, now known as the JoinEUI (they are sometimes used interchangeably), is consistent among Radio Bridge products and thus is not listed on the product labels. Earlier products use a generic, non-unique, JoinEUI, and newer products use a unique JoinEUI as described in the following table.

Table 1 AppEUI/JoinEUI for Radio Bridge Products

AppEUI/JoinEUI Description
01-01-01-01-01-01-01-01 Used in the following product families: RBS301, RBS304, RBS305, and RBS306
78-94-E8-00-00-00-00-00 Used in product families not listed above

…along with:

…is really bad if the devices are registered outside of the Radio Bridge platform. I really feel that each off-the-shelf device should have its own unique AppEUI (or allow for changing it).

Aside, 0101010101010101 is not even owned by them. They do own the block of 16,777,215 addresses of that second EUI-64 but only seem to be using one value for all devices of some type? Also, I don’t understand their “newer products use a unique JoinEUI as described in the following table” while that table refers to a single non-unique value? Maybe it’s just a documentation error?

Surely we noticed, but JoinEUI is a LoRaWAN 1.1 term. And it’s actually a different thing, although a 1.0.x network that is oblivious about the existence of 1.1 can just perform a 1.0.x OTAA if a user has registered the JoinEUI of a 1.1.x device as the AppEUI on a 1.0.x network. When that happens, a 1.1.x device can tell from the Join Accept that it should fall back to 1.0.x while deciphering the Join Accept to derive the secrets, and in all its subsequent communications.

So, in LoRaWAN 1.0.2 (which is what the TTN Community Network uses, and what this specific device uses), it’s still AppEUI. For the 1.1.x JoinEUI:

6.1.1.1 JoinEUI

The JoinEUI is a global application ID in IEEE EUI64 address space that uniquely identifies the Join Server that is able to assist in the processing of the Join procedure and the session keys derivation.

I’d say that the JoinEUI should again be unique for each off-the-shelf device, as a manufacturer cannot make assumptions about the device’s usage.

Long story short, if one does not want to use the Radio Bridge services, then to make sure things work in the future I’d return the devices and request the following:

Note that the AppEUI/JoinEUI can be modified at the time of manufacturing to match the end customer’s requirements. Please contact Radio Bridge for more details on customization and pre-configuration.