Thanks BoRRoZ. I didn’t know that t was this hard to get a Node register. I always thought that it didn’t matter what type of the board was as long it has the LoraWan chip onboard, it would communicate.
I Still think that this is the case, because i still see the data coming in at the gateway console.
and i also see what the payload is on the Gateway Console side, but not on the application side.
So the question still remains, what am i doing wrong?
Please help. Any lead is welcome.
You are seeing join requests at the gateway, as the application does not show any activity one of the EUIs or the key on the device probably does not match the values you entered in the console.
could be the keys , in your screenshot they look similair
I have doubled checked all the keys on TTN, and they all match.
But how do i check the Keys on the Node?
Differently put, How can i see what they keys are on the Node?
The node has no physical way to connect to (serial or usb).
Hey BoRRoZ,
The keys are an exact match on the TTN, but the only verification i need to do if the keys also matching with the keys on the Node itself.
Challenge
How to check the keys on the Node itself?
Is there anybody who can guide/help me with this?
find out first (ask your friend) what the manufacturer and type is
its seems a commercial product.
The node has no physical way to connect
there must be documentation… how do you set/read keys
Thanks. I will try to find out what the keys are on the Node.
You must find out how to enter the keys that you get from TTN… you can’t use a preprogrammed node from another network.
Thanks BoRRoZ.
I always thought that it wouldn’t matter was registered on another network. It would always be possible to register the node on any other network. The strength of the openess
If it was previously registered on another network, then TTN should accept it. One cannot register an ABP device with hardcoded keys from another network (DevAddr, AppSKey and NwkSKey). But your device is using OTAA (DevEUI, AppEUI and AppKey), and that should be fine. All is not lost yet.
So: where did your friend use it earlier?
If your friend used it on TTN then be careful: deleting an application on TTN might orphan its devices, and then one might not be able to register such device with the same DevEUI, AppEUI and AppKey again. See How can I reuse hardcoded AppEUI and AppKey after I deleted an application?
Do NOT ask your friend to delete anything at this point.
However, in that case, I’d assume you would see errors when trying to register the device with the same DevEUI, AppEUI and AppKey, which you did not mention, so that’s probably not the case.
If your friend used it on another network then TTN should (also) accept it. If your friend did not delete it from the other network yet, then if both networks receive the OTAA Join Request (orange icon in TTN Console), then both could transmit an OTAA Join Accept (green icon). Next, the node would receive the strongest signal (possibly the wrong network; the node would stop joining), or none at all (collisions, after which the node would try again). However, you don’t see that Join Accept in the gateway’s Traffic page at all.
As for not seeing the Join Accept:
The OTAA Join Request is not encrypted (the AppEUI and DevEUI are not a secret). So, in the gateway’s Trafic page you can see the AppEUI and DevEUI that the device sends. (The values you see in that Traffic page are not the ones you registered in TTN Console, but the ones sent by the device. Of course, these should match.) Check and double-check those values, again. And, again!
Clicking an item in TTN Console’s gateway Traffic page reveals more information, which may include some hints. What do you see there?
Any chance the Join Request is received by multiple TTN gateways, and another TTN gateway has a better reception, hence is selected by TTN to transmit the Join Accept? In that case, you should still see the Join Request (orange icon) in the application’s Data page as well, which then also shows a DevAddr, even if the device somehow does not actually receive the Join Accept at all. So, do you see anything in the application/device’s Data page?
Note that seeing a Join Accept only proves that the AppEUI and DevEUI are correct. If the AppKey were wrong, TTN would still send the Join Accept based on that wrong AppKey, which the device could not properly decrypt when the AppKey does not match. But for now, that’s not your problem; you first need to see TTN accept the join.
Unless it’s a really short message which allows for trial and error, in general you cannot. The EUIs are registered to to OnYield Inc Ltd, so it might be an OY1400 LoRaWAN Industrial communication and control unit. But of course, your friend used it, so must have some information too? Also, that would be a different topic.
If the AppKey does not match between end-device and network server, the MIC of the Join Request is invalid and a Join Accept should not be sent to the end-device.
Good point, @jreiss. So, @khassan, yet another question:
I doubt that the TTN generated keys are used at all
It’s about changing the AppKey in TTN Console, to match the key embedded in the device.
Hey Arjanbanb,
I actually haven’t used any TTN generated keys. I have replace all the keys with the once i already had.
In Theory they match. But this is in theory. The only way i can 100% be sure is if i can check the keys which are on the Node itself. But that seems almost impossible if i am correct.
Hey arjanvanb,
My apologies. I really appreciate your help and the questions you are asking are perfect. It is has been my best day to day, so i am sorry for not giving you a complete answer. I will definitely answer all your question in a really good manner.
So once again, my sincere apologies. And i really hope that you are still up for the challenge and willing to share your helpful insights and knowledge. 
Hey arjanvanb,
where did your friend use it earlier?
My friend used it on a different network server. So he never actually configured here on TTN and the other server it not anymore available 
I remember him showing me that the data was coming in and he has been using it for couple of months before he deleted it on the other server and gave it to me to practice and get going with LoRa.
I have double/triple checked all the keys and also replicated it to TTN as they were provided by my friend and it still just shows me the Join request.
Luckily, my friend provided me with another device (temperature sensor) and he also gave me exactly the same type of information
So here, i did the same as before and made a new Application and registered a new device. But this case was different that the previous one, because now i could finally see the Sensor only and also receiving data from the Temperature sensor
I actually jumped up 
Still looking for the problem
It indeed seems that you were right @arjanvanb. The data that i got from my friend doesn’t match with the one on the sensor itself.
I need to do a bit more digging to see if I can find what keys are actually on the sensor itself.
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.