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.
Very true. But just curious: did you get the same non-unique AppEUI A000000000000100 like the others in this topic? Also, I’m starting to wonder if people get different values for the AppKey…
I have got the same AppEUI A000000000000100. This looks to be ok. See: Addressing and Activation. I do think that the application is the LHT65 itself.
Unfortunately my coverage issue could not be solved by activation of LHT65 (placed outdoor in a wooden beehive) once again, 1km far away from my indoor Dragino LPS8 gateway (placed in 2. floor under the roof top made from concrete roof tiles). This is not that far away, isn’t it? The area is a standard settlement with houses in the same height as my one.
I am at a loss. Does anyone know, how to improve the range (beside outdoor gateway or antenna)? Is it that Over-the-Air Activation (OTAA) is not possible on that range and I should try Activation by Personalization (ABP)? Any experience with simliar setup would be helpful as well
No, it’s not okay: an application is not defined by a device type. Even a single customer should be able to define multiple applications using the very same device types. Also, this is not even a valid AppEUI, and who knows if Dragino or another manufacturer isn’t using the very same AppEUI for another device type. See my earlier answer above.
That said, it’s nice, and weird, that this works for some of you (at least with the current version of the TTN stack) while others needed to change the AppEUI to get things to work. I’d not risk having to fix this later though, and I’d give the devices a proper AppEUI before deploying them.
As for coverage: the activation method does not matter. if ABP works but OTAA does not, then such only implies that uplinks work but downlinks don’t, or not that well. In that case ADR would not work either (and you’d need to explicitly program basic network settings as well). Also, just to be sure you know: you should not do an OTAA join very often, and once joined there’s no difference between OTAA and ABP.
Hello Guys.
It will be great if you‘re able to assist me as well. I‘m running a Dragino OLG-02 and I have 3 Dragino LHT65 Sensors.
The gateway is Running properly and is listed in the TTN as online. When I try to connect a LHT65 sensor, i do not geht valid data.
In the console i can see Device traffic, but just „Join request“ and „Join accpet“. No other data.
For the application i can see for that sensor just activation packets…
What is Running wrong and how can I fix it?
I know, that this gateway is not optimal, but isnˋt ist enough for some testing?
Do you think, the gateway is causing the problem? What will be a cheap alternative device for europe frequency? As i only want to connect 3 sensors it must not be that „Professional“. Sadly there is no other available gateway that can be used by me.
After the accept you node will use any of 8 channels and one of the possible spreading factors within that channel. Chances of that combination matching your non compliant gateway which listens at far fewer channels and spreading factors are about 2 percent.
I just want to give a short update. I´ve replaced the gateway by a Dragino LSP8 as suggested. That solved my problem. Sensor is no sending data.
Thanks for your support…
No sure if this is the right topic, but it does concern a LHT65. I received two pieces and connected with success however I do see something strange happening. One unit started to receive downlinks after 64 successfull uplinks. The downlink seems an empty message targeted for port ‘0’. The other LHT65 is not receiving these downlinks. There is nothing in the visible downlink queue … what to do, I expect these downlinks to have negative impact on the battery life.
That’s ADR and is telling your device to change its settings. Assuming the device is handling it, it might actually improve your battery life. See What are these port 0 downlink messages?
But if the device keeps getting the same downlink over and over again, then something is wrong. It might not receive the downlink, it might not process it, or it might be using ABP (or OTAA, with last join before October 2019) for which TTN has a bug in some fallback.
Concerning the Spreading Factor: On my devices I disabled ADR. as it burned the battery by a staircase effect. In a quite regular interval the SF got up to 12 and then back to 7. Tested this with two devices in 10m distance to the gateway, so reception wasn’t a problem. Just pinned the SF to 7 and now everything is fine. Anybody else with this problem?
