Ok. So I don’t need to know AppEUI. And once connected I could possibly reconfigure it to OTAA with downlink messages. Correct?
I ordered a similar device
and received it in the mail with a piece of paper with five number/letter combinations in this format:
T0004885
1838Nxxxx
647FDA00xxxxxxxx
647FDA80xxxxxxxx
F92072606BD7xxxxxxxxxxxxxxxxxxxx
I see that the first of those is a product number corresponding to Home Sensor Module, North America, PIR. I’m a beginner in these matters and not certain what each of the others would represent. Would they be: Dev addr, device eui, app eui and AppSKey in that order? Since I’d be wanting to use the device on the TTN network, I’ll be grateful if you find a solution in respect to your device. Thanks.
Hello there,
I am also a newbie but seems like your device is set for OTAA (lucky you).
T0004885 - this is indeed the product code
1838Nxxxx - I dont know about this one
647FDA00xxxxxxxx - most likely DevEUI (but maybe AppEUI)
647FDA80xxxxxxxx - most likely AppEUI (but maybe DevEUI)
F92072606BD7xxxxxxxxxxxxxxxxxxxx - AppKey
Hope this helps!
EDIT: I found out that 1838Nxxxx is the serial number of the unit
1 Like
I agree with @mhruska’s analysis. Also, things like DevAddr, EUIs and keys are usually given in a hexadecimal human readable representation, which only holds the digits 0-9 and the letters A-F (or lowercase a-f). So, T0004885 and 1838Nxxxx do not seem to be related to any of that.
Anyone having access to the gateway logs/traffic please see my earlier note about identifying OTAA vs ABP.
In LoRaWAN version 1.0.x (TTN is using 1.0.2 RevB) ABP needs DevAddr, AppSKey and NwkSKey, and OTAA needs DevEUI, AppEUI and AppKey.
That’s what I take from the user manual, yes. But I’ve never used the device.
1 Like
But when registering a device in Console using OTAA, I cannot fill-in AppEUI. This is system assigned. So I should either be able to change it in Console or change it on the end device.
Edit: Sorry. Just found out that this is possible in Application settings.
Thanks. I checked with the vendor and you guys were correct. The first two were product ID and serial number… the next were DevEUI, AppEUI and AppKey in that order.
And does it use OTAA by default? All, to assist future readers: what do you see in the gateway’s Traffic page, ABP or OTAA?
1 Like
A year ago, I set up three gateways and tested them successfully with TTN nodes. Two seem still to be working fine on top of 13-story buildings. The third gateway is on loan to someone in another city.
Meanwhile, I have forgotten much of what I learned in the process, having done nothing more with LoRaWAN while I have been waiting for off-the-shelf sensors at an attractive price. The prospect of the TTN generic node has reawakened my interest. But I’m out of practice.
On the TTN console, I did: “add application” and entered the AppEUI I had been provided and set the handler to ttn-handler-us-west since I’m in Boston, USA.
Then, in the Application, I went to: “register device” and added there the DevEUI and APPKEY that I had been provided by the vendor.
I’m not sure what else I perhaps should have done. Meanwhile although I took the sensor reasonably close to one of the gateways, the device continues on the console to show status: never seen. Frames up: 0 and Frames down: 0
And when I go on the console to the gateway (which was last seen just seconds ago) there’s no traffic visible under uplink, downlink or join. The counter shows received messages and transmitted messages but none necessarily at all recent.
The little sensor has a consistently flickering red light.
I may have forgotten to do something very basic…
The device says: Activation Method: OTAA
But I don’t know if that’s the Console’s well-considered assessment due to the characteristics of the DEVEUI, APPEUI and APPKEY. Or that may just be there as a default that I didn’t change. I don’t know.
My first guess would be that the gateway is not working. I’d expect it to receive some data every day, even when not yours and even when not from TTN users, on a 13 stories tall building? Or is it surrounded by even higher buildings? (I’d assume that the uplink counters als include traffic from non-TTN nodes, as gateways are just dumb forwarders.) Any chance you can test with a TTN node again?
Also, US gateways use a subset of 9 out of the available 72 channels, which either requires some programming in the device, or an initial ADR after an OTAA Join to get those settings. (But before ADR can start, you’d first need to see some OTAA Join.) Maybe the device is trying to join on another channel, and you need to be patient for it to randomly get to a supported channel?
1 Like
I’ve been struggling with a couple of these sensors for months now with similar problems. I’m new to all of this so I’ve been chalking it up to lack of experience. I’m using a Laird RG1xx for a gateway. I sometimes see messages on one of the sensors. I will reset the other and re-join then I will see the messages from the one that was reset but not the other.
Sounds to me like they use the same OTAA credentials in their code. (AppEUI, DevEUI and AppKey.) You’ll probably still see uplinks from both devices in the gateway’s Traffic page in TTN Console, but only the one that was reset last will know the correct secret session keys and the latest assigned DevAddr (which changes for each join), as given in the last OTAA Join Accept response.
(Also, the other device will use an uplink counter that is too high, since the join will have reset it to zero. But that’s irrelevant when it doesn’t even know the correct secrets.)
1 Like
I don’t at the moment have a TTN sensor node in hand, but may in the next week or two be able to retrieve one that I have lent out. And I plan to order a TTIG and generic sensor(s) as soon as available.
The roofs both have long range views… I’ve included a picture of the location of one of those TTN gateways. On the Gateway Overview page that one says:
Last Seen: 3 seconds ago
Received Messages: 2104
Transmitted Messages: 367
But when I switch from Overview to Traffic, there’s no traffic at all visible. On that page, does traffic stop showing at a certain time after a transmission/reception? Does that expire after a while, or when there’s an outage, while the “Received” and “Transmitted” counts on the overview page survive a reboot?
Thanks greatly for your input.
The gateway’s Traffic in TTN Console does not show historical data; you’ll need to have that web page open to see the packets come in. (And when you leave it open for a long time, then at some point you’ll probably see an error about some expired session.)
(Same goes for an application/device’s Data page, though there one might see recent historical data when one has the Storage Integration enabled.)
Given the (great) location of the gateway I’d really expect to see some traffic… 
2 Likes
Does anyone know if I should set Network ID on my sensor? If so, what is its MSB and LSB value for TTN? I would say that:
MSB = 00 00
LSB = 00 19
Is that correct?
The 7 bits NwkID is already included in the DevAddr, which is why a TTN DevAddr always starts with 0x26 or 0x27. So, there is no need to set anything else.
(For ABP, the DevAddr is hardcoded; for OTAA the DevAddr is derived from the Join Accept.)
Four additional “received messages” counted on one of the rooftop gateways within the past two days… which suggests that it may be functioning ok… just not seeing much LoRaWAN activity in the area (I doubt that the uplinks were from the KONA device).
Today I need to spend much of the day about 150 meters from the base of one of those buildings that has a TTN gateway on the rooftop. No line of site and it’s on the far edge of the roof from where I am now. I brought the Kona device with me and was surprised some hours later to see this below appear about an hour ago… I don’t know how to interpret it. That definitely is the device in the bottom of the join data… And the device is no longer flickering which it had done continuously for close to a week since I pulled out the plastic tape from the battery. I haven’t yet seen any gateway traffic though.
A little more action. I see now by opening up each line using the arrow on the left edge of each row that the item at the bottom in this picture was a join request, the next item up the list was a join accept. The next item was traffic from a non-TTN network (Senet). The top item is for TTN. I wonder if it might be my device that has been successfully given a new devaddr starting with 26? Or would that be someone else’s TTN device?
Later: While I was still at that location, I subsequently, every half hour or so, waved the Kona device around and saw corresponding traffic at the gateway.
So… next I’ll need to figure out how to translate the uplink payloads into sensor data that I understand. And will start with the decoder that @eggfriedrice kindly referenced on Jan 21 in this thread.
You can tell the current DevAddr from the device’s Overview page in TTN Console. Also, it might have shown in the orange Join Request in the screenshot, when scrolling to the right. (It surely does that when looking at a Join Request in the application/device’s Data page.)
1 Like
Can I connect this device to TTN and see temperature from the internet?
If yes, on which website could I do that (see temperature data)?