So when the engine warning light in my car is on, but the car still is running properly, it’s “operating as expected”? The issue seems to be that way for more than 4 days and the only reaction is “but it’s working, isn’t it?”. The connected/not connected indicator is especially important for people with multiple gateways in remote locations. Being able to monitor them without sending test data is essential.
4 Likes
-
Have you checked if ttnctl provides the same status? I’ve been using it for years to monitor my 15+ gateways and it rarely is wrong about gateway status. Last weekend it showed all gateways using a certain connection off-line and ‘surprise’ there was an issue and it was resolved asap by TTN
-
You sound like you feel you are entitled to something. If you feel that way, move to TTI, the network with SLAs. The community network is run on best effort base and costs TTN money to keep up and running while not generating any income. They decided not to invest time to resolve this particular issue and focus on getting the next generation software up to the point where we can all benefit from it. That version was designed with the experience of what does not work in the current generation in mind and should not suffer from these failures. (There will of course be other issues as no software is ever perfect)
3 Likes
I reported the console showing “offline” when gateways are in fact online. It doesn’t matter what other services show different results. That single component does not work. In fact, it would be far worse if other components were also failing and showing bad results. What kind of argument is that?
No, I reported an issue with the free service you are providing, to which arjanvanb was quoting that it’s working “as expected”, to which I disagreed.
Please keep your combative attitude to yourself. It’s not constructive. There’s an issue with the console not showing correct information, and the time spent on arguing about it is completely wasted. It’s currently broken and not working “as expected”.
Welp, I spent a bunch of money on a gateway by the same company, for a product that was defective right out of the box, but you don’t see me complaining about having to fix it myself, do you?
Overall, do you have a problem with your users reporting issues with your service? I reported an issue, and all I get is backtalk. A simple, “we are working on the issue, but it’s not our first priority” is all it would have needed.
2 Likes
The only service I provide to you is moderating this forum. I am not employed by TTN, don’t get any money for the many hours I spend trying to support forum users, just a lot of attitude by people that find they are entitled to things.
TTN is aware of the issue. As I explained they decided to spend their time on other things and not to work on resolving this known issue. I understand you don’t agree.
2 Likes
Have you checked if ttnctl provides the same status?
Okay, let’s try it:
$ ttnctl gateways info 19711137
INFO Found gateway
Gateway ID: 19711137
Frequency Plan: EU_863_870
Router: ttn-router-eu
Auto Update: on
Owner: markruys
Owner Public: yes
Location Public: yes
Status Public: yes
Brand: MultiTech
Model: Conduit mLinux
Description: xxxx EU868
Access Key: xxxx
Collaborators:
- Username: markruys
Rights: gateway:settings, gateway:collaborators, gateway:status, gateway:delete, gateway:location, gateway:owner, gateway:messages
So this doesn’t show me whether the gateway is online. Or do you use another ttnctl command?
Although I don’t sympathize on how @milanoengineering makes his point, I do find it annoying that suddenly for some of our gateways the status is not updated anymore at the TTN console.
Off topic, a few days ago we also saw that US915 configured gateways with a EU router suddenly started to receive downlinks on EU868 channels from the NS. These gateways refused to process the downlink so now no join requests get an ack anymore.
You’ll need ttnctl gateways status.
ttnctl gateways status 19711137
INFO Discovering Router...
INFO Connecting with Router...
INFO Connected to Router
INFO Received status GatewayID=19711137
Last seen: 2020-05-15 17:17:50.685704614 +0200 CEST
Timestamp: 0
Reported time: 2020-05-15 17:17:50 +0200 CEST
Frequency Plan: EU_863_870
Bridge: gs.v3.
Location: not available
Rtt: 46ns
Rx: (in: 29; ok: 6)
Tx: (in: 1; ok: 1)
2 Likes
Yes, perfect, this shows my gateways to be connected indeed. Thanks, Mark
What an interesting spin to give users who report issues, issues where they don’t even know if they’re at fault, or if the network is faulty. No one feels entitled by reporting an issue with a service. I understand you being frustrated when people complain about stuff you have no control over, but the users don’t have control over it either.
Please look at my first post. I asked what the problem is, and what comes back is “operating as expected”. If anything, that’s seems to be an entitlement to be a smartass to users. “Buy an SLA if you want proper service, you freeloader”. What an attitude to have.
What I saw in the first 3 posts was 3 users who didn’t even seem to bother to search for existing reports about this, nor provide much detailed information.
1 Like
After you reported a known issue that has gotten coverage a couple of times already on the forum and get quoted the official TTN statement regarding this (please visit the official status site to check for it yourself) you respond with a story regarding engine lights. Have you reread your own response and judged it not sounding like you feel entitled?
May-be we should conclude things are as they are. Neither the users nor the moderators can change the decisions made. If you don’t agree, this forum is not the place where you can challenge TTN on their decisions. Don’t ask me what the right place is, I haven’t found it yet…
1 Like
I was perplexed by something being broken, yet “working as expected”.
I checked the official status page, there was an entry from “Jan 27” (no year, on none of the entries). Not sure how relevant that is or can be.
Anyway, you explained the issue, basically the TTN people will work on it whenever they feel like it, as the issue seems to persist for months now, and besides the status and traffic console everything is working fine. Users (like me) just have to deal with it.
TTN is a free to use service, so solving issues like this is probably not a priority.
2 posts were merged into an existing topic: Can’t access TTN Console, ttnctl fails, TTN Node-RED library fails, and Kickstarter gateways get stuck after daily reboot
Thanks, this showed my gateways are connected. Never knew ttnctl existed…
Same issue here. Gateway is not registered in TTN console. I cannot run ttnctl because I make a balena.io/resin.io install and this command not work from balena.io terminal.
Also in TTN traffic didn’t see anything as last week.
Thanks
You can install and run ttnctl anywhere:
ttnctl gateways status pruebas_leon
INFO Discovering Router...
INFO Connecting with Router...
INFO Connected to Router
INFO Received status GatewayID=pruebas_leon
Last seen: 2020-05-18 11:53:59.389490752 +0200 CEST
Timestamp: 0
Reported time: 2020-05-18 11:53:59 +0200 CEST
Frequency Plan: EU_863_870
Bridge: gs.v3.
Location: (42.581059, -5.534930; source unknown)
Rtt: 62ns
Rx: (in: 24; ok: 0)
Tx: (in: 0; ok: 0)
Ahh, ok thanks a lot. So, it’s working ok then?
I cannot see any traffic. unfortunately I haven’t any device at hand to test it. Hope can test it in few days.
Thanks a lot!
Yes.
Yeah, not seeing traffic in TTN Console is quite annoying and I don’t know of any other way to see gateway Traffic without depending on that NOC component. Also, I don’t know how the Rx and Tx metrics in the output above are calculated. (The source code might reveal that.)
Of course, without TTN, one might still be able to peek into the raw gateway logs; isn’t that something that Balena offers? When you’ve got devices you’ll surely see their traffic just fine though.
I can only see main log but no realtime traffic…
like this:
18.05.20 12:22:33 (+0200) main ##### 2020-05-18 10:22:33 GMT #####
18.05.20 12:22:33 (+0200) main ### [UPSTREAM] ###
18.05.20 12:22:33 (+0200) main # RF packets received by concentrator: 0
18.05.20 12:22:33 (+0200) main # CRC_OK: 0.00%, CRC_FAIL: 0.00%, NO_CRC: 0.00%
18.05.20 12:22:33 (+0200) main # RF packets forwarded: 0 (0 bytes)
18.05.20 12:22:33 (+0200) main # PUSH_DATA datagrams sent: 0 (0 bytes)
18.05.20 12:22:33 (+0200) main # PUSH_DATA acknowledged: 0.00%
18.05.20 12:22:33 (+0200) main ### [DOWNSTREAM] ###
18.05.20 12:22:33 (+0200) main # PULL_DATA sent: 0 (0.00% acknowledged)
18.05.20 12:22:33 (+0200) main # PULL_RESP(onse) datagrams received: 0 (0 bytes)
18.05.20 12:22:33 (+0200) main # RF packets sent to concentrator: 0 (0 bytes)
18.05.20 12:22:33 (+0200) main # TX errors: 0
18.05.20 12:22:33 (+0200) main ### BEACON IS DISABLED!
18.05.20 12:22:33 (+0200) main ### [JIT] ###
18.05.20 12:22:33 (+0200) main # INFO: JIT queue contains 0 packets.
18.05.20 12:22:33 (+0200) main # INFO: JIT queue contains 0 beacons.
18.05.20 12:22:33 (+0200) main ### [GPS] ###
18.05.20 12:22:33 (+0200) main # No time keeping possible due to fake gps.
18.05.20 12:22:33 (+0200) main # Manual GPS coordinates: latitude 42.58106, longitude -5.53493, altitude 868 m
18.05.20 12:22:33 (+0200) main ### [PERFORMANCE] ###
18.05.20 12:22:33 (+0200) main # Upstream radio packet quality: 0.00%.
18.05.20 12:22:33 (+0200) main ### [ CONNECTIONS ] ###
18.05.20 12:22:33 (+0200) main # bridge.eu.thethings.network: Connected
18.05.20 12:22:33 (+0200) main # Semtech status report send.
18.05.20 12:22:33 (+0200) main ##### END #####
18.05.20 12:22:33 (+0200) main 10:22:33 INFO: [TTN] bridge.eu.thethings.network RTT 67
18.05.20 12:22:33 (+0200) main 10:22:33 INFO: [TTN] send status success for bridge.eu.thethings.network