Hi,
same issue. After normal setup procedure, status changed to “not connected”, despite green led is solid.
eui-58a0cbfffe802225.
Best regards,
Jo
My gateway was recently offline, too (last 6 hours). Turning it off and on again solved the issue.
How do you determine it being ‘offline’? Could you please characterise it in a bit more detail? What is the state of the LED?
Hello,
also the same issue.
It is not connecting.
eui-58a0cbfffe80295f
Any tipps?
My TTIG is still listed as online.
My Raspberry Pi + RAK831 however is listed as “Last seen 7 days ago”.
Sometimes (once every few months - that’s at least when I notice it) the Pi based gateway is listed in TTN console as not online.
I thought this was caused by a hickup of the gateway and when I detect it, I just reboot it (without actually checking if it is truly offline or that TTN console just reports an incorrect status).
The reboot usually makes it listed as online again.
So today when I noticed “Last seen 7 days ago” I just rebooted the Pi gateway.
After reboot the TTN console still shows “Last seen 7 days ago”.
But in the Application Data tab I just see messages coming in and the Pi gateway listed as “Last seen 7 days ago” is listed as one of the gateways that received the message. So while it is listed as offline it is just working.
1 Like
Wasted a huge amount of time trying to debug GW’s over weekend and Monday and tracking some of the outages and \Console issues flagged by others in recent days (changing back haul connections, changing/reprogramming Wifi links & router connections, multiple reboots, pinging GW’s to confirm on local connections, pinging external servers from GWs to confirm they had viable internet connections, doing software rebuilds etc… 
) . Like you mine are showing Last seen 7 Days ago now… problem is I have 11GW’s currently in that state (out of 30+)… I finally followed Jac’s (@kersing) suggestion to another forumite and loaded up ttnctl yesterday and after a bit of a battle (meatware problem and lack of experience on my part I guess!) finally managed to get all my GWs listed and worked through status of each in turn confirming they were online (well most of them!) problem is its laborous compared to just a quick eyeball scan down the Console GW page and fact 2 TTIG’s and a TGW cant be seen (‘gateway ‘ID’ not found’) and looked to be stuck offline despite fact they have been rebooted a few times and in the case of the TGW have 4 stable leds. Console inadequacy is unsustainable esp as number of GW’s escalates - have more waiting to go online but cant be bothered until I can be sure I can see them online and wont be wasting my time debuging status or backhaul issues where real problem is its just the Console misreporting
3 Likes
Hi, same issue here…
eui-58a0cbfffe80277f
‘not connected’ while LED is solid green…
I wish I had a solid green LED its flickering:
green, then green/red and green again…
Hi, same issue here…
‘not connected’ while LED is solid green…
There is currently a known issue with the console showing gateways offline when they are working just fine.
Either check for data flowing through the gateway or use the ttnctl command line app to check it
Ok, I’m online and connected. And my sensor is sending it’s data. So everything works now.
The only thing that I changed, was the wlan. It looks like the Gateway likes the telekom router more than the linksys with openwrt.
The Gateways in Chandler AZ are down again. Can someone look into this? The gateway IDs are:
ahwatukee-foothills-phoenix-az
microchip-wsg-chandler-az
microchip-wsg-chandler-az-wide
Rebooting the gateways did not restore the connection.
Thanks,
Picworker
That doesn’t look like TTIG ids, which are EUI-based? Also, when reporting elsewhere, please explain what “down” means: are you not seeing any packets forwarded to your application(s), or is it “just” that TTN Console doesn’t show their status and traffic? (For the latter: that’s a known issue, like you can read above.)
1 Like
Hello,
The devices are original TTN Gateways, model: ‘The Things Gateway’. When I mentioned they were down, I meant they were no longer connected to The Things Network.
All (3) gateways are connected again now.
Thanks
eui-b827ebffffeb208f
Hi All,
I have a very strange problem that may be related to this. My TTI Indoor Gateway, eui-58a0cbfffe802629, only reports a momentary connection when I reboot it. Then it will time out and get marked not connected. My applications are still reporting traffic through that particular gateway on TTN Console and the stats display on TTN mapper. TTN console never sees gateway traffic. This was not always the case, my stats are stuck at Received Messages 30318 and Transmitted Messages 3199. This began a couple of weeks ago. Nothing that I can do at my end resolves the problem. I have tried a factory default, connection to other TTN routers throughout the world. I am normally connected to ttn-router-us-west since I am located in California USA.
I see many similar reports that go back to 2019 but no reports of the actual cause or a solution.
There is some discussion comments that go like this, " If you invest some time you can read the BasicStation back-end protocol is not supported by TTN Community Network V2. It will be by TTN V3."
and this,
"Reason:
As some of you might know, our V2 stack does not support the new BasicStation protocol and hence we have a temporary/experimental BasicStation-Bridge that bridges the TTIG to our V2 routers. This bridge is functional but breaks at scale which is what’s happening here). I have added some load-balancing in the backend which should keep it functional.
In the next few weeks, we will be replacing this bridge with a native, highly scalable component which will ensure that these kinds of outages don’t happen." – July 2019.
Is there a back end outage to the BasicStation-Bridge? Or a bug from a recent update?
This is a real problem if you are using TTN Mapper and you need to reboot your gateway every 5 days to prevent its deletion from the map.
Did you see the post above yours?
I do. I am really wondering if there is something here that needs more attention than just the TTN console. Is TTN Mapper just pulling its data from TTN Console via the API? Is the problem related to the new protocol used with the Indoor Gateway? Is it the TTN Console? Is there something that I might have missed that I could do to fix this? Please remember that I saw a similar discussion a year ago so I am really trying to see if I missed something at my end. Any help and advice would be welcome. Thanks.
No there is not. There are known issues with gateway state in the console which are not related to the protocol used to connect the gateway to the back-end.
TTN Mapper currently relies on the same data set because querying the status of all known (to TTN Mapper) gateways takes too much time. (Search the forum and you will find messages concerning this.)
You can head over to the TTN slack #ops channel and shout out hoping someone will be able to reset whatever isn’t working right.