The Things Gateway shows status: "not connected"

So when the engine warning light in my car is on, but the car still is running properly, it’s “operating as expected”? The issue seems to be that way for more than 4 days and the only reaction is “but it’s working, isn’t it?”. The connected/not connected indicator is especially important for people with multiple gateways in remote locations. Being able to monitor them without sending test data is essential.

  1. Have you checked if ttnctl provides the same status? I’ve been using it for years to monitor my 15+ gateways and it rarely is wrong about gateway status. Last weekend it showed all gateways using a certain connection off-line and ‘surprise’ there was an issue and it was resolved asap by TTN

  2. You sound like you feel you are entitled to something. If you feel that way, move to TTI, the network with SLAs. The community network is run on best effort base and costs TTN money to keep up and running while not generating any income. They decided not to invest time to resolve this particular issue and focus on getting the next generation software up to the point where we can all benefit from it. That version was designed with the experience of what does not work in the current generation in mind and should not suffer from these failures. (There will of course be other issues as no software is ever perfect)


I reported the console showing “offline” when gateways are in fact online. It doesn’t matter what other services show different results. That single component does not work. In fact, it would be far worse if other components were also failing and showing bad results. What kind of argument is that?

No, I reported an issue with the free service you are providing, to which arjanvanb was quoting that it’s working “as expected”, to which I disagreed.

Please keep your combative attitude to yourself. It’s not constructive. There’s an issue with the console not showing correct information, and the time spent on arguing about it is completely wasted. It’s currently broken and not working “as expected”.

Welp, I spent a bunch of money on a gateway by the same company, for a product that was defective right out of the box, but you don’t see me complaining about having to fix it myself, do you?

Overall, do you have a problem with your users reporting issues with your service? I reported an issue, and all I get is backtalk. A simple, “we are working on the issue, but it’s not our first priority” is all it would have needed.


The only service I provide to you is moderating this forum. I am not employed by TTN, don’t get any money for the many hours I spend trying to support forum users, just a lot of attitude by people that find they are entitled to things.

TTN is aware of the issue. As I explained they decided to spend their time on other things and not to work on resolving this known issue. I understand you don’t agree.


Have you checked if ttnctl provides the same status?

Okay, let’s try it:

$ ttnctl gateways info 19711137
INFO Found gateway                           

      Gateway ID: 19711137
  Frequency Plan: EU_863_870
          Router: ttn-router-eu
     Auto Update: on
           Owner: markruys
    Owner Public: yes
 Location Public: yes
   Status Public: yes

           Brand: MultiTech
           Model: Conduit mLinux
     Description: xxxx EU868
      Access Key: xxxx

   - Username: markruys
     Rights: gateway:settings, gateway:collaborators, gateway:status, gateway:delete, gateway:location, gateway:owner, gateway:messages

So this doesn’t show me whether the gateway is online. Or do you use another ttnctl command?

Although I don’t sympathize on how @milanoengineering makes his point, I do find it annoying that suddenly for some of our gateways the status is not updated anymore at the TTN console.

Off topic, a few days ago we also saw that US915 configured gateways with a EU router suddenly started to receive downlinks on EU868 channels from the NS. These gateways refused to process the downlink so now no join requests get an ack anymore.

You’ll need ttnctl gateways status.

ttnctl gateways status 19711137
  INFO Discovering Router...                   
  INFO Connecting with Router...               
  INFO Connected to Router                     
  INFO Received status                      GatewayID=19711137

           Last seen: 2020-05-15 17:17:50.685704614 +0200 CEST
           Timestamp: 0
       Reported time: 2020-05-15 17:17:50 +0200 CEST
      Frequency Plan: EU_863_870
              Bridge: gs.v3.
            Location: not available
                 Rtt: 46ns
                  Rx: (in: 29; ok: 6)
                  Tx: (in: 1; ok: 1)

Yes, perfect, this shows my gateways to be connected indeed. Thanks, Mark

What an interesting spin to give users who report issues, issues where they don’t even know if they’re at fault, or if the network is faulty. No one feels entitled by reporting an issue with a service. I understand you being frustrated when people complain about stuff you have no control over, but the users don’t have control over it either.

Please look at my first post. I asked what the problem is, and what comes back is “operating as expected”. If anything, that’s seems to be an entitlement to be a smartass to users. “Buy an SLA if you want proper service, you freeloader”. What an attitude to have.

What I saw in the first 3 posts was 3 users who didn’t even seem to bother to search for existing reports about this, nor provide much detailed information.

1 Like

After you reported a known issue that has gotten coverage a couple of times already on the forum and get quoted the official TTN statement regarding this (please visit the official status site to check for it yourself) you respond with a story regarding engine lights. Have you reread your own response and judged it not sounding like you feel entitled?

