One of your troubles could be that were you got it from still have it configured on TTN as well.
WiFi at work being a common issue (see the forum posts on it!). Can you try linking to your phone.
Just before anyone asks, it being on v2 doesnât matter, as a v3 gateway gets priority.
Ah, you got that chestnut in before I could finish replying! It doesnât due to the excitement of the migration!
But surly if it is in another users name on v2, I canât register it in my account on v3?
Given that the database doesnât exist anymore, sure you can. And as they were separate databases, we could when we were moving from v2 to v3.
The Packet Forwarder is also totally separate from the various Network Servers, which is the thing we are querying.
You know when you pop the bonnet on a car and quickly close it because it just looks too much? Double that, and then again and then think TTI infrastructure - many database servers providing duplicates for resilience with cluster failover, multiple instances of a NS which I figure they have setup in a Kubernetes cluster so that the load balancer can then forward the messages to what ever is the least loaded. Probably multiple load balancers. Ditto for the Application Server. And then there is the Identity, Gateway, Gateway Configuration, Join, Device Claim and Network Operation Centre Servers instances.
And then somewhere with some more moving parts is the Packet Forwarder.
To totally mangle Nietzsche " âŚif you gaze for long into an abyss, the abyss gazes also into you" so I donât recommend getting in to the details unless you are some insane bearded SysOps person who drinks vegan beer from Jam Jars and does crosswords composed of AES cyphers.
At the end of the day then I can register all the V2 gateways in my name, they all will sizes to work.
Then you have 5000 users trying to prove who owns what.
I drink Black Label, if you can, you can down an can. 
Clearly you have time on your hands AND have not read https://www.thethingsnetwork.org/responsible-disclosure
I think to put any gateway on v2 in context, back in December TTI had the option of turning off the v2 gateway server, thereby removing a whole pile of abandoned gateways or running a cut down version that relays via Packet Forwarder.
However Iâm not so sure the ttnv2 tenant lists the not-transferred gateways - I think it lists the gateways that were on v2 that werenât deleted that have made it over to v3.
So descartes-m2m-tele-2 in front of me was on v2 and is now on v3 which you can see in the data. Whereas descartes-m2m-tele-1 is still on v2, is behind me (oh yes it is) and I can see uplinks from my new special friend, the most gorgeous PCB Iâve made yet, arrived via both gateways. But the v2 gateway data isnât in the PF API output âŚ
For anyone following any other topic, itâs on OTAA, itâs using LoRaMac-node and it hasnât been pestered with any downlinks.
As I suggested, if you want to stare in to the abyss, Iâll see your Black Label âwaterâ and letâs see how you can get on with something with some legs, like Carlsberg Special Brew.
Donât forget, itâs Turtles all the way down âŚ
NB: The moderators do not condone heavy drinking except in the evenings of the 22nd & 23rd September in Amsterdam - @johan will need the babyâs head wetting âŚ
PS, âbabyâs head wettingâ is British tradition where you drink to the babyâs health, we let the vicar try to drown the poor thing.
Gents,
Can we stay on topic and not confuse the forum users with esoteric subjects?
1 Like
Try using Custom LoraWAN server option instead of using TTN V3 with the same URL.
Also try adding 1450 at the end of your gateway EUI. Worked for me a few weeks ago.
thank you very much, this problem is solved. I have tried to do it from another hotspot and it worked!
But now I have another problem. My Temprature Sensor from Dragino does not connect to TTN server, although it is alrealdy connected to the Gateway, it can be seen in Log of my gateway. It is also shown in my TTN account (screenshot below). The data from my sensor was entered carefully several times. I did everything according to the instruction of the manufacturer.
Dev addr 01xxx means it is in the experimental range vs TTN allocated block, so assume you have this registered under ABP rather than OTAA? You need to double check device firmware and as registered under application/device console to ensure all keys and device details are a direct match with correct spec/phy option etcâŚ.are you seeing anything on the device console page at all? You might also try registering under OTAA (with correct f/w) to see if that works as much of the info is then automagically taken care off without room for wetware errorsâŚ.
Thank you for answering, Jeff! I am not so sure about it, what ist the difference and how do I know how I registered it? Below is my Sensor data i entered, and the data shown by the manufacturer. I am pretty sure I entered everything right
1 Like
Device (or node), a sensor is something that records data that is passed on via a device/node. They are settings. Data is what we receive. LoRaWAN is too complicated to debug without standard terms.
We canât see any settings from the manufacturer and it would help tremendously if you told us what the device actually is. Only the AppKey needs to be kept secret, Dev & App/Join EUIâs are heard in plain text on the air.
At the top of the page is a link to the Learn section which will tell you LoRaWAN 101 which you will need to survive - you must read this as the difference between OTAA & ABP is a fundamental. Dragino normally provide keys to setup for OTAA so the ABP entry in the gateway log seems a bit odd - which is where knowing what the device is so we can ensure which instructions youâve used.
dear descartes,
it is LSN50 v2-D20, outdoor temperature sensor from Dragino. The problem is solved. I just added the node one more time using Appskey and nwkskey. Now everything works properly, thanks for help
This topic was automatically closed 24 hours after the last reply. New replies are no longer allowed.