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.
A post was merged into an existing topic: Unable to receive downlink messages from V3 application to V2 gateway
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.
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:
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?