I’m using the end device attribute mechanism to forward data that my application receives over MQTT to another service. Upon startup of the application, and once an hour, my application retrieves the attributes for the application and all of its devices. To my surprise, the contents of the end device attributes that my application sees, are different from the device attributes that I see myself in the console.
My application uses the EndDeviceRegistry.List call to get the end device attributes as described on: https://www.thethingsindustries.com/docs/reference/api/end_device/
My application has permissions “view devices in application”, “view application information” and “read application traffic (uplink and downlink)”.
I (as a user of the console) do not have full access to all of the properties of the application/end devices, however I am allowed to view the device attributes. My user’s permissions include the ones also given to the application, plus some extra ones. I do not have permission to edit the end device attributes.
My application does not store the device attributes (other than temporary in memory) and upon new startup of my application it retrieves the attributes again. Still, after restart of my application I still see old/wrong data. So IMO there is no other conclusion that TTN is returning wrong information. Or perhaps there is some intermediate HTTP cache that returns stale information.
I am sorry, it appears to be a problem/misunderstanding on my side.
The TTN application has multiple devices with the same device EUI but different join EUI.
My application made the incorrect assumption that device EUIs are always unique within an application.
It should consider the combination of device EUI and join EUI for that device.
Are you sure you havent got this the wrong way round - its not uncommon for suppliers to use same AppEUI/Join EUI between similar devices, but then with different Dev EUI…IIRC have seen this or similar with Dragino product in the past - minor change of APP EUI based on model# LHT65 …100, LT32222 …101, LGT92 …102, LM502 Module …106 etc. Though I note later devices used a more complex mix…
I think you are both right, the device EUI should be globally unique.
I did not create this TTN application nor decided about what EUIs to use.
I am just trying to create a kind of “integration” application that picks up data from the MQTT stream.
So, the assumption my code made about uniqueness of device EUI was indeed reasonable.
My initial suspicion that TTN was handing the device attributes somehow incorrectly, was wrong.
I can also imagine that it’s not up to the TTN console to detect and enforce every uniqueness constraint.