LOL, YMMV!!!
At the end of the day, on here, when asked about the little connection dot, we will almost always tell you how optional it is and how the acid test is, does it blend erm, does it hear & pass on uplinks. So whilst you may see stat messages in the Live Data, you need to see traffic to be 100% sure.
Please do, I’ve been asking for a while.
When it comes to GW’s the ONLY thing that really matters is do they pass traffic? Irrespective of what connection status says! And that’s where I agree with Nick that you need traffic to be sure (listen to the voice of experience! 
)
In V2 we have had a problem where GW’s would show as not connected - but a check in devices & apps would show traffic still routing through correctly = result!
Krishna correctly identified how systems and TTN back end ‘should’ behave but as Nick mentioned you need traffic to be 100% sure.
By way of example there was a recent multi-hour outage on V3 (TTS-CE) where they shed >1/3rd of previously connected GWs. Checking V3 console correctly showed my two recently (last month or so) added V3 test GW’s as disconnected. The system recovered and Console GW list showed them both connected again. A seperate issue I was seeing a day or so later where I wasnt getting expected data in a V3 TTNMapper integration led me to dig deeper - the two GW’s are in close proximity but slightly different locations and elevations which I know causes slight difference in coverage on other side of valley 1-3k away. When I dug into the V3 console I could see both GW’s showed connected and individually both GW’s looked to be online… I could see regular stream of traffic from trackers and a series of local static nodes on testgw041 but testgw040 was just sitting there showing ‘connected’ in the console (GW must have been happily sending its keep alive update messages & stats messages per Krishna’s comment) but live data window was empty and was telling me its was “waiting for…” i.e. no traffic was being seen/forwarded. I waited 24hrs to see if system recovered as part of the behavioural tests I was running. No joy so at that point I simply restarted the GW by power cycling it (suspect the GW PF stopped as a result of the connection being lost or a new connection being established _ didnt bother looking at the logs), instantly on recovery Console started to show the local node traffic comming through = result!. Without known local traffic, and fact it was missing, I would have happily have assumed GW was fine as V3 was showing all connected.
TL:DR = You need traffic to be 100% sure 
Again, I don’t have the science to back it up, but ditto. v3 gateway apparently online but no traffic - reboot it, all suddenly sprang in to life.
The challenge is find a place to put a gateway that can’t hear any devices to do tests like this - I don’t have a wine cellar anymore.
So the Ah-ha moment did come to truth as soon as I changed the server pointing on the gateway. Just a dumb mistake on my part and it in front of me all along. I’m well seasoned with radio systems and just had a blind spot.
On the issue of the necessity of having traffic I’ll offer that in any good network system design all the parts play their role. Certainly having a system for confirmation that the gateways are seen by a Network Operating Center is an important tool in fault detection and isolation toward overall remedy. In my case it took the Application/Node component out of my startup equation and got me going without the having to deal with the complexities of simultaneous faults on the application/node side.
BUT as you all are suggesting; through and throughput testing are essential for true confirmation of stable operation in the network and even then performance verification and stability have a lot of parts. That’s where good system design, testing and verification practices are in place. I see a lot of effort by this group to establish a seriously reliable and manageable network using this (these) technologies; that’s kind-of why I took an interest.
Thanks all for your help to get me launched and I’ll return the favour by helping RAK update some of their language on github so new users get on V3 from the getgo,
Peter
V3 does not have a NOC. In V2 that proved to be one of the bottlenecks when it comes to scaling so V3 has been designed without a NOC.
Yes … These are interesting conceptual design points of modern networking. As I see it anyway, TTN is much like TCP/IP in nature, that it is infrastructure where distributed components are connected, managed and monitored by their respective owners; it just sits on top of other infrastructure - how great is that. Users of the TTN establish their own methods to monitor performance and to remedy faults across the whole system.
It could be a long (rather enjoyable) discussion of network management, reliability, fault discovery and remedies etc … but for my part I just like it 
… and a team of people who pour their talents into making it successful. I have some history in big networking systems and I can certainly say that establishing this with demonstrated user directed responsiveness is a remarkable thing. 
You make up the ID to suit your ID naming requirements.
You put the Gateway EUI in to, well, the EUI field.
Read the data entry labels and the error messages and please do not double post.
How did you choose the EUI? Is it on the gateway itself?
Please skip my stupid question. I already fixed it.
Hi, I’m still learning basics. I got my The Things Indoor LoRaWAN Gateway and tried to set it up in The Things Network following the instructions at Add Gateway .
I wasn’t that successful so I deleted my gateway and now I realised I shouldn’t done that. I now get ID already taken when I try to register again. How to proceed?
Use a different ID.
The ID is NOT the EUI but both have to be unique to TTS CE.
So I’m guessing “my-cute-gateway” will be taken already.
Hi,
I am trying to migrate a gateway from v2 to v3
***************** is already registered as ******)but i cannot see a gateway with this EUI in the list.
As of https://www.thethingsindustries.com/docs/reference/id-eui-constraints/#deleted-entities
the EUI should be released when the gateway is deleted.
How can this be solved?
Are you 100% sure that you re-typed the EUI correctly? ie you haven’t entered one that is registered for someone else?
There may be some delay in having the EUI purged from the in-memory database &/or the back-end database - maybe @htdvisser could comment?
I am sure i typed the correct EUI
Sure or definitely?
You can either try it again to be sure, or we can sit and wait to see what happens …
i am definitely sure
tried that again and i still get the same error
I’ll wait a bit more and see what happens
These two chaps know about the gateway server.
@KrishnaIyerEaswaran2 @adrianmares
But it may be the network server, or the console, but one of the three I’ve paged should be able to point us in the right direction.
I’ve also posted on Slack - as this sort of info is going to be vital as more people get stuck in to the migration tango.
Thank you very much for the quick replies and the help
There should not be any delays.
@xperiencelab if you send me the EUI of your gateway I can try to see what’s going on.