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.
Thank you for the suggestion. I posted the request.
Please do not expect a response - it’s been made clear (above and all over other forum posts) that this is not going to be fixed.
1 Like
Not going to ever be fixed – Or is the expectation that TTN V3 is the fix?
It won’t be broken in v3 but it may be different!
We have a known issue related to our v2 “NOC” service that sometimes shows online gateways as offline. We are not going to fix this issue.
Another known issue is that Basic Station gateways experience websocket timeouts. This is fixed in the new 2.0.4 and 2.0.5 firmware versions that are currently being tested. Maybe @KrishnaIyerEaswaran2 can comment on this.
And as @descartes just wrote: in v3 things will be different.
3 Likes
@htdvisser, @johan
It will be nice to have available a brief, easy readable introduction to V3, with a comparison between V2 and V3, so users can get an idea of what V3 will mean for them in practice and what they would need to do to prepare for it. Without having to do a deep dive and read all V3 tech specs first.
Does such a document currently exist?
https://thethingsstack.io/latest/getting-started/migrating-from-v2/major-changes/ would be a good place to start.
1 Like