Ok that is helpful.
I am sure that i added the gateway with the “add gateway” button.
In what way “claim gateway” differ from adding a gateway?
Ok, I used Claim Gateway. It errored out stating that the EUI was already registered.
I then removed the entry from the “add gateway” and submitted the Claim again.
It still reads disconnected.
I then unplugged the Gateway. Waited 30sec and plugged it in again.
It still reads disconnected.
So let us think for a moment here, what I am trying to create
- is the TTN IG device trying to connect to the The Things Stack Cloud server by default?
- So all I’m doing is registering the traffic at the Cloud server as traffic from my device?
We don’t need to and you are not trying to create, your just need to do, albeit with the potential for glitches, it’s a clinical procedure without room for creativity.
Assuming your gateway is still not showing connected, given on startup it has to connect to your WiFi then connect to the internet then connect to a server to get it’s configuration and then connect the NS to start up, so 30 seconds is a bit tight, can you check if the extra BasicStation info has appeared in the gateway settings (menu on the left will get you there, scroll down a bit, it appears after the description box, gateway server address & required authentication):
You should expect the LNS key and the three attributes. The numbers/entries/details will not necessarily be the same.
If you can’t see any of this stuff, then delete the gateway and re-claim it.
You will not be able to reuse your gateway ID so think of another one, like beez-gateway.
PS, the public bit is optional, I turned it on because I’m a nice TTNer
1 Like
I’m seeing the same with a newly purchased Things Network Indoor Gateway. I’ve added it in the console and can see live data being sent through the gateway to my application, but the gateway always shows as disconnected.
I’m using eu1.cloud.thethings.network and EU_863_870_TTN.
So all seems OK except for the disconnected status.
???
Or claimed, like the instructions say?
1 Like
Interesting.
I unplugged my gateway this evening. I waited for an hour or so. Went for a walk.
Then I plugged it back in. Online within 10 seconds.
Great.
Now I’ll create a temperature device to monitor my beehives.
It wasn’t the length of the walk that did this, it was the fact the TTIG retrieves it’s settings on startup or approximately once every 24 hours. Power cycling the device has been highlighted in several places.
Good luck with the bees.
1 Like
Yes, my bad, I found the instructions at https://www.thethingsnetwork.org/docs/gateways/thethingsindoor/ first, and these did not mention claiming. Now deleted/claimed and my gateway shows connected state.
Anyone finding this thread, here’s the relevant bit at the top of that link:
2 Likes
Thanks a lot @descartes
I’ve added a PR here to remove the duplicate info there and have a single redirect to the TTS Docs
I am opening myself up to critique for responding to an old thread or not reading enough first… go ahead and fire away…
I had an indoor gateway connected to V2. I just last week got around to migrating to V3. I read the instructions in the doc referred to by the URL above. Everything seemed fine, except now I have run into the block I’ve seen others hit, namely the fast blinking green.
Therefore, there is no problem with my WiFi setup, but the gateway status is always ‘Disconnected’. The live data indicates there has been some communication, and the ‘cups-last-seen’ attribute is very recent. I did not use the same gateway-id when I reclaimed it under V3.
I’ve restarted, and followed the other advice under the Troubleshooting link, but to no avail. Not sure what else to do or look for.
Clarification - do you have a TTI paid for or discovery instance?
Why is Authentication turned off?
1 Like
So you tried to claim this and connect to a private TTS instance or by V2/V3 reference are you saying you want this on TTN TTS(CE) aka TTN V3?
(Montana.nam1.cloud.thethings.industries vs. nam1.cloud.thethings.network)?
And would need authentication with associated LNS key enabled…
1 Like
Thanks for quick responses.
I have a discovery instance.
My memory from last week is a little hazy, but I think I unchecked the ‘Require authenticated connection’ because the help states “This will only allow a gateway to connect if it uses a TLS enabled Basic Station or MQTT connection.” I probably thought trying a fallback to a more permissive connection might work. It was probably originally checked by default, but I don’t remember.
I am guessing from both comments that this authorization should be enabled.
Hmm, a “private” instance. I didn’t ever wish to connect to a private instance. As far as the ‘Gateway server address’ goes, I accepted the default.
If I remove the ‘Montana’ from the beginning of the gateway address, the connection status then changes to ‘Other cluster’, and tells me “This gateway is connected to an external Gateway Server that is not handling messages for this cluster. You will hence not be able to see any activity from this gateway.” That doesn’t seem good either.
I have now enabled authentication. When that didn’t change things, I then tried again to power cycle (with over 5 minutes off). This didn’t change the connection status.
You signed up for a private instance …
Well, no, because you are tell it to connect to the community servers, which you can do, but you end up with a configuration that would be outside the norm. You either put it on TTS CE or a TTI instance, but putting it on a TTI instance pointing at TTS CE would be ‘interesting’.
The connection status can often be misleading - as per forum search - the acid test is if a known good device is seen to be heard by the gateway - which you can see in the gateway console log.
1 Like
Not unless changing the .industries to .network, just removing the ‘montana’ from front won’t work
@MontanaMac you need to commit wholly to one or the other, a hybrid attempt won’t work 
(and IIRC the LNS key needs to come from the instance used, haven’t tried but suspect key from private won’t/may not work with (CE) and vice versa. …and yes needs to then be enabled 
1 Like
I do appreciate the help and know it can sometimes be frustrating to deal with new users. I promise I have tried to read all I can, and thought I was following instructions. However, I am not even sure how to tell the difference between community and private instances. I am not trying (on purpose) to create a hybrid invocation.
I followed the docs which said I must register this indoor gateway by the claiming process. Upon starting the claim, I am presented with this form:
Nothing there allows me to choose community vs. private.
Yes, when creating my account I did choose the Cloud option with the Discovery option. I would not think these choice would have any bearing on the claiming of the gateway, but if they did that would be reflected on the options on claim forms.
As an experiment now, I have tried changing the gateway server address to ‘nam1.cloud.thethings.network’, but that just results in the same ‘other cluster’ status.
Okay, sorry for my ignorance. So, by signing up for a Cloud account, I put my future gateways in a ‘private’ instance category. Therefore, since my tennant-id is ‘montana’ and I’m using the North America 1 cluster, my gateway address is indeed ‘montana.nam1.cloud.thethings.industries’.
What I can’t figure out then now is what part of this configuration identifies the gateway on the community edition?
Nothing. They are separate. You use one or the other. You can have gateways peer between networks. But it’s an either-or situation.
You do that when you log in to the console - log in to a region.cloud.thethings.network and that’s the community, log in to qqq.region.cloud.thethings.industries and that’s a private one.
It really is as simple as using just one of them.
1 Like
Okay, then I am very confused as to why @descartes and @Jeff-UK are telling me that I am attempting a hybrid approach, or that I was ever using or attempting to use the community edition.
I have always been logged in to montana.nam1.cloud.thethings.industries on the console. I successfully configured (as far as I can tell) the CLI and am logged in there using the montana.nam1.cloud.thethings.industries server addresses.
So the way things stand is I have a valid gateway config with authentication and LNS key. Logged into a private cloud console, but still have the fast blinky green light and disconnected status.
I certainly don’t expect you two responders to solve my troubles, but I’ve read all the docs I know of, and tried everything I know to try. I’m not sure where else to turn, but I’ll keep searching.