RS-485 AppEUI / JoinEUI Update

I registered my RS485-LN, MAC V1.0.3, PHY V1.0.3 REV A, Over the air activation (OTAA), Class C end device in v3 applications with all zeros as APPEUI. The v3 guide said I could update later. if the device was programmable. How do I update APPEUI and what ID should I use? I have an APPEUI from Dragino, how do I enter it? When I do an AT+CFG the APPEUI on the RS-485 device is not zeros nor is it the APPEUI from the manufacturer.

Was it this bit:

Enter a JoinEUI/AppEUI if provided by your manufacturer. If your device is programmable, you may use all 0ā€™s, and then program the same JoinEUI/AppEUI in the device.

The CLI allows you to update far more than on the console which, for Dev & App/Join EUIā€™s is locked.

However, the fundamentals are that the DevEUI, the App/JoinEUI & the AppKey on the console have to be identical to the settings on the device. It is usually easier to read the settings from a device & put them in to the console. It is not unusual if you ask a vendor for an EUI for them to supply one, even if you already have one. Most Dragino devices come with the info on the label on the bubble wrap.

Yes, on my console, the wording is, ā€˜ā€¦ it is ok to enter all zeros, but ensure you use the same JoinEUI in your device as you enter in The Things Stackā€¦ā€™
Does this mean I enter all zeros in my device JoinEUI?

My console too, however there are some nuances that are invisible brick shaped to what is on the console & the documentation - brick shaped because itā€™s not made clear what combinations may or may not work so when you bump in to the nuance, you know it!

So the console is suggesting all zeroā€™s and to update the device. The docs say you can change it but donā€™t mention you canā€™t change it via the console, only the CLI.

We have found that some of the LoRaWAN stacks do not like all zeroā€™s for reasons unknown - Iā€™m sure someone with some time could track the why down. Also, the LoRaWAN Alliance in their firmware best practices guide says do not use all zeros for an EUIā€™s.

So you can try one of two things:

  1. Set the device AppEUI to all zeros which could potentially not work.

OR

  1. Re-register the device on the console with the EUI/keys that the device is reporting which should just work.

As I suggested, being sent a new EUI is a bit of a red herring - it would have been quicker for them to send you one than dig in to the details of why you didnā€™t have one.

I deleted and recreated the end device with the manufacturer IDs but it will not join. It is an EU device and using simple OTAA. I get this error on the gateway and the end device live data, I can find no reference to these terms. What do they mean?

{
  "time": "2021-08-05T10:07:22.538Z",
  "name": "synthetic.error.unknown",
  "isError": true,
  "isSynthetic": true,
  "unique_id": "synthetic.1628158042538",
  "data": {
    "error": "TypeError: Error in body stream"
  }
}

There must be something obvious here, I used v2 console for over a year with dozens of devices and no problems. I have registered 10 devices on v3 now and not a single one works. I followed the manufacturer instructions and the TTN instructions deleting and re-registering, something else is wrong, can a Dragino RS-485 work on console v3? Could it be the gateways I am connecting through are mis-configured?

That (formatted with </>) error message is about the communication between your browser and the servers and isnā€™t related to the registration.

There is no particular reason anything with a good set of keys / EUIā€™s canā€™t be registered and itā€™s not related to the gateways.

There are a few more buttons on the v3 console, but the OTAA registration is straightforward whereas ABP is a bit of a mare.

This information about the above error suggests it is not my end devices or gateways, it is the console:

Event details
info
Note: This meta event did not originate from the network but was generated automatically by the Console. It is not related to any end device or gateway activity.

Unknown error

The Console encountered an unexpected error while handling the event stream data. It is possible that event data could not be displayed (correctly) as a result. Note that this is an internal error which does not imply any malfunction of your gateways or end devices.

Am I wasting my time adjusting my device configurations?

I donā€™t think so, you just need to get one in the bag and confidence will increase.

Are you using the end device repository entry and the EUIā€™s & keys that the device reports to you over itā€™s serial port? Or doing a manual entry?

I am using the repository entry, just adding the EUIs from the box. There is no payload or any other data to complicate the things, the device instructions say it is pre-configured and should join automatically following registration.

When you say ā€œfrom the boxā€ it wouldnā€™t be totally surprising if the device has something different, a bit rare for Dragino but not the first time - can you verify itā€™s EUIs & Key via the serial port.

And then, yes, when the keys on the device are on the console with an operational gateway, data should start to flow.

Everything on the device box, on the AT+CFG screen and on console match.

My AT+CFG shows AT+APPEUI=a0 00 00 00 00 00 01 01

but when I look on my gateway data, I see:

  "join_request_payload": {
    "join_eui": "0000000007000000"

I have never set either EUI to anythiing, that is how it works out of the box.

Weird.

I take it this means you didnā€™t change the device settings.

I reset the device and manually entered the EUI, now it works. Canā€™t explain it but thanks for your help.

Normal for Norfolk/LoRaWAN!

As it happens I setup using the repository entry with the AppEUI you quoted just in case it had some foibles using a TTI generated DevEUI but itā€™s working OK.

1 Like