I purchased a The Things Indoor LoRaWAN Gateway.
I have set it up, greenlight is on.
I have registered the gateway in the The Things Network Backend.
However, the status displays: Disconnected.
could it be that the Gateway is unable to reach the outside world from my home network?
Doubtful as all my other devices are able to reach the outside world. And I can see that the gateway has been given an IP address by my DHCP server.
Does the Gateway have a login where I can do some debugging (ping, tracert etc)?
Could it be related to V2 => V3 upgrade?
Is there anything I need to do here?
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
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.
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.
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.
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.