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.
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
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?
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.
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…
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.