Hi andromeda,
since the September of this year I have the same problem. The gateway has been showing disconnected on the dashboard, but the LED status is solid green and can be seen as “connected” within my router.
Have you found a solution to the problem in the meantime or has a good spirit sent you one?
I’ve been looking for a solution for almost a month now, including on the site you mentioned, but nothing helps.
Best regards, Bert.
Greetings jahnbes,
Good to hear this is not an isolated case. Maybe there is a common fix in that case we’d have to uncover.
Since my post, I unfortunately have not found any leads - I did try both resetting, power cycling, and leaving the gateway plugged in for a couple hours to see if it may eventually connect.
It sounds like we both are experiencing the same issue - and I believe the first time I started experimenting with the gateway again was in early September as well. I had last used it in May 2024 and it was successfully running.
Are you also using The Things Indoor Gateway (TTIG) or similar?
Best,
andromeda.
Exactly, I use the same gateway.
And strangely enough, at the same time (it was midnight) my weather station’s connection to the router via WLAN died. And it really has nothing to do with LoRaWAN and TTN.
So far I have tried various restarts and also left the gateway unplugged (without power) for an hour, nothing has helped.
In the meantime, it is always connected to the network and power supply for many days. The led is then also permanently green, only in the console the gateway is marked with “disconnect”. And it does not work, i.e. it does not forward data as it should and has done for two years (until this September).
I’ll investigate further, greetings, Bert.
Hi andromeda,
I have written another post on the topic under the title
“How can I reconnect a TTN indoor gateway?”
Maybe a new post will get things moving!
Have a nice Sunday, Bert.
Actually no…double posting just splits attention and efforts and fragments any responses making it harder for peope to find solutions to similar issues in the future! And indeed your other post ommits potentially key additional information such as
Perhaps you can expand on this and what you have done to investigate the seeming outage/lack of backhaul for your router/selected devices?.. are all ports clear/open? did the router go through an update? was there are close proximity lightning strike? Any other ‘connected’ devices in the premises playing up? Did it happen on a wednesday after a major houseparty? etc. 
Meanwhile I will close your other post…
P.s. wrt
…“did the router go through an update?”…
my son just completed a 3+year stint in DE with DSL solution from local provider that insisted on rolling out updates typically aro 12 midnight to 2am every few-6 months - that basically bricked the router forcing him to roll back next day so he could get back online again - so not unknown!
First step, read all the posts on what the disconnect tells you on the console and how & when it is updated. Disconnect is a side issue. reality is uplinks.
Like @Jeff-UK says, soooooo much detail missing - like do you actually have a device, is it working (how do you know), how often is it uplinking etc. And what is your other one, a different brand?
The other reality is that such debugging is done with a second gateway - again a different brand - seems like an imposition but if it turns out there is something wrong with your backhaul, we’d expect both devices to show disconnected, if they are both using the same sort of gateway firmware - which yes, means you need a BasicStation based gateway. And if you have a Packet Forwarder based gateway, you need two.
If this was WiFi that wasn’t allowing all your devices to connect to the internet then you’d have to get a second router or access point, so this is not a LW thing, it’s an RF thing.
Hello andromeda,
Following the information that has accumulated here, the following picture now emerges for me:
-
the status is unchanged.
-
the gateway is obviously OK and not the source of the error.
-
all (!) three, completely independent LoRaWAN devices, which I have been operating continuously for 3 years without any problems, went down at the same time on 26.9.24 approx. 00:01.
-
a troubleshooting revealed that the devices start the join to TTN, but obviously receive no response from there.
-
this means that no connection has been established since 26.9.24 and the gateway reports ‘disconnect’ at some point.
-
one of the devices is mobile. I moved it close to a very good gateway (TH Wildau), but no join was possible there either. The gateway works according to TTN-Mapper.
-
all three of my devices are based on Heltec MCs, two CubeCell HTCC-AB01s and a HELTEC WiFi LoRa 32(V2).
The crucial error is that a join is no longer possible. I will investigate the reason for this further and report it here. Maybe the libraries from back then are no longer correct, we’ll see.
I think the first thing I will do is delete a device in TTN and try to place it there again.
Do you have any other ideas?
Best regards, Bert.
The gateway is obviously not OK - three devices tend not to drop off the network by themselves - and it could be as simple as a change in the settings of your ISP that now blocks certain packets or the gateway could have suffered some trauma that renders the antenna or input stages damaged in some way.
TTN rarely picks out one users set of devices to exhibit some odd behaviour, so it’s unlikely to be the three devices excepting if you are using the original Heltec code base that runs v1.0.2 then there may be something odd occurring but then we’d see a flood of messages on the Heltec forum.
“troubleshooting revealed that the devices start the join to TTN” - what does this mean - what did you do, what did you see?
“I moved it very close to a very good gateway” is very subjective - how close is close? It may appear on TTN Mapper but that’s no guarantee it was on at the time.
Hello descartes,
You are right. After many tests on my devices, I drove around again today with three devices and found a gateway in the wider area that worked and received the data from my devices and transmitted it to TTN.
A further test at home has now clearly shown that my TTN gateway (TTN Indoor Gateway) is faulty. What was a bit irritating for me was the fact that, according to the manual, the LED that lights up green continuously after booting indicates that this gateway is in correct contact with TTN. But obviously it is no longer in contact with its devices.
The new gateway (LPS8N Indoor LoRaWAN Gateway) has been ordered, I will report back.
Thank you and best regards, Bert.
2 Likes
Hello Jahnbes,
One other thing I was planning to try was to take a look at my router and check the status of the ports the gateway normally uses for the uplinks. It could be possible that there is currently traffic on those ports, or traffic on that port is blocked by a firewall.
It appears by default both uplink and downlink communication between the gateway and the network server happens on port 1700 (UDP). Could be something to look into as well. I’ll try this and report back.
That would be the case for gateways running the semtech UDP packet forwarder. However TTiGs run Basics Station which is websocket based and uses different ports.
The new gateway has arrived and, after a few teething problems, has been put into operation.
However, this was very bumpy. There is no longer a stable connection, but I am not yet sure why this is the case.
I simply plugged in my old gateway (TTN indoor gateway), did the few necessary steps and then it worked for 3 years.
Unfortunately, this is not the case with the new gateway (LPS8N Indoor LoRaWAN Gateway). The many uncommented and unexplained setting options are somewhat confusing for a gateway layman. For example, it is not clear to me whether I should use ‘Basic Station’ or the variant with ‘semtech UDP packet forwarder’. The difference between the two is already unclear to me. What was actually the case with the ‘TTN indoor gateway’, ‘Basic Station’ or ‘semtech UDP packet forwarder’? I would like to continue using that.
Can you help me, kersing?
Translated with DeepL Translate: The world's most accurate translator (free version)
Do you use the instructions on Dragino LPS8N | The Things Stack for LoRaWAN?
Easiest to setup is UDP Packet forwarder. TTIG used Basics Station software, however that is harder to setup.
Yes, I have used this website. I’m also not sure what the problem is. It may also be due to my devices.
Obviously their software libraries (Arduinoe IDE) have changed a lot and I am currently unable to recompile the three year old codes. I’ll keep researching and get back to you.
Thanks for the categorisation of BUDP Packet forwarder and TTIG used Basics Station!
Unlikely - the standard is a standard which means that older versions remain.
I’ve LMIC based ATmega328+RFM95 devices happily working even with the all new TTIG Pro as well as ancient PF OrangePi based gateways.
Always best to do one thing at a time - a gateway would be pretty useless if adversely impacted by bad RF.
The problem is solved. The (old) TTN indoor gateway had broken, obviously in the part of the hardware that receives the signals from the devices.
Unfortunately, the LPS8N ordered as a replacement was also defective.
Only a new TTN indoor gateway brought success, everything works again. I didn’t need to change anything on my devices, although I suspected faults there too and checked them.
The troubleshooting was made more difficult by the fact that a WLAN device that really has nothing to do with LoRaWAN went faulty almost simultaneously (+/- 10 minutes). This resulted in many wrong turns that had to be taken when troubleshooting.
Hi jahnbes,
Happy to hear a new TTN gateway fixed your issue. How did you ascertain whether a new TTN gateway was needed? I would presume the hardware shouldn’t unexpectedly break like that considering these aren’t cheap.
Best,
andromeda
Actually in relative terms they are quite cheap (or should that be low cost?!) And are more like a consumer router than a Telco grade missin critical system Given old - per poster comment - then mortality not unexpected especially given
which brings me full circle to my question fro just over 3 weeks ago:
not least as that would account for
1 Like
Hello andromeda,
yes, the gateways are not cheap.
In short and apart from all the wrong turns, I have come to the conclusion that my gateway is defective for the following reasons:
- two sensors operated with LoRa failed at exactly the same time.
- a third test sensor could no longer join either.
- near a third-party TTN gateway in my city, all three sensors joined immediately and without any problems and reliably sent their data to the TTN over a longer period of time.
- all further tests with the sensors showed that they were OK.
The following points caused difficulties and errors during troubleshooting:
- a weather sensor that had nothing to do with LoRa failed almost simultaneously (+/- 10 minutes). It sends its data via the WLAN. Its fault has now been found and rectified. However, the simultaneity was confusing.
- the first replacement gateway I bought (LPS8N) is obviously also defective, a join with it was only possible very sporadically, data was only sent very irregularly, sometimes only every two days (!). Many data records were missing.
- only the next gateway I bought (TTN Indoor Gateway) worked straight away without any problems. All my sensors were able to join and send data immediately.
I wish you every success too, hopefully at a much lower price!
Best regards, Bert.
Hello Jeff-UK,
thanks for your comments. No, there really wasn’t a thunderstorm during those hours when the LoRa connection failed.
The following points contradict the assumption that a lightning strike or a spike on the power line could have been the cause of the failure:
- all LoRa devices were located inside a building (house or garage), https://www.arduinoforum.de/arduino-Thread-Garagenüberwachung-mit-LoRaWAN-und-TTN)
- all LoRa sensors are battery-powered and are not connected to the power grid.
- the LoRa gateway is connected to the power supply, but it was the only device that was connected to the power grid and failed at that time. All other devices (router, server, etc.) did not show any errors.
- only the weather station mentioned (https://www.arduinoforum.de/arduino-Thread-Wetterstation-mit-DFRobot-FireBeetle-ESP8266) is located outdoors, but the fault has since been found and rectified. It was the JST plug/socket connections that had been damaged after three years of outdoor use without being directly exposed to the weather.
Best regards, Bert.