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.
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.
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.
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: 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.
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?
Since the v3.13 update of last week, we can exchange traffic between TTN V2 and The Things Stack Community Edition, both ways. Meaning that you can start migrating your gateways as it won’t impact the coverage of the public network.
Unless someone shouts and says something is broken or discovers an integration related issue it looks like we have green light to migrate our GW’s
It may be prudent to start with one or two each or by co-ordination within communities to test as you go.
We would recommend that migration is undertaken WITHOUT DELETING GW FROM V2 - for now! Just in case you need to roll back whilst resolving any discovered issues.
Also if your GW is a TTIG - HOLD ON V2 FOR NOW! We await formal announcement of CUPS support under TTS(CE) aka TTN V3. We will shout it on the Forum once TTIG migration is a supported option - testing is currenty underway and we will keep you updated under seperate threads/announcements.
Note: One of the roadblocks for myself and others in taking this step has been the lack of Cayenne/myDevices integration OoTB under Webhooks (formerly http integrations) in V3, with this change of guidance it shoud be the case that any V2 Cayenne integrations should continue to work with data fed through V3 GW’s until V2 shutdown (?) reducing risk…anyone interested in Cayenne should start to lobby myDevice hard for an off the shelf V3 integration (TTI have done their bit - it is up to myDevices to step up now).
nito the RAK, everything worked fine. Except that my GW didn’t show up in TTN mapper 
