Not seen gateway status on ttn

hi
my gateway status has been vanished from ttn suddently, and i can not see traffic on my gateway
where would be the problem?gateway

1 Like

If you search the forum you’ll find that this is a known issue with v2, it won’t be fixed.

The acid test is, are uplinks appearing in the gateway console and are uplinks reaching your application?

in the application in data part I can see the data in uplink
but in gateway part there is no any traffic tap
I was working with my ttn about half an hour ago and everything was fine but now I can no see even my gateway is connected or no?
what should I do now?

yes I saw the issue regarding v2 but my problem is not just about downlink I can not even see my gateway status and there is no any traffic tab on gateway side to see uplink and downlink traffic

1 Like

Sounds more like they are trying to push us to V3.

2 Likes

That was what Nick was refering to wrt known V2 problem - it isnt ‘just’ a downlink issue - the Console appears to show GW not connected and you see no traffic at all in GW views - uplink, downlink, join req, ack etc.

Do you see node traffic appearing in you applications? If so GW is stll routing just fine and it is the known issue with info. BTW hiding GW EUI limits our ability to help - eg by checking status in the NOC. If your GW is publically declared then such details usually available in the clear and hiding therefore doesnt achieve much :wink:

This issue has been around for last couple of years and nothing to do with move to V3 through decision was taken to prioritise getting V3 up and running and ready for prime time vs spending resources fixing a platform was was due to retire once V3 out and stable…

Thank you for the reply
Yes I can see only uplink in application-data part
I have uploaded my gateway status which was working before which device Id is clear
image

this means that I have to go to v3?
this problem wont be solved?

This shows it was live just 15 seconds before your screen grab - typically they update every 30secs, some perhaps every minute (a TTIG may be longer) or when they receive a packet - so contrary to what you say it does not appear to have disappeared from TTN - can you clarify or explain what you mean on this. If you look at the traffic page from same view are you seeing any messages passing through? (Note this only captures LIVE traffic - historic data wont show and list will apear blank if you only open after a message has passed through…)

STATUS APPLICATION
as you can see i do not have any traffic tab to see data but i can see uplink data in application part.
these pictures have been taken 1 sec ago
application2

Ah see what you mean now - have just opened one of my console pages (actually checked 3 or 4) and see same problem… Looks like will have to flag something on slack OPS channel as not sure why the Traffic tab has suddenly disappeared : Paging Jac @kersing and Nick @descartes - are you guys seeing same problem - no Traffic tab in Console GW view?

1 Like

I have the traffic tab but for the first time ever I’ve just seen the Not connected issue for my “forever on” gateway in the office.

EDIT: It’s a web app (yeah, it’s an app), so one refresh later and the traffic tab disappears!

EXTRA: It’s not in the HTML either!

@Jeff-UK Yep, confirmed. Missing in action… Along with last seen and message counters on the information page.

@descartes Yep tried a few more and refresh - BANG!
image

Just logging into Slack OPS and havent seen anyone flagging so a recent problem?

Update: just seen Nick post to OPS - types faster than me :slight_smile:

Many apologies for not spotting this: tap = tab - I hate autocorrect!

Although the first screen shot didn’t show this section of the web page so I didn’t figure it out.

In the meanwhile you can see your data at the application or device level.

thank you
you mean the gateway part wont be fix anymore? and i have to just see data in application part?

No, this is an issue that we would expect to have fixed - it has been reported.

If you search the forum you will find that there is an issue with the part of the console that you took a screenshot of that doesn’t update the last connected or the status.

Which is why I thought it was that you were referring to.

thank you so much for any efforts
i look foreward to seeing this isuue would be fixed soon.

Other comments in this topic already give a pretty good explanation of the situation, but I can also add some more details.

We recently updated the v2 Console to make it less confusing. Instead of showing incorrect information or empty pages, the Console now tries to hide parts of the user interface that rely on the “NOC” component when this “NOC” component isn’t available. Gateway status and live gateway traffic are the main features for which data is provided by the “NOC” component.

