Are you using the right IP address?
Hint: it’s not the one in the code
“IP” and “DNS name” no longer work ( “router.eu.thethings.network” / “52.169.76.203” )
- Single Channel R.Pi & Dragino shield (Europe)
- Arduino + RN2483
- include “thethingsuno.h”
All was working fine a month ago.
It seems that single channel gateway support is completely broken. I am in Canada and use the following router in my gateway:
“13.66.213.36” // The Things Network: router.us.thethings.network
I see all node messages on my gateway. I can forward them successfully to my own custom-built network server. But when I check TTN, it does not show anything.
What no longer works: Raspberry Pi based Single Channel Gateways based on this code: https://github.com/tftelkamp/single_chan_pkt_fwd
Messages received by these gateways and forwarded to TTN no longer appear on TTN and the gateways no longer appear on the TTN Map.
What does work: ESP8266 based Single Channel Gateways built on this code: https://github.com/things4u/ESP-1ch-Gateway-v4.0
These gateway are seen by TTN, appear on the TTN Map and the data forwarded by these gateways appear on TTN. I did have to trivially modify the v4.0 code to work in the US
I am using a SCG based on this:
And it also seems not to be working. I can see the uplink data forwarded to my own server through a http integration. And I can also see data coming in the TTN console interface. I can also see there that the network server sends an ack back to the node when the data is confirmed, although almost everytime my LMIC-Arduino node gets an invalid downlink (I am correcting for the clock accuracy error).
However the gateway shows as not connected with a NOC connection timed out.
I thought that a SCG based on this code supported downlink messages.
The issue here is that some single-channel forwarders (such as the tftelkamp version) do not support downlink messages. As we mostly focus our development on real gateways (multi channel with downlink support), single-channel-no-downlink gateways are easily forgotten.
We recently implemented an optimization in our backend that connects gateway streams when the gateway is active, and disconnect when the gateway becomes inactive. As some gateways don’t see much traffic, we can’t base this “state” on the uplink messages that are received from those gateways. However, all forwarders (except these single-channel-no-downlink ones) ping the server every 5 seconds, so we decided to use these pings to determine whether the gateway is active or not.
As a result of this choice, forwarders that don’t “ping” for downlink messages are assumed “offline”, and this results in the uplink traffic received from these gateways is not being handled correctly. I’m working on a solution for this.
The problem that @asier mentions is unrelated. For some reason the console does not correctly reconnect to the NOC when the connection breaks. This results in the “NOC connection timed out” message, message counters being 0 and traffic not showing in the “Traffic” view of the console. Messages should still be delivered to applications, because that does not need the NOC.
2 Likes
Thank you! It seems like the gateway is now connected. I guess it needed some time? Anyway, everything is working as before now.
Like @asier I’m also using https://github.com/JaapBraam/LoRaWanGateway. It was stable for some weeks but about 10 days ago began intermittently showing as “not seen for X hours”, and sometimes “Could not subscribe to gateway status NOC connection timeout” in an orange banner appeared in TTN Console.
I don’t believe the HW or SW changed, before the symptoms started appearing.
Yesterday the SCG had not been seen for some hours so I re-loaded all the LoRaWAN LUA scripts into the NodeMCU. After that it was briefly seen in TTN Console, was able to pass some traffic from a Node to TTN console. But now it is again not connected.
I’m posting in case others also see a similar pattern.
Hi: Im having the same problem with the 1ch GW starting 10 days ago too that is using the standard PKT Forwarder. The GW & associated motes worked fine but now can´t be connected. The router.us.thethings.network port 1700 address respond with PKT PUSH ACK so the TTN bridge seems to work but “could not Subscribe GW Status - NOC Connection timeout” message appear as soon the GW start sending.
Neither the GW configuration or firmware version has been changed.
Have you changed any address? Are you stil support this GW?
Do you know how can I solve the issue?
I solved this by replaing the Pi with a Wemos D1 mini and the software I mentioned earlier in this thread.
I have also solved using the same ESP Gateway SW 3.0 just changing on the configuration file (ESP-sc-gway.h) the interval used by the GW to pull data from TTN as stated by htdvisser.
#define _PULL_INTERVAL 5
Many thanks!
Seems it’s all a bit flakey. Sometimes they connect, sometimes not. RIght now a gateway that worked perfectly yesterday and at lunch is giving ‘could not subscribe to gateway status’ and ‘context deadline exceeded’.
Deleted, rebuilt, reflashed to esp8266, no fix.
Hey, TTN guys, any changes in the last few hours?
I’m experiencing the same issue as @asier. Just put together a single channel GW based on the same JaapBraam code. Worked great for a while, but then I started getting the NOC timeout errors. Although @htdvisser indicates that messages should still be delivered to applications, I’m finding it to be a hit or miss proposition. It worked, then stopped for a while, then started again. Seems like restarting my gateway sometimes makes a difference. But not always.
Same problem. What is the criteria for the gateway to be reflected on the TTN network?
I am using an RasPi 3 and Dragino LoRa shield. Messages are reflected on the terminal but the node status is inactive on the TTN network.
If you’re using the tftelkamp code for the R-Pi, read back through the thread and you’ll see that TTN has stopped supporting packet forwarders that don’t downlink messages. If you’ve found some other R-Pi code, I’d be curious to know what it is and how well it works.
2 Likes
We’re dealing with two completely unrelated problems here:
- Traffic from Single-Channel Gateways that don’t support downlink is not correctly handled by the backend
- The Console shows “not connected” for gateways, throws the “NOC Connection Timeout” error or keeps “fetching gateways”
We are working on resolving both issues
My LUA single channel gateway is running stable for months now. Every now and then the console shows ‘not connected’ or gives other error messages. At those times other users using other gateways also experience problems…
Without doing anything it shows ‘connected’ again after a while. So I’m quite sure most (all?) problems are caused by the TTN servers / console web application…
Usually messages sent by my test node (sends a message once every three minutes) keep being delivered as expected when the console shows error messages or ‘not connected’.
1 Like
Same symptoms today
Ic880a ras pi 3
No connection
Thanks for the clarification. I experienced issue #1 when using the tftelkamp code single channel packet forwarder for R-Pi, and then issue #2 when I switched to the JaapBraam LUA code with an ESP8266.
Do I understand correctly that TTN intends to continue support for single channel forwarders that don’t support downlink (once the backend issue is fixed)?