Devaddr changing everytime

hye, I would like to ask is it normal when everytime we open our sensor the Dev addr will exchange each time?

The DevAddr changes every time you make a join, that is normal. After the join, the DevAddr stays the same until you make the next join. That’s what you see in your screenshot.
Hth, martin

1 Like

i see, what if im using a ready made sensor that have its own DevAddr? because i think before this i have connected my sensor and even i open my sensor it still show me the same devaddr the same sensor i use from the figure above result, and because of the changing devaddr…will it affect my data when i do integration with Node-red MQTT?

Bit hard to say about the fixed DevAddr but that’s usually related to ABP connections.

You should limit the number of times your device joins when it is deployed to once.

But it makes no difference what so ever to any integration.

Just to keep you on your toes, did you know many many devices can share a DevAddr?

Your sensor probably is built to work with both ABP and OTAA. The fixed DevAddr is only used with ABP. With OTAA (thats what you use at the moment) this fixed DevAddr will not be used. Instead TTN will tell your sensor a DevAddr with every join.
I suggest to use the DevEUI when processing/saving data in to a database. This value is really unique for every factory made device. When saving your DevEUI along with sensor data you will always be able to distinguish between different sensors.

will it effect my work if i not limit the device joins? because I’m still in development of my project and my sensor sometime not sent uplink to the TTN and i dont know what the problem so i just restart my sensor. is it wrong to do that?

this is my first time using TTN so im sorry i dont know any of device that share a DevAddr, right now im working on WISE 2410 (vibration sensor) and trying to connect my sensor through RAK2245 and MQTT integration (Node-Red)

i see, thats why before this my device always using same DevAddr. Before i register a new device using the same sensor i set it to ABP, right now im using OTAA.
right now im not using any database to store any data from the sensor, can your recommend me maybe a link that can i work with for my project? right now my gateway is RAK2245, and my sensor that im working on is WISE2410.
maybe a newbies question, but can i store my data in my gateway?

A device can only join 65535 times. However for older LoRaWAN versions there is a ‘random’ number involved that will result in hitting issues a lot sooner. So limiting the number of joins is a good idea.

You should check why that happens and not use the ‘WIndows’ method of resetting to work around it. What happens if you deploy a device somewhere and this happens? Will you go to the device and reset it?

The device and gateway are not important when looking at a database. The use cases for the data are. So check what you want to do with the data, find a database that allows those use cases and then decide if you want to run the database yourself or use a cloud instance.

Yes and no. Most gateways are Linux boxes under the hood which would allow you to run a database on the gateway. However storage is limited and wears out so it might not be the best solution. And you will need to get the data from TTN anyway because the gateway can not decrypt the data.

if i close my gateway and only let my sensor/device ON, and i reopen back my gateway, will it give the new Devaddr or just used the same one?

Is it mostly because of the Wi-Fi connection? because sometime there are some message that appear like this
but is it possible there are something else that can cause this kind of problem?

if let say i just want to save my previous data in csv file instead, is possible to store it in gateway for me to download it later on?

Why not try it out - investigating solutions is part of the engineer/developer landscape.

But, as you’ve clearly not gone and investigated DevAddr and what they are for, it still doesn’t matter - it’s just a number of convenience to help the Network Server and has no bearing on any level of functionality for the device or it’s uplinks. You could never knew it existed and still get on with sending data.

Jac was using an analogy about turning your device off & back on again as a way of fixing every issue. WiFi has nothing to do with it. The messages you’ve highlighted, details on forum search, are your web browser temporarily losing contact with the backend servers providing the console data.

Yes, you could change the gateway code to save the data, but as mentioned above, it will be encrypted so reading it will require more code to use the keys for the device session.

This thread started out with a question that didn’t matter - the DevAddr can/does change with each join but it makes no difference to what we do, it’s an internal reference. So it’s not really clear what problem you face with your project. Can you explain again.

You may find watching the video & reading all of this set of pages helpful: