I know there are other posts on this or similar topics and I have been trawling through them. Many are years old and didn’t help.
It’s been a very long time since I looked at my gateway console so I don’t know when the status changed to disconnected.
My kickstarter gateway IS sending status packets. The diagnostic serial port shows messages like this every 20 seconds or so:-
MQTT: Sending status packet
MQTT: Sending status succeeded: 467
Packets do reach my test application and the verbose log shows the message was forwarded by my gateway. The gateway info page shows the Packets up count which increases when I fire up my test device.
It would be rather nice to have my gateway log back but how? I have powered down the gateway for 5 minutes and powered it back up but no change.
My gateway (bnn-ttn-1) is a KickStarter running FW v1.0.9-eb004399 (2022-10-28T13:45:31Z). It was converted from TTN V2 to V3 a few months after V3 came out (must be well over a year ago) and was running just fine.
Any help would be gratefully received. Thanks
Brian
It’s not clear if you mean just the status or an actual log in the gateway console. Going for the most commonly asked question on the forum …
And none of them mentioned that the status is updated sporadically and that is not be used for anything other than generating forum posts?? If there is gateway console traffic and it’s arriving at your app, the status is a red-herring bonus of worry.
There are also posts about checking the gateway status using the packet broker API but that’s a bit overkill but may set your mind at rest. I personally don’t use it as if my Canary (permanent test device) is getting packets to TweetyPie, it’s all working.
Status and Log - status is disconnected log has nothing in it. When I fire up my end device device the application log shows the transmissions are received but there’s nothing in the gateway log yet the verbose log entries show the signals were forwarded from my gateway and no other.
Yes the trawling did throw up that a regular status message should be sent to keep the status as connected. That’s why I said the log shows the status is sent every 20 seconds or so.
I agree I could, in this case ignore it but I’m trying to debug a new device which is not playing ball.
Fine, but the twice weekly on average “Gateway shows disconnected” posts are about the status message on the console and have no bearing on what the gateway sends.
As the prior paragraph referenced the status your clarity is still not clear - I think this means you are wanting to see the gateway console log which is something that general works.
There is nothing we can do about the gateway status.
Assuming you mean the former, then, using the old worn “is it plugged in” avenue of the irritatingly obvious but easy to overlook, have you tried a different browser / computer? Do you have any other gateways, even unplugged ones? If so, when they are plugged in, are they showing normal log activity?
My gateway console log is not showing any messages at all.
I have tried Edge and Firefox. They are both devoid of any console log messages.
No I don’t have any other gateways so I can’t compare.
Yes my gateway is ‘plugged in’ it has the 4 leds lit and is rock solid.
If there’s nothing that can be done about this then I’ll thank you for taking the time to help. I’ll live with it and close this topic and find another way to debug my new device (conversion of RasPi Dragino Lora Hat/GPS python code to CircuitPython).
As in ANO Police Procedural, “this clue is the only lead we have to go on”?
Yeah, got that, it’s forwarding uplinks, the “is it plugged in” is a generic reference to asking basic questions just to do a sanity check. Back in the late-80’s, “is it plugged in” was a genuine question, followed by “is it switched on”.
This just may be an Aspbergers special day (for me).
I’ve made you a collaborator for one of my gateways, if you click on the big Gateway icon or on the Gateway option at the top of the page you can select it - can you see if that console is showing traffic?
Your gateway should show console traffic, it may be you are spearheading a new issue and no-one else has noticed yet - so if no one else spots this & reports it, then it will be unique to you.
??? it provides information ???
Really? True when the console log is working. I’ve added you as a collaborator on bnn-ttn-1.
Thanks for adding me to your gateway but I fail to see the point?
Back in the eighties
Is where I cut my teeth as a computer service engineer for 25 years. This TTN stuff is a retirement hobby.
Your gateway should show console traffic,
It doesn’t, check it out yourself. There is someone in the locale sending periodic messages maybe one every 10 minutes but they only show in the gateway debug output not the TTN console.
I have just fired up my working RPi Dragino Lora/GPS hat - it’ll run till it reaches the 30s tx time limit and it’ll send every 20s to adhere to 1% duty. They appear to uplinked via my gateway.
Were you able to try a different computer?
Tried my Linux Mint laptop - still no log messages. It’s using Firefox as well.
From my application log the uplink messages include this
Forwarder GW is bnn-ttn-1 but no traffic shown the RSSI is -53, it being in the next room. My transmissions are also seen by another gateway hcc-lora-004 which belongs to Hull City Council but I have no rights to look at their log.
If it’s just me then that’s my bad luck and explains why I can’t win the lottery.
Please try powering down for a longer time. It sounds like a load balancer is forwarding your session to an gateway-connector instance that does not forward information to the console. From what I understood some time ago this can happen after a software update, which happened yesterday. @KrishnaIyerEaswaran2 did I understand that correctly?
My Kickstarter gateway does forward status updates and shows information so not every gateway has issues.
Seen it, no traffic showing so it’s not your computer or ISP etc, it’s something about the gateway or the connector …
Because it is showing traffic on my web console so the acid test is if it shows on your web browser.
This is a hugely important test. Please can you look asap.
This got lost in translation - you were prepared to give up, I was saying that your gateway should show console traffic so you shouldn’t give up. I didn’t say “I don’t believe you”.
As I’m won’t to say else where, please don’t run something that will breach FUP if accidentally left running - it doesn’t make something start working by banging on the door constantly.
OK, thank you for checking.
This, like the give up above, isn’t moving things forward. Please look for the questions & suggestions and action them as appropriate, hopefully we can get this fixed for you so you can carry on with the project.
Yes I saw traffic in your gateway log. I didnt understand you were trying to eliminate the browser. I never had problems viewing the my gw console log in the past. It was good to see others were using the gw.
After you said that the gw console disconnected status was outside your control I took that to mean no more could be done. Hence the flippant lottery comment.
My code won’t breach FUP nor the 1% duty cycle I’m very mindful of that.
Probably won’t hurt, but I don’t expect it to make a difference.
You are sure your gateway is handling traffic? Your test devices packages are not picked up by another gateway nearby?
My suspicion is still a sticky load balancer session. However 45 minutes should have taken care of that. You cloud try powering it down for over an hour but I don’t expect miracles.
The app traffic showed the packets were picked up by two gateways. Mine and one owned by the council. The rssi for mine was -58, the council gateway was -110. So i think mine would be selected. I don’t have access to the council gateway but even so my gw console is not showing status messages which the gw debug output indicated were sent & recvd ok.
I have to go out so Ill turn the gateway off again. Itll be a couple of hours before I return.
LoRaWAN is not WiFi. End devices do not connect to gateways, end devices transmit and hopefully one or more gateways receive that transmission without CRC errors and forward it to the backend.
All received packets within a certain timeframe are combined (especially the meta data) and the result is forwarded to the application the device belongs to.
For downlinks the LoRaWAN network stack selects the most appropriate gateway to transmit based on several criteria, signal strength and available airtime (gateways must adhere to the same legal limits as all devices) among those criteria. (For those interested in all of them and the weight, check the source of the things stack.)
I know it’s not WiFi. My apologies if that’s the impression I conveyed.
My gateway was off for 2 hours today. It has been on for another two. There are still no gateway status messages or anything else in the log other than this:-
Selected for what? If both gateways hear an uplink, they forward it to the LNS, as long as they both arrive in time at the LNS then they get duplicated so the Applications Server only gets one. But both gateway consoles should/would show the uplink.
The only time there is a choice made about gateways is for downlinks.
The next acid test would be to try running the gateway via a mobile phone or someone else’s network to check there hasn’t been a change with your router or ISP that is affecting anything.
I don’t know if there is mileage in refreshing the firmware.
The acid test after that is to beg/steal/borrow a gateway of a different type to try at home. If it comes to that, I can post you a TTIG to try.
Selected for what?
Yeah it was a dumb comment on my part, on reflection.
I have considered an alternative - delete the gateway and re-add it with another name.
Thanks for the offer of a loan TTIG, I’ll bear it in mind. But I’ll contact the Hull City Council IT guy I was working with - I think they may have some spare Kickstarters - they bought a job lot just before the change to V3, to distribute to people like me.
