New to TTN - my gateway status: disconnected

Gateways TTIG - The Things Indoor Gateway
1

Hi,

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?

Thanks, PeterK

2

Yes! First search for and read existing related information and questions already answered on the forum.

1 Like
3

I tried that…
You are not being helpful.

3 Likes
4

Did you use the instructions at (claiming your gateway) The Things Indoor Gateway | The Things Stack for LoRaWAN ? If not delete the gateway and start over. You will need to ‘invent’ a new gateway ID (which is not the gateway EUI and has no relation to an EUI).

1 Like
5

Yes, I followed the instructions in the manual and registered my gateway at The Things Stack.
Do you see anything out of the ordinary?

screenshot TTN

6

Did you claim your gateway or register it? There is a vital difference and the gateway page does not show which way you added the gateway.

1 Like
7

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?

8

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?
9

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):

Screenshot 2021-07-10 at 12.32.59

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
10

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.

11

???

Or claimed, like the instructions say?

1 Like
12

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.

13

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
14

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.

15

Anyone finding this thread, here’s the relevant bit at the top of that link:

Screenshot 2021-07-14 at 13.13.47

2 Likes
16

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

17

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.

Screen Shot 2022-03-07 at 4.16.34 PM

18

Clarification - do you have a TTI paid for or discovery instance?

Why is Authentication turned off?

1 Like
19

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
20

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.