Any support questions you might have can be asked here:
https://www.thethingsnetwork.org/marketplace/product/kona-all-in-one-home-sensor
Hey
I’ve written a TTN decoder for these sensors, here: https://github.com/SensationalSystems/tektelic-kona-decoder (not entirely complete as it doesn’t handle all the payloads yet, but it’s a start!).
We’re started selling these at https://connectedthings.store and our first batch sold out pretty quick, we just have our second batch of the “base” model in, and more of the PIRs arriving in the next couple of weeks. They’re really nice devices, well made and highly configurable.
Cheers,
Al
3 Likes
Hello,
I got TEKTELIC T0004897 Kona Home Sensor Module (EU External Connector). The problem is that it is preconfigured for ABP. I have below params:
- DevEUI
- DevAddr 1f2609dd
- NetSKey
- AppSKey
As you can see DevAddr does not start with 0x26 or 0x27 which I understand is a condition to work with TTN.
Would anyone know how to get out of this? Is it possible to change this sensor somehow to OTAA (factory reset maybe)?
Thanks for your reply in advance!
T0005370_TRM_verRevC-1.0 (2).pdf (550.6 KB)
1 Like
Skimming the documentation (thanks!) shows the device supports OTAA. But the only way to configure it is by using downlinks?
I’d assume it’s configured for OTAA by default, as then you could connect to any network, and then fine-tune it using downlinks. Do you have access to a gateway log? (Like in TTN Console, the gateway’s Traffic page?) If yes, then I wonder if you see an OTAA Join Request there. That would reveal the DevEUI and AppEUI, but not the AppKey, so still doesn’t help you much, but tells you it’s using OTAA. But if you see an uplink with the known DevAddr, then you know ABP is used (and ignored by TTN).
If OTAA is enabled by default, you need more details from the manufacturer.
If ABP is enabled by default then you’re out of luck with TTN, if only as the ABP and OTAA configuration is marked as RO, being read-only. Some other networks (not TTN) might allow any DevAddr though, even though that’s really not how things should work. (Like apparently in September 2018 both Loriot and Blink Services accepted a DevAddr that was actually assigned to the KPN network.) You could then use a downlink to reveal the LoRaWAN MAC configuration (DevEUI, AppEUI and AppKey) and after that configure it to switch to OTAA, and use it on TTN.
1 Like
Thanks for your explanation. Just a question to better understand: if I managed to change devaddr to 0x26… would it help to connect the device to TTN with other 3 parameters that I have (using ABP)?
If you can change it to the TTN-assigned DevAddr: yes, you can then copy the device’s AppSKey and NwkSKey into TTN Console. But you cannot use just any DevAddr that happens to start with 0x26 or 0x27: TTN uses a scheme in which other parts of the DevAddr also may have some meaning.
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?