I added my TTIG yesterday. It shows not connect when ever I a have a glance in the console.
The console shows last seen 8 hours ago.
eui-58a0cbfffe801ffa
Any ideas.
I added my TTIG yesterday. It shows not connect when ever I a have a glance in the console.
The console shows last seen 8 hours ago.
eui-58a0cbfffe801ffa
Any ideas.
Same here. Just installed and connected my new device (TBMH100) but it won’t connect. The UART logging shows (had to invalidate the URLs, coz of new user 2 links restriction):
1970-01-01 00:00:07.246 [CUP:INFO] Starting a CUPS session 1970-01-01 00:00:07.255 [CUP:INFO] Connecting to CUPS … hxxps://mh.sm.tc:7007 (try #1) 1970-01-01 00:00:07.267 [any:INFO] cert. version : 1 serial number : 01 issuer name : CN=Root CA, OU=TrackCentral (ez5Cj0eN), [O=TrackNet.io](http://O=TrackNet.io), C=CH subject name : CN=Root CA, OU=TrackCentral (ez5Cj0eN), [O=TrackNet.io](http://O=TrackNet.io), C=CH issued on : 2018-11-22 10:23:38 expires on : 2024-11-20 10:23:38 signed using : ECDSA with SHA256 EC key size : 256 bits 1970-01-01 00:00:07.293 [AIO:INFO] cups has no cert configured - running server auth and client auth with token 1970-01-01 00:00:07.387 [CUP:VERB] Retrieving update-info from CUPS hxxps://mh.sm.tc:7007… 1970-01-01 00:00:13.955 [SYS:DEBU] Free Heap: 26168 (min=25664) wifi=5 mh=7 cups=1 tc=0 1970-01-01 00:00:14.057 [any:VERB] Failed to retrieve TCURI from CUPS: (404) Not Found 1970-01-01 00:00:14.061 [AIO:DEBU] [2] HTTP connection shutdown… 1970-01-01 00:00:14.068 [SYS:INFO] sys_inState - Ignoring state transition: 5 1970-01-01 00:00:14.071 [CUP:INFO] Interaction with CUPS failed - retrying in 1m 1970-01-01 00:00:14.075 [TCE:INFO] Starting TC engine 1970-01-01 00:00:14.080 [TCE:ERRO] No TC URI configured 1970-01-01 00:00:14.090 [TCE:INFO] INFOS reconnect backoff 0s (retry 0) 1970-01-01 00:00:14.093 [TCE:ERRO] No TC URI configured 1970-01-01 00:00:14.096 [TCE:INFO] INFOS reconnect backoff 10s (retry 1)
Finally, the issue was an unprovisioned gateway. My vendor forgot to unlock the device. I was able to detect that with the following POST request (substitute with your gateway id):
$ curl -k -i -X POST --data '{ "router": "xx-xx-xx-FF-FE-xx-xx-xx" }' https://mh.sm.tc:7007/update-info HTTP/1.1 404 Not Found Content-Type: text/plain; charset=utf-8 Content-Length: 15 Date: Sat, 02 May 2020 21:13:07 GMT Server: Python/3.6 aiohttp/3.5.4 Connection: close Not Provisioned
Especially thanks to @KrishnaIyerEaswaran2 who assisted even on a Sunday!
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.
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
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.)
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.