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?
IMPORTANT UPDATE!
Recently @laurens has advised:
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).
https://iotinabox.zendesk.com/hc/en-us/requests/new
Regular request posts here:? 
7 Likes
Wot’s this then?
A nice surprise? Christmas come early!? Will have to experiment…
Did a quick check in between other tasks and yep its there 
- so quickly added integration to an existing V3 registered Laird RS186 t&h sensor that was used for early V3 tests and is running fine.
However, where I see payload decoded just fine in V3 console:
There is a problem with Cayenne display that I will need to investigate further when I have a few mins (think I have seen this reported previously with an easy fix but damned if I can find quickly now I need it!)
Office/Workbench a bit of a sweatshop but not that bad! 
Guess I have no excuses for GW migration now - just have to find time! (And figure out how to get around Covid travel bans…e.g. guess Hamburg GW off limits for now! )
Do we still have access to V2?
What have you tried in the way of accessing the v2 console???
Have you been told we can’t??
Anyone migrating their Things Outdoor Gateway - ensure the RTC is setup with NTP after installing the Basics Station firmware. SSH access required.
Time and Date with ours was out (causing issues with the certificates). School boy error!
5 Likes