The combination of DevEUI and AppEUI needs to be unique. A DevEUI can be registered multiple times without any issue.
All the more reason for it not to be blocking the registration using an EUI.
Although I also appear to have morphed it from a gateway to a device registration via a mixture of nomenclature. Or via the mention of device by the OP or the error message having OTAA in it. Or the OP did the morphing. Confused!
This morning I did a quick test, I change the DEVEUI in my hardware, re-loaded my code, add it to V3, no issue.
So, it appears that the DEVEUI is the issue, as the original DEVEUI come from a EUI64 chip from Microchip, it very unlikely that someone else is using this DEVEUI… so for some reason, the old DEVEUI was locked in the database without a way to delete it if it’s in my account… or verifying that it was in another account… It possible that it was locked in on a previous attempt to load the device in V3 using the EU1 system.
also, error messages like “duplicate identifiers” not stating what identifier(s) is the issue is not very helpful…
My Friend Alan Cooper has written a number of books on computer interface design, and his firm (now part of designit) teaches classes on how to design man-to-computer interfaces… as TTN grows, they might find a need to understand how to refine their interfaces to make them more user friendly…
I think there is still some uncertainty here - if it’s a gateway, it’s not the Device Id. Which gateway is it that comes with Microchip EUI silicon on board.
I’ve started compiling from the source code all the different error messages so I can track things down quicker. Unfortunately it appears to assign them to identifiers that don’t necessarily get used as expected so I’m still on the learning curve of the data structures.
If you want to get TTI’s attention for Alan Coopers works, you’ll have to file an issue on GitHub.
As TTN grows the community has more members that can lend a hand in working on the code base. If you look at contributors for V3 you will notice its very much the TTI team that works on it while then there are over 140 thousand users using the free service. May-be it is time some of them start contributing…
I looked at a few issues in autumn related to the UI as I thought I could help out with that side of things.
I can replicate most of the UI using the API’s, apart from the console log which uses Server Events to send messages to the web browser. There is no concept of CORS for SE. I’ve looked in detail at the code used for the console log and it’s beyond me, mostly as I don’t know React and mostly because my brain gets overheated when looking at such obtuse code. It doesn’t appear to actually invoke SE on the web browser so I can’t tell if they have found a way to make it move between domains or if React / Babel is just using a polyfill.
The use of Google’s Protocol Buffers and the subsequent compiling of API stubs from the definitions means getting in to the Go code has a learning requirement as well as the more technical techniques, which for those that code Go a lot I’m sure makes sense.
The only Open Source element of all of this is that it is published on GitHub. Everything else about contributing is theoretical.
Nope, it has a steep learning curve but it is certainly possible to contribute to the code.
However there are more ways to contribute:
- creating issues on GitHub for improvements
- answer questions on the forum (with actual helpful answers, not me too’s)
@descartes you are well covered when it comes to contributing.