That is not a LoRaWAN gateway.
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.
Get a TTIG (the things network indoor gateway) or LPS8 from Dragino.
No.
Appreciate the problem, these devices are not LoRaWAN compliant and the manufacturer does not recommend them for TTN use.
When powered up they can disrupt the connections of compliant nodes, you may not know the problems you are causing.
So given that, how likely is it that the TTN forum will now publish information or provide support to get them working ?
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…
Stefan
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?
Thanks Arjan, TTN keeps sending these messages for just the one device, so something must be wrong. Devices are using OTAA without any issues …
Hello,
I have LHT65, I connect it to thethiungnetwork. But receiving errors. I use cayenne lpp.
{“error”:“Unable to decode payload fields: cayennelpp: unknown type”}
any help?
The v1.7 version uses:
//SHT20,temperature,units:℃
TempC_SHT:((bytes[2]<<24>>16 | bytes[3])/100).toFixed(2),
That yields a text result. To convert to a proper JSON number (which will output 5 for "5.00" and 5.1 for "5.10"), prefix with a plus:
// SHT20 temperature; unit: °C
// Sign-extend to 32 bits to support negative values, by shifting
// 24 bits to the left (16 too far), followed by a sign-propagating
// right shift of 16 bits, to effectively shift 8 bits. And unary plus
// operator to convert string result of toFixed to number:
TempC_SHT: +((bytes[2]<<24>>16 | bytes[3])/100).toFixed(2),
// SHT20 humidity; unit: %
Hum_SHT: +((bytes[4]<<8 | bytes[5])/10).toFixed(1),
Actually, as dividing by 100 should never yield excessive decimals in JavaScript, I’d remove the toFixed. (This would be different for, e.g., multiplying by 0.01, like 2224 * 0.01 yields 22.240000000000002, while 2224 / 100 is simply 22.24.)
(There are a few more occurences in that code.)
And aside, the following:
//DS18B20,temperature,units:℃
TempC_DS:
{
"1":((bytes[7]<<24>>16 | bytes[8])/100).toFixed(2),
}[bytes[6]&0xFF],
… could be written as:
TempC_DS: bytes[6] === 1 ?
+((bytes[7]<<24>>16 | bytes[8])/100).toFixed(2) : null
Still ugly, but that’s due to using return without any temporary variables. I’d use some switch-case instead.
I wonder if think the 0xFF in bytes[6] & 0xFF is an error. It has no effect. All other code uses 0x7F instead.
How do pin the SF to a certain value on the LHT65? Have not found a clear answer in the manual. I have range problems and like to pin it to SF12.
SF12 significantly restricts the number of packets you can send a day, maybe 20 max ?
You have to disable ADR
AT+ADR=0
after that you can set the datarate:
AT+DR=5
Please consider the restrictions mentioned before by @LoRaTracker and @arjanvanb.
As the battery isn’t replaceable and SF12 sends for quite a long time you’ll transform your sensors worthless in a short time. So, what’s the matter with ADR?
Hello,
I have a Dragino LHT65, but I can’t connect it to Objenious network in France (Spot platform).
Is it possible?
Sounds like that is not The Things Network so may-be use another forum?
Hello,
I use two LHT65 with the TTN Indoor gateway.
I try different frequencies on the sensor. In all cases the packets are received and logged (TTN gateway page) by the gateway.
However, only packets received on channel 0 (868.1 MHz) are forwarded to TTN.
Is this a known feature?
If packets are listed on the gateway page they are in the TTN backend and have been forwarded to TTN.
Do you mean you are only seeing packets on that one frequency in the application page? If so, can you open the details and check the EUI of the gateway matches your TTIG?
This is most definitely not normal behavior for a TTIG.