The problem here is that the “NOC” component is having issues. This is unfortunately something that happens more often. We made a lot of crucial mistakes when we initially designed the architecture of the NOC. As a result of these wrong architecture decisions, we’ve had a lot of difficulty scaling the NOC as The Things Network grew. We’ve had to disable some functionality (such as event history, searching for events, events from applications and end devices) to prevent it from crashing completely. Suffice to say, the NOC is always having a hard time, and it’s barely working most of the time.

In the meantime, the core team is now spending all its time on The Things Stack (v3), we’re not going to fix v2 issues anymore. The core team still does its best to resolve downtime of critical components in v2 deployments. Critical components are the components that are required for routing LoRaWAN traffic between Gateways and Applications. The “NOC” component is not considered critical, so we’re not going to spend a lot of time figuring out what’s wrong. Sometimes switching some things off and on again helps, but that’s all we’re going to do.

I would indeed like to take this opportunity to push you guys to The Things Stack (v3). Anyone who’s just getting started and doesn’t have working applications or end devices, and still relies on live gateway traffic, should really be using The Things Stack (v3). Anyone with working applications and end devices can use the data view of their application or end devices. But you should still migrate those to The Things Stack (v3) as soon as you can.

1 Like

Ok, appreciate the explaination BUT this causes HUGE problems for many.

Whilst appreciating changes due to NOC issues what you have just done is rendered much of V2 unusable…and with little forwarning or discussion of effect or mitigation .

E.g. besides the change to individual GW status and traffic (and the value that has for helping debug device issues or gw problems it seems this has also impacted the GW overview page :frowning: Listing all GW’s is closest thing to a simple individual/user/group NOC and as you can see connected/notconnected status no longer listed.:

With, in my personal vs community or clients case, several dozen GW’s to monitor and manage a quick scroll up or down would tell me if any had gone offline or not - if lots suddenly offline then I could guess it was the NOC problem and then if concerned dive in to indivdual devices/applications to see if traffic still coming through and all ok with routing or if indeed the GW was down and needing attention. It is not practical/too time consuming to step through ALL of them in the abscence of an overview.

Yes, we know we get the message… BUT v3 seems, looking at the posts we see on the forum and from our own testing and experiments/experiences, still not ready for prime time for many, there are still missing integrations, documentation needs and there is a steeper learning curve cw V2 usage. TTN Mapper integration has only recently become available and there is still no sign of My Devices/Cayenne coming on board requiring major discussion and evaluation of potential alternatives/replacements (and likely significant costs - both monitary and opportunity/manpower - in considering, evaluating, learning and the implementing alternates).

In many cases migration requires visits to site to recover/reprogramme devices and or GW’s…

In case you missed it we are in the middle of a global pandemic and travel (domestic or international), in country movement and visiting sites - be they commercial, governmental or private locations is often not possible and in many cases not desireable… forcing the issue doesnt provide a solution. We are ‘in limp along mode’ for the comming months and TTN/TTI needs to respect and allow for that… please!

Having V2 data forwarded to V3 helps but we still have 2 issues to resolve - physically migrating the end devices and applications from V2 to V3 and, where applicable, its not possible to look at received metadata to verify which (V2) GW’s are handling the traffic to help debug system issues or indeed to see which GW’s are most effectively carrying the traffic in order to prioritise the gw migration task in a given area - as PacketBroker annonymises the GW id when passing the traffic, and as per other posts to the forum, GW owners have a responsibility to not just migrate their GW’s from V2 to V3 for selfish reasons but rather need to consider possible local users who may still be using for V2 devices and V2 apps (that they may not be able to deal with in current situation, even if motivated to migrate) - we do not want to cut these guys and gals off at the knees…

It is well documented that the NOC/V2 console is causing problems and oft posted to the forum, with users regularly calling out for help (and sadly not using search to get understanding 1st!)… but it is far better to leave it running showing some data than cripple it even further…even if as Mods, and other active users, we then have to step in and answer user questions and point them to prior reponses where V2 causes problems.

@wienkegiezeman @laurens @johan please ensure V2 can limp on for a time, and in a usable fashion, for as long as practical and consult with your community users before taking such impactful decisions and implementing without a heads up…

5 Likes