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.
My understanding of a gateway is that it forwards packets from the sensors to TTN.
I added the EUI of the gateway in the application settings, but without any effect. The packets that now arrive at the gateway on the frequency 867.5 MHz do not appear in the application.
The gateway forwards the packets to TTN, in the TTN console you can view those packets in the gateway part for the console of the gateways you own. Next TTN tries to match the packets with an application and forwards them if a match is found.
As you seem to be seeing packets in the application (please confirm) the application has been created correctly and the devices have been added correctly to the application.
In the application data you can view the uplink packets and their detailed data, I was asking to open the details and look at the gateways listed there. There should be one or more gateways listed with the gateway EUI.
Please delete the gateway EUI from the application as it is not needed there.
Things to keep in mind: you will only see data in the console that is received while the page is open. The TTN console does not list historic data (unless the data storage has been enabled for an application in that case the application page might show recent packets listed historic)
Both LHT65 have the same APP EUI A0 00 00 00 00 00 01 00. If I set the APP EUI on the LHT65 with the frequency 867.5 MHz to the value of the application, the data packets of this sensor are also displayed in the application.
Your LHT65 devices should be configured to use OTAA and 8 channels as delivered from factory, not 1 channel. Please reset the LoRaWAN configuration to use 8 channels to comply with the standard.
I have an lht65 connected to my ttn indoor gateway that is working fine, send the data to cayenne (my devices) and to the storage integration. I can see the messagebin the console and decode the payload.
The problem is when I try to move the lht65 away from my gateway… I live in Milano (Italy) and I drive around the city (taking a look at the network coverage) but I was unable to get the lht65 connected to the ttn network.
As soon as I returned at home It start again to send data.
Any idea?
thank you
First, hopefully you are not creating a new “connection” as in OTAA session during this, but merely experimenting within the existing connection. OTAA re-joins are something you want to avoid having happen on more than the rarest occasions of maintenance.
What spreading factor is your node running at? If you are using ADR, then when close to the gateway it would have adjusted to a fast, short range spreading factor such as SF7 or SF8. To work at a longer range it would need to be at a slower spreading factor. Given enough time, and ADR node would eventually slow down to this, but it might take a substantial number of hours (quite possibly more than a day) to make the adjustment.
Typically for mapping people will use a fixed spreading factor rather than ADR. Using SF12 even if it is legal in your location isn’t really considered proper unless achieved via ADR. Probably something like SF10 with brief packets several minutes apart would be good for range testing.
First, thnk you for the answer.
Of course I’m not creating new connection, but just moving the lht65 around the city.
How can I know the actual sf? and how can I change it?
Sorry but I’m nuwbie and just approching the technology.
thnk you