May-be we should conclude things are as they are. Neither the users nor the moderators can change the decisions made. If you don’t agree, this forum is not the place where you can challenge TTN on their decisions. Don’t ask me what the right place is, I haven’t found it yet…

1 Like

I was perplexed by something being broken, yet “working as expected”.

I checked the official status page, there was an entry from “Jan 27” (no year, on none of the entries). Not sure how relevant that is or can be.

Anyway, you explained the issue, basically the TTN people will work on it whenever they feel like it, as the issue seems to persist for months now, and besides the status and traffic console everything is working fine. Users (like me) just have to deal with it.

TTN is a free to use service, so solving issues like this is probably not a priority.

2 posts were merged into an existing topic: Can’t access TTN Console, ttnctl fails, TTN Node-RED library fails, and Kickstarter gateways get stuck after daily reboot

Thanks, this showed my gateways are connected. Never knew ttnctl existed…:slight_smile:

Same issue here. Gateway is not registered in TTN console. I cannot run ttnctl because I make a install and this command not work from terminal.
Also in TTN traffic didn’t see anything as last week.


You can install and run ttnctl anywhere:

ttnctl gateways status pruebas_leon
  INFO Discovering Router...                   
  INFO Connecting with Router...               
  INFO Connected to Router                     
  INFO Received status                          GatewayID=pruebas_leon

           Last seen: 2020-05-18 11:53:59.389490752 +0200 CEST
           Timestamp: 0
       Reported time: 2020-05-18 11:53:59 +0200 CEST
      Frequency Plan: EU_863_870
              Bridge: gs.v3.
            Location: (42.581059, -5.534930; source unknown)
                 Rtt: 62ns
                  Rx: (in: 24; ok: 0)
                  Tx: (in: 0; ok: 0)

Ahh, ok thanks a lot. So, it’s working ok then?

I cannot see any traffic. unfortunately I haven’t any device at hand to test it. Hope can test it in few days.

Thanks a lot!


Yeah, not seeing traffic in TTN Console is quite annoying and I don’t know of any other way to see gateway Traffic without depending on that NOC component. Also, I don’t know how the Rx and Tx metrics in the output above are calculated. (The source code might reveal that.)

Of course, without TTN, one might still be able to peek into the raw gateway logs; isn’t that something that Balena offers? When you’ve got devices you’ll surely see their traffic just fine though.

I can only see main log but no realtime traffic…

like this:

18.05.20 12:22:33 (+0200) main ##### 2020-05-18 10:22:33 GMT #####
18.05.20 12:22:33 (+0200) main ### [UPSTREAM] ###
18.05.20 12:22:33 (+0200) main # RF packets received by concentrator: 0
18.05.20 12:22:33 (+0200) main # CRC_OK: 0.00%, CRC_FAIL: 0.00%, NO_CRC: 0.00%
18.05.20 12:22:33 (+0200) main # RF packets forwarded: 0 (0 bytes)
18.05.20 12:22:33 (+0200) main # PUSH_DATA datagrams sent: 0 (0 bytes)
18.05.20 12:22:33 (+0200) main # PUSH_DATA acknowledged: 0.00%
18.05.20 12:22:33 (+0200) main ### [DOWNSTREAM] ###
18.05.20 12:22:33 (+0200) main # PULL_DATA sent: 0 (0.00% acknowledged)
18.05.20 12:22:33 (+0200) main # PULL_RESP(onse) datagrams received: 0 (0 bytes)
18.05.20 12:22:33 (+0200) main # RF packets sent to concentrator: 0 (0 bytes)
18.05.20 12:22:33 (+0200) main # TX errors: 0
18.05.20 12:22:33 (+0200) main ### BEACON IS DISABLED!
18.05.20 12:22:33 (+0200) main ### [JIT] ###
18.05.20 12:22:33 (+0200) main # INFO: JIT queue contains 0 packets.
18.05.20 12:22:33 (+0200) main # INFO: JIT queue contains 0 beacons.
18.05.20 12:22:33 (+0200) main ### [GPS] ###
18.05.20 12:22:33 (+0200) main # No time keeping possible due to fake gps.
18.05.20 12:22:33 (+0200) main # Manual GPS coordinates: latitude 42.58106, longitude -5.53493, altitude 868 m
18.05.20 12:22:33 (+0200) main ### [PERFORMANCE] ###
18.05.20 12:22:33 (+0200) main # Upstream radio packet quality: 0.00%.
18.05.20 12:22:33 (+0200) main ### [ CONNECTIONS ] ###
18.05.20 12:22:33 (+0200) main # Connected
18.05.20 12:22:33 (+0200) main # Semtech status report send.
18.05.20 12:22:33 (+0200) main ##### END #####
18.05.20 12:22:33 (+0200) main 10:22:33 INFO: [TTN] RTT 67
18.05.20 12:22:33 (+0200) main 10:22:33 INFO: [TTN] send status success for