The TTN forum language is English , good for some but not others I guess.
If I follow correctly
I have a sensor added (Dragino LHT65) and wanted to bring it into the thethingsnetwork. But somehow I do not succeed, he never shows me that he has logged into the network. Lt. Instructions would then flash a blue LED regularly. I’m sitting here near the old town Köpenick, and according to the various maps, I would have here iegentlich cover? Is only the sensor broken or something wrong?
What have you done/tried? What config…will help others help you.
Created an app? Registered the device? ABP or OTAA. Etc.
Don’t know the specifics of your device what does documentation say about the flashing blue led etc.
If there are gw’s Near you have you contacted their owners? Can they see your traffic/join requests etc…
Are they part of a local community (Berlin close by is a massive community with >100gws & >100 contributors so sure you can get help there )…can you reach out to them for help…perhaps in your own language if searching the forum and it’s core language a challenge for you…
Give more info & im confident others will step in to help where they can…good luck
Hi,
Yes, i added an application with application euis from the LHT65 sticker and added a device with OTAA, device eui , application eui and the app key from LHT65 sticker. I double checked all that. But if i try to connect the device (hold key for more then 3 sec) the led flashes several times green , then red with 15 sec repeating time. And after 10 minutes or so no flashing led anymore. I never see a blue flashing led. Is there something i have to change before in the firmware with a serial connection or why i cant get a connection? according the coverage map i should have lora gateways here
Yes, - I recommend you join them - they have some good guys onboard , many of who are very active here on the TTN Forum so I hope they will pick up on this and help you .
Now to your specific position I had a quick look and you are right there are several GWs within a few KM of you both to the west and further away across the Muggelsee - which will be good for GW reach. The land area looks reasonably flat so I would expect any node at a reasonable height (try in upstairs rooms!) should be able to get to these GW’s is they have reasonable local elevation.
I suspect you problem may be that the nearest GW to you isnt a real GW - I believe/suspect it is a kludged Heltec based SCPF -aka a single channel GW - these are a nightmare to work with as they do not meet LoRaWAN spec nor do they handle traffic correctly. It may be several GW’s in range see your join request but the NS will ask this GW as the closed to handle the Join Ack and any downloads/confirmations which likely will not get to you:-) Can you drive closer to one of the other GWs and try to join there (East past the lake or further into Berlin community area?)
You will see lots of recent posts on the forum from people including myself recommending against these SCPF spawn of the devil for this very reason.
hmm.but yesterday i took the device with me to the middle of Berlin, Kreuzberg near Checkpoint Charlie. And connection did not work either.
And here at my home i am at maybe 15m heigh upstairs. At the screenshot of the map below where the label “Köpenick” is displayed, near the bridge
Really not sure what to suggest at this point then as I dont know your device…perhaps others will step in.
One thought is it may depend on just where you were around Kreuzberg as I believe there are several Single or (and at least one) Dual channel PF’s that operate around there…you may have been unlucky in being ‘serviced’ by one of them depending on the RF path and strongest signals etc, though if you were moving around the density of full GW’s in Berlin would suggest you should have been able to connect…start looking at the documentation and firmware for the device at this point… good luck!
That’s right. In order to sort out different reasons for the problem, I’d also suggest to try the device again in a zone where several gateways should be reachable. If there is still no connection, I would suspect a hardware problem with your node.
For further investigation into the problem it’d probably be best to contact TTN community people nearby who can help with gateway logs, SDR debugging, different nodes for testing at your place, general advice, and more.
Where did you get these details, and did you overwrite the details in TTN Console?
A TTN-generated AppEUI starts with 0x70B3D57ED. Of course, in the Application in TTN Console, you can add the AppEUI that comes with a pre-configured device, and then select that for the device. But you did not mention that, and the value you’re using is not registered to Dragino either.
Also: is the Join Request show in the gateway’s Traffic page in TTN Console, and when clicking it, do you see any errors?
With Your hint i managed to get the LHT65 working. It has a serial console which responses to AT-commands. And there is an AT-command to set the proper APP EUI (AT+APPEUI=).
The supplier sends me an other device with proper frequency band…but it doesnt work either. As i see i have same APP EU A000000000000100 on the sticker on the device and i set this as Application EUI in TTN. This is wrong? Which APP EUI should i set with the AT command you mention?
Should the device connect to LORA network even if i do not register it in TTN?
The AppEUI is a global application ID in IEEE EUI64 address space that uniquely identifies the entity able to process the JoinReq frame.
By definition, an EUI-64 address should be unique. In this case: unique per application, but Dragino should not expect customers to share an application, so each off-the-shelf device should have its own unique AppEUI (and DevEUI). As apparently Dragino uses A000000000000100 for all their LHT65 devices (which was not even assigned to them, unlike their DevEUI which is okay), in theory TTN would not be able to tell the applications of different LHT65 users apart.
I’m a bit surprised that multiple users can apparently add the same non-unique AppEUI to TTN Console, but it seems TTN only uses the combination of AppEUI and DevEUI:
Just to be sure: is the DevEUI indeed unique for each device?
But as it’s still not working for you, and as I assume you don’t want to be surprised in the future: apparently making it unique and using the AT-commands to set that unique value helps. One could simply use the value that TTN generates when one does not explicitly set a value in TTN Console.
No. Devices do not really “connect”. The gateway(s) will forward any valid LoRa packet to TTN, and one can see those in the gateway’s Traffic page in TTN Console. But TTN would not be able to find the AppEUI and DevEUI, so would not know the secret AppKey it needs for a Join Accept, and will ignore the Join Request. Also, even if somehow magically joined (or when using ABP rather than OTAA): where would you expect the data to go when the device has not been registered in TTN?
…and given my previous answer, and as that error is not mentioned in the posts above: what if the AppEUI on the sticker is bogus? Maybe there’s an AT-command to read the AppEUI that is currently configured in the device?
What does “internal” mean? Is that TTN Gateway just registered in TTN Console? If yes, then you’re part of the public network.
Devices don’t really “connect” to a gateway, but I understand that your device’s transmissions are received by your gateway, and maybe some other nearby gateway(s) too.
How long ago did you register that in TTN Console? And @tomber42, did you manage to register the very same AppEUI without seeing any errors, and if yes: when?
And @VictorMarinus I assume you don’t have the same DevEUI as well? (Above, A84041000181BD42 and A84041000181C7BF are mentioned.) Also, I wonder if things keep working for you if at some point others manage to register the very same AppEUI…
That’s no longer relevant now that it’s clear that at least one device was registered with that weird AppEUI, so the weird AppEUI on that device’s sticker matches the true AppEUI as configured in the device.
I mean it is the indoor model of the TTN gateway. Registered in my console since one week.
As I can see all the traffic of my LHT-65 on the gateway, I suppose my device is only using my gateway. Am I correct?
The LHT-65 has been registered 5 days ago.
And indeed the DEV EUI is different. ending with C7B7
Any gateway in its neighbourhood will receive it. If those are TTN gateways, then you can see the list if you go into the application’s or device’s Data page, and then click an uplink to see its metadata. Its gateways attribute is a list of one or more gateways.
You can find the AppEUI of Your App in the TTN Application Console. When You try to register a new device to the App the EUI ist shown as last field at the bottom of the Form.
To connect to the serial console of the device I used an USB-Serial adptor with an open UART-Connector (just four open black/white/green/red jumper-pin-connectors instead of the usual RJ45 or DB9 plug). Using the serial connector shipped with the device You must patch red to red, black to black, white to green and green to white (null modem connection). The default passwort is 123456 and Enter (You find it in the Dragino documentation)
Apply the AppEUI of Your device via the AT+APPEUI=… an then Your AppEUI including a Blank between each byte. With AT+APPEUI=? You can verify if the device has “swallowed” it.
I copied and pasted the DevEUI and the AppKEY (AT+DEVEUI=?, AT+APPKEY=?) into the registration form and changed the AppEUI on the device to the TTN-AppEUI and the device registered.
With AT+CFG You can retrieve the whole device configuration.
I recommend to download the AT-commands- and the operating-manual in its latest version from the Dragino support website. They are both really useful.
Recently I have got one Dragino LPS8 gatway and two LHT65 Sensors. I started them up at home near to the gateway and could finally connect both to the TTN. One mistake I made was to miss to put in the “APP KEY” beside the “APP EUI” and “DEV EUI” on the TTN Console. “APP KEY” and “APP EUI” are printed on the sticker inside the small carton box. So there is no need to reprogram the “APP KEY” to the one generated by TTN. You simply can overwrite it in the TTN console by the one from the sticker.
Regarding coverage: One of the sensors I moved arround 1km. I was disapointed about that it does not connect to TTN anymore. Today I think I found the reason for this in the specification lorawan1_0_2-20161012_1398_1.pdf. There is written “Adaptive Data Rate control may not be possible when the radio channel attenuation changes fast and constantly”. This likely happend to the sensor due to the move by car 1km far away from the gateway without any transmission (was set to 10min period).
With the second sensor I checked out the scenario by moving it to the cellar of my house. Same situation. In the logread of the gateway, I saw that the LHT65 was sending with spread factor SF7 and 14dBm (EU variant) before. This seems to be to less. After I restarted the sensor in the cellar by pressing the button > 5sec it got connected with SF12. Sensor back in the first place, the SF went back to SF8. So adaption works fine in this direction.
In case there was already a connection to TTN and the attenuation is changed rapidly, activate the device again.
for this very reason. 
