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?
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.)
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?
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…
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.)
“Can I connect this device to TTN and see temperature from the internet?”
If you are in the U.S., you should be able to use the device (Tektelic producte code T0004885) that I linked to above (Feb 25) to connect to TTN, presuming there’s an active TTN gateway within range, and then see temperature data using the TTN console.
I don’t yet know how easy it would be to have the traffic forwarded to a site like Cayenne to have a better dashboard for remote monitoring. https://mydevices.com/cayenne/features/lora/
If you want to be able to do it soon, you might consider instead using The Things Node, which I’m confident integrates relatively easily with a dashboard like Cayenne’s.
And if you’re not in a hurry, perhaps wait for the TTN generic node.
A device is registered to an application. So, first create an application; this does not (yet) use any of the values provided with your sensor so just use whatever you like. After creation, go into the application’s settings and select “EUIs”:
Hi. I have successfully registered a Kona Micro gateway to TTN (us-west.thethings.network). Successfully registered a Kona Home Sensor and Kona PIR sensor. When I start the sensor OTAA the first time, it attaches and sends a payload. But then I don’t get any more traffic unless I reset the sensor. What am I missing that is keeping the data from the sensor to keep being sent to TNN?
I only changed the basic constructs in the gateway via KonaFT [added gateway_ID, changed server address, added aes_key].
