The combination of DevEUI and AppEUI needs to be unique. A DevEUI can be registered multiple times without any issue.
Ah, OK.
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âŚ
1 Like
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.
Thereâs no architectural documentation to really point the way and the UI side via a web browser requires detailed knowledge of JavaScript with the React library. Itâs then transpiled by Babel over to a wider supported dialect of JavaScript which means the source doesnât match up with the production code and often doesnât look anything at all like the original code.
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.
I did ask many months back about the state of the JavaScript SDK (more languages coming soon) as the single example provided doesnât run. There are other parts that need addressing first, so I wasnât able to get any pointers. This is one area I thought I could contribute but as above, Iâm a bit without clue.
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:
- documentation
- examples
- 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.
1 Like
A post was merged into an existing topic: Unable to receive downlink messages from V3 application to V2 gateway
Hi everybody,
sorry for bothering, but Iâm afraid I created one of those âHoly ***! Why do people do this crazy stuff?!â corner cases: I tried to move my gateway back from V3 to V2. And failed.
After some fiddling around with T-Beams and stuff on V2 in an area with bad coverage, I bought 2 RAK7258. After reading about the V2-V3 migration I added the first one to V3 (legacy packet forwarder), and after entering the right router address 
nito the RAK, everything worked fine. Except that my GW didnât show up in TTN mapper 
After reading this thread I figured out that my GW wont show up in TTN mapper because itâs in V3, so I decided to delete it in V3 and move it to V2 for the time until V2 will be switched off / TTN Mapper will work on V3.
Deleting in V3 worked fine, but re-adding in V2 doesnât. I get the old error
Could not register gateway
a gateway with id eui-xxxxxxxxxxxxxxxx already exists
I waited for 24 hours now, because I guessed there may be some timeout triggers or synchronisation jobs betweeen V2 and V3 running, but to no avail.
Any suggestions on what to do now? How do I get my gatewayâS EUI deleted from V2 so I can add it?
I believe that is not possible. Once a gateway is deleted from V2 you can not register it again. But I believe letting the gateway forward to V2 without it being registered will work. You just wonât be able to change its description.
Yeah, we wonder that too, given all the warnings.
But from your narrative, you donât appear to have got as far as deleting it from v2. Except you say âre-addingâ. So itâs not really clear what you actually did with which of the two gateways. Did you put both on v2 and then remove one to put it on v3. Like the Hokey Cokey.
There is no reason why you canât add it to v2 - the databases are separate - the packet forwarder handles passing on packets for anything it recognises as being destined for v3.
At worst, as @jpmeijers says, you can just point your gateway at the v2 endpoint, you just wonât be able to see traffic in the web console.
So, if you can tell us exactly what you did with gateway A and gateway B, we may well be able to come up with a solution.
Thanks descartes 
All the warnings? Well⌠I have to admit⌠Iâm having some kind of problem understanding why a device with an immutable burned in address canât be removed from a network and re-added later/somewhere else. That would basically turn it useless once it has to be sold or removed from the network. Maybe conventional networking wisdom kinda misled me there.
What I did:
Gateway B: I just added gateway B to V2. Works. No problem there.
Gateway A: I added gateway A to V3 about 2 weeks ago. Had some learning curve until I found out which server address to enter in the packet forwarder config, but after that it worked fine. It just didnât show up on the TTNMapper map. After reading the beginning of this topic, I figured out that this may be caused by V3 traffic not being forwarded to V2. Thus I decided to delete the gateway A from V3 and add it to V2 (I originally wrote âre-addâ, but thatâs misleading; âaddâ is correct). Deleting gateway A from V3 worked, but adding it to V2 fails with the error message
Could not register gateway a gateway with id eui-xxxxxxxxxxxxxxxx already exists
My guess is: Gateway A is/was known to V2 somehow⌠by replication of gateway EUIs from V3 or having a common EUI database, maybe? According to some github tickets I found while googling there were issues about gateway EUIs not being released when gateways were being deleted, but these issues were fixed last summer.
So⌠Iâm wondering: How do I get my gateway A into V2? Not at all? Should I just add it to V3 again and wait until V3 gateways show up in TTNMapper some day?
Wow ok then it is really strange you canât add it. Perhaps someone else mistyped their EUI for yours, and registered it under their name. You can check here:
https://account.thethingsnetwork.org/api/v2/gateways/eui-YOUR_EUI
Which should list the gateway if it was known by V2, along with the owner.
Everything around V3 is still very unclear. It might be worth adding a comment to Discussion point: V3 console is too complicated
There is no need - there is a perfectly good system for transferring it to the new owner. And if itâs fallen in to disuse, just leave it be, it doesnât have any impact on anything.
As @jpmeijers says, may well be someone mistyped the EUI.
It doesnât really matter as v2 has a finite lifespan and youâve got one on v2 working for now, you ignored the warnings so you have to pay the price - just have it on v3 and for the love of all that runs the universe etc, please people, stop deleting things, there is just no need to do so.
Oh, thanks for the hint!
I tried the link and it looks like gateway A has already been registered in V2, but not by me!
I used a meaningful description in V3, whereas the description in the V2 database is just âtestâ. And I also added coordinates and let status and owner data be public⌠now no coordinates are present and all information is set to non-public.
So my assumption that the error has something to do with the move from V3 to V2 seems to be wrong; my gateway just is already registered in V2.
But what do I do now⌠get back to the seller?
Someone elseâs finger trouble is nothing to do with the seller.
Do you have a compelling need to have it on v2? If not, leave it be. If yes, you could put your case to TTI on the Slack support channel to see if they could add you as a collaborator to take ownership.
But it should still route for you anyway, youâll just not see traffic on the gateway console.
Turns out the seller had gateway A registered. âJust once, just for testingâ.
So⌠my problem ist fixed, both gateways are now connected to V2.
Thanks for pointing out to me that gateways shouldnât be deleted in TTN. I also discovered the âtransfer ownershipâ link and will use it in the future.
My compelling need is: Iâd like my gateways to show up in the TTNmapper map. And the way I read the beginning of this topic means that the need to be in V2 to do so, at least for now. No?
Ask for some shop credit for future purchases - who was it so we know to check what they ship in future.
For bragging rights for the next few weeks until v2 turns off?? Not that compelling!
V3 is not ready yet.
In that case the seller should be able to transfer the ownership on the V2 console to you.
Iâve seen mentions about V3 forwarding to V2 since v3.13. Also it seems like V3 has the V2 gateway IDâs now. Maybe someone can investigate this?