???
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.
Maybe because you said you never wanted to have a private instance and it’s really not clear why you have one and we are all volunteers here so we try our best to answer with the information available / as presented to us and it appeared you were hoping to change the end point to TTS CE.
OK, but you also said
Why not try the Community Edition?
What is the CLI for - what have you done with it / tried?
It shouldn’t and it doesn’t - I have TTIGs on private instances. Your challenge is that a Discovery instance is for those who want to use a private instance as part of a move to a paid for instance. So it you are have ground to a halt, you need to contact support for your instance and for the private instances, that’s a paid only option.
So the authentication is back on and you haven’t touched the LNS key?
What is logged in to the console? The TTIG won’t be logged in to it in the sense that it’s software looks up where it should get its details, calls the gateway server component that then sends it all the details and any firmware updates.
I’d definitely go for the thirty second test of setting it up on TTS CE, at which point you can then ask TTI support nicely about the TTIG if it transpires its as confused as we all are. And once that’s working, you can then chose to claim it on the private instance.
1 Like
We aren’t we are suggesting you try and avoid it (accidental hybrid). YOU said you would remove Montana from front end - which makes it private tenant - as if looking to try on CE, but with the .industries that would not work so I said you would (also) need to change to .network for it to be TTN… between two stools you find the floor is an old expression that might well apply what you may have ended up with is a hybrid between the two. If you are running private no issues, stay with the Montana.nam1… address and log into console using Montana.region as directed by Nick. 
It might even be worth going all in on TTN implementation as that is what we (the community and 98%+ of Forumites) are most familiar with to see if your gw works there and is debugged. Then switch back to trying to migrate to a private instance? Just thinking aloud…
1 Like
Sorry to disappear for a while. On the evening of Mar 8 I suffered an injury which put me out of commission for a spell. All’s well now, and I just re-visited this today.
I am still very confused as to why things did not work in my discovery account, but I’ve left that in the past for now, as I have taken all the advice to simply
Try it on TTS CE!
I deleted the gateway from The Things Stack Cloud and claimed (not added for heaven’s sake!) the gateway on The Things Network aka The Things Stack Community Edition. Yeah, I can’t imagine how someone new could possibly become confused with all the clearly differentiated nomenclature… 
Thanks for all the help. The status light is now solid green, although the overview status shows “Disconnected” and there are no Attributes appearing in the General settings. I figured I would be patient for at least 24 hours, and then delete the gateway and try again if nothing changes.