Dear All,
Why can’t I delete my gateway? The menu where I can delete is gone? See attached screenshot.
Best,
Anders
You may want to try a force-reload or clear caches or similar as your side bar isn’t showing the other options including “General settings” at which point there is, scroll down, the terrifying and dangerous delete gateway option. After which, you will never be able to add that gateway EUI to TTN again. Ever. So just leave it be.
Dear descartes,
Thank you very much for your answer. My problem is that I can not create a new gateway again. I have a TTIG gateway from The Things Network. However, it must be said that I have found out that I can not now move my TTIG gateway to v3.
Best
Ohlhues
Moving TTIG’s are work in progress so not something to do yet. As long as you haven’t deleted from V2, it should carry on working on V2.
I have thankfully not deleted my gateway on v2 
So until further notice everything works OK. Thanks for your help and good Sunday.
Sincerely
Andrs
1 Like
Hi @ohlhues, it looks like you somehow managed to revoke your collaborator rights on this gateway. We’ve restored your rights, and will see if we can make it more difficult to accidentally revoke your own rights.
I am using a gateway for over 3 year now it is: eui-b827ebfffe517647 Stiphout with over a million packets processed. Two day ago I discovered that is was not working anymore. I saw about the V3 upgrade and tried it but did not work. The problem was not TTN but the memory left on my gateway, it ran out.
But now I have the problem that I removed from V2 and went to V3 but can’t get it to work anymore.
Also going back to V2 does not work anymore. So I have a “BRICKED GATEWAY” which is a shame because it covers quite an area. What can I do ? Can somebody make it possible that I can go back to V2 fro time being ?
Mostly, the response is that the data is distributed across so many databases that undeleting a gateway or purging it’s EUI from the system isn’t feasible.
It may be that we need to help you get it working on V3, but it won’t route any packets back to V2, so your applications & devices will need moving over as well.
If you just enter the V2 information and boot the gateway it should forward data to TTN without any issues, as you are unable to re-add it to your account you won’t be able to see it in the console but it will still forward traffic to TTN without any issues.
(You can check that by looking at your applications data stream)
Thanks for the quick responses, I will try again with clean installation later this week onV2. I will check the responses from my application devices to see if they can connect and send data to MyDevices. If so then I will be happy again and I’ll wait for somebody who has the same gateway IC880A-SPI and was successful in migrating to V3.
The hardware isn’t the bottleneck when moving to V3. What software (packet forwarder) do you use on your hardware? And is the ic880a used with an RPi?
BTW, if your gateway serves other people’s applications besides your own (that you have migrated to V3) then it would help if you can hold of migrating. Gateways on V3 do not deliver data to V2 applications (things do work the other way around). So once you move your gateway all applications on V2 that relied on it break down.
Note the Cayenne integration is not yet implemented for V3 and may be a while… 
Stay V2 for now if that is important…
We know that it’s not really deleted from the database, but I hadn’t heard you could put the settings back and still have it work, even if you can’t see it on your console. Nice solution.
That only works for UDP gateways and possibly Basic Station (never tested that one). A new UDP gateway can forward traffic to TTN without being registered as well.
Hi Jac. what abut ProtoBuf/your MP Frwdr based gateways?
These can’t contact the backend without a valid registration so if you ‘accidentally’ delete one you need to register a new gateway. Registering it requires choosing a new name, that can simply be the old name with a suffix added to it.
To register them with V3 you need to create an API key with the right permissions (“Link as Gateway to a Gateway Server for traffic exchange, i.e. write uplink and read downlink”) and use “eu1.cloud.thethings.network:1881” as the server address.
Use the “Gateway ID” as user and while creating the gateway on V3 leave the EUI field empty.
Hi Jeff,
I am desperately trying to get back to a proper working V2 setup on the gateway.
V3 is a disaster (at least for me).
I will rebuild my gateway ic880A-spi from the learning lab’s pages, I will replace the RPI so the MAC address will change without the need for me to hack it. I will register the gateway as new on V2 with the new EUI and see if it will fly again. If not then I may consider to terminate my membership with TTN and go to a fully private network or go to a professional server. KPN IoT or something for devices out of range.
If you are looking for help it would be good to mention what is and what is not working. If you just want to vent frustration, keep in mind the moderators are also just community members.
From community point of view it would be a loss if you leave TTN. However you are free to do so. With regards to V3 the entire community is in the same situation, some things work, some don’t (yet). That is why from the minute V3 was announced and it became clear not all traffic would be routed back to V2 we started warning people not to move gateways yet because that could severely impact use cases. The banner on the console TTN added explicitly mentions applications and devices, no mention of gateways.
Please ask if you need help getting the gateway up and running, don’t forget to mention which set of instructions you are using in that case (url helps)
That will work 
I have a large fleet of (various) RPi based GW’s and have had occasional Pi failures where I have then done just that and all good (Note for others: dont just delete old RPi based GW - you never know you might get chance to fix going forward)
Otherwise I echo Jac’s sentiment, we do what we can and try to advise best practice as we see it develop - its early days for the V2-V3 migration as yet 
BTW one option (I assume you are using something like the TTN Zurich build for your iMST/RPi combination (I have some the same) using UDP/Legacy Semtech packet-forwarder and registered using EU-12345FFFe67890 type namig? If so try redoing your GW on existing Pi but swap over to Jac’s MP Forwarder and use a descriptive name (do a new GW registration) for the IDs etc. Havent tried but that may bring back for you? just 
Have a look at GitHub - ch2i/LoraGW-Setup: SX1301 Lora Concentrator Raspberry PI based gateway setup
Follow and input build options & just make sure you go to
/opt/loragw/start.sh
When build finished and check last line is showing:
./mp_pkt_fwd.sh
and not:
./poly_pkt_fwd.sh
Good luck (Let us know which way you try and how successful please!)
The install script may well generate an EUI based on the Pi’s MAC address, but it’s not actually an official EUI as such. So you don’t have to swap Pi’s, just change the global or local json conf file to subtly alter the ID/EUI that’s in the config and then register with that.
This is not normal procedure and not recommended and the whole EUI from a MAC address isn’t ideal either, but needs must some times.