# Noob issue connecting RadioBridge Sensors to TTN

**URL:** <https://www.thethingsnetwork.org/forum/t/noob-issue-connecting-radiobridge-sensors-to-ttn/36050>\
**Category:** End Devices (Nodes)\
**Created:** [April 9, 2020, 7:37pm UTC](https://www.thethingsnetwork.org/forum/t/noob-issue-connecting-radiobridge-sensors-to-ttn/36050 "2020-04-09T19:37:01Z")\
**Posts on this page:** 1\
**Showing post:** 9

<div class="post-metadata">

**Author:** ![arjanvanb](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/arjanvanb/32/46626_2.png) [@arjanvanb](https://www.thethingsnetwork.org/forum/u/arjanvanb)\
**Post date:** [May 26, 2020, 9:14pm UTC](https://www.thethingsnetwork.org/forum/t/noob-issue-connecting-radiobridge-sensors-to-ttn/36050/9 "2020-05-26T21:14:20Z")

</div>

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. 🙂

> [@CambridgeSensorNetwo](#):
>
> 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”

I disagree. Yes, in V2 using the same AppEUI among multiple applications seems to work. ([Or does it?](https://www.thethingsnetwork.org/forum/t/dragino-lht65-and-network-coverage/31434/10)) 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](https://radiobridge.com/documents/How%20to%20Connect%20LoRaWAN%20Sensors.pdf#page=4):

> ### 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:

> [@CambridgeSensorNetwo](#):
>
> RadioBridge don’t reprogram the AppEUI in the device from the generic 0101010101010101 (for the 306 sensor types)

…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](https://www.thethingsnetwork.org/forum/t/dragino-lht65-and-network-coverage/31434/12) (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](https://macaddress.io/mac-address-lookup/VaR9d60kP3) 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?**

> [@CambridgeSensorNetwo](#):
>
> I think this is generally useful hence LoraWAN AppEUI has been re-branded “JoinEUI” although nobody noticed.

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](https://lora-alliance.org/sites/default/files/2018-04/lorawantm_specification_-v1.1.pdf#page=47):

> ### 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.

---

_[View the full topic](https://www.thethingsnetwork.org/forum/t/noob-issue-connecting-radiobridge-sensors-to-ttn/36050)._
