Just joined so very very green on all this, sorry if its a noob question!
I am trying to setup and register a heat monitor (measures kWh of heat produced by a gas combi) which I have been assured is LoRaWan compatible. Been provided with a selection of LoRaWan registration details from the manufacture as below.
So far I have, installed and setup a " The Things Indoor Gateway", setup an application and added the above AppEUI to list of application EUI’s. I then used both the console and the cli to register the device a few times to see if I can get any data.
I have been able to see the gateway connected through the console and briefly seen data listed in the data tab and packets received. I am aware of some of the issues with the console so understand that this is not reliable but I am happy that the heat monitor is transmitting a “hi there” message and the gateway is picking it up.
I am sure I am just not getting the device settings right, could someone point me in the right direction for adding it?
Would be useful to know what the device is - link to website preferable!
The console is just flaky on the Last Seen, the data is usually pretty good to go.
So, if you have your gateway setup and you feel that your device is transmitting and it’s reaching TTN, what device settings are you looking to change - it sounds like it is going to be very device specific but you could mean that you want to know how to relay them on to do something with them.
I am really just looking to get data from it and make sure its connected to my application before starting with integration with my web application to start reading data from it.
I can see data on the gateway ok, I think e.g. packets received on the console interface. But no data on the registered device when looking at the console or the cli. This make me think that I have not got the config/registration of the device correct.
So you think that actually the device is probably registered ok and ready to go? How do I check? I have set it up a good few ways but without a way to check that data is reaching my app its hard to know which way worked.
I see you are (rightly IMHO) trying an OTAA join but last screen shot shows “nil” for e.g. DevAddr etc suggesting device not yet successfully joined so you wont see any data. Have other keys been set correctly (finger touble and character confusion can be a real issue!). Also is actual device set up to do OTAA?
Can you see Join request on traffic page of GW?
Make sure your device isnt too close to the GW when trying…
List of details provided by Manufacturer in your OP suggests may be set for ABP. If so also try registering with ABP, then if successful look to reset for OTAA.
Thanks @Jeff-UK, I hope so been copying them out of a spreadsheet from the manufacture.
Yes I did see some join requests a few days ago the devices EUI on the gateway console interface.
I am contacting the manufacture to confirm if its ABP or OTAA by default.
I have just changed it to ABP again to see if I get anything as below and managed to manually set everything I could including the DevAddr to match details from the manufacture but no data yet.
Going to try and force the heat meter to send another request and see what happens.
Look at the Dev Addr for the device and see if that’s appearing in the gateway traffic tab - the Dev Addr is not unique across TTN but it’s a good quick check.
Note for TTN/TTI it should be 26xx xx xx or 27 xx xx xx is (as apears from above) it is 00 xx xx xx or 01 xx xx xx this is for experimental nodes with no network association - you should see the traffic in GW traffic page with the exp node addr but data wont be forwarded to a TTN app. I use these types of devices where I want to quickly test GW coverage and dont want to bother setting up a full app…if I see the message with the target node DevAddr I know its in range, job done
Thanks @Jeff-UK, So really to configure a device to be compatible with the TTN network I need to change the Dev Addr to one assigned to me by TTN when registering a device?
Ok got a response from the manufacture.
We always configure with OTAA (by default).
Lora settings can be changed sending downlink to the server, and the server will changed.
Will re-setup for OTAA, any one have any idea what is meant by:
sending downlink to the server, and the server will changed
Would this configuration be possible as part of the join process? I read the quick start guide for adding a device but its not clear what happens after you receive the join requests.
So my guess at the moment is that the additional settings I got on the spread sheet are just dummy settings to help get me the device EUI and some of the keys?
For ABP yes, you use the one that is generated by TTN when you setup or change to ABP
By some magic they are expecting you to know what characters to type in to the device page to send a message (downlink) to the device to configure it. Or does it come with an app (desktop or mobile) or webpage or something?
So what does the gateway’s Traffic page show in TTN Console? Sometimes it shows nothing, or only shows uplinks but no downlinks, all due to being unreliable. So, until you see some Traffic you may need to rely on what the Device’s Status and its Data page show you:
But if the gateway’s Traffic does show traffic, then that helps a lot: if it shows a Join Request (orange icon) while the device’s Status or DevAddr do not change, then you know that the configuration is wrong. You can validate the AppEUI and DevEUI as sent by the device from the Traffic page, so if those are okay then only the AppKey may be wrong. If it shows no Join Request, then the device is probably not sending one, or is out of reach. If it shows the Join Request and a Join Accept, then the device probably has not received that accept downlink.
No mobile app for the device but I do have optical serial connection to the device for setup and reading and I have also the LoRoWan documentation which describes what communication is possible with the device but not seen any options as yet to set the LoRoWan settings, have asked for clarification from manufacture.
Thanks @arjanvanb, I did not have any traffic this morning but after forcing the device to send again I got the following join request.
Have confirmed that the Dev EUI and the App EUI are correct. I then checked the AppKey and it was still the default one assigned by TTN when setup. I have now changed that and will try and force another request from the device.
Aside: DevEUI and AppEUI (and DevAddr) are not secret. Lucky you, as they’re still visible in the non-encrypted parts of the Physical Payload in your screen capture. You can see in an online decoder, and anyone could grab that payload from the air, in your neighbourhood.
Things like AppKey, AppSKey and NwkSKeyare secret. And the application payload of a data uplink is encrypted.
Thanks @arjanvanb nice tool, unfortunately, if I am using the tool correctly, I tried to test with my keys to see if I could get a decoded message and it just came up with fail, as below.
Interestingly through after resetting up and manually setting all the keys etc through the cli I now have a green dot but still “never seen”
I hope the decoder did not make you doubt your settings. What keys did you use?
The session keys AppSKey and NwkSKey (and the DevAddr) are (re-)generated whenever an OTAA Join Accept is accepted, so are not known yet at the time of an OTAA Join Request. So, for an OTAA Join Request, you need(ed) to enter the AppKey in the AppSKey field, and enter dummy data in the NwkSKey. I’ve just added a bit more documentation about that, and made NwkSKey optional.
The screenshot now showing a DevAddr implies that at least one Join Request was successful, but then I’d also expect to see a timestamp for Status. Maybe I’m wrong and maybe for a first join that’s only set after a regular data uplink. Or maybe it’s a leftover of earlier tries with ABP for the same device?
If you’re still in doubt if the settings are okay then I’d delete the device and add it again. OTAA seems to work just fine for you.
For a regular uplink you may also want to use the online decoder, to check if FCtrl.ADR is set: your OTAA join uses the worst possible data rate, DR0 a.k.a. SF12 BW125, and it would be great if TTN can use ADR to tell the device to use better settings.
Thanks @arjanvanb I used the keys supplied from the manufacture.
Ahh ok as I have not received a join request into the device within TTN yet I have not seen this step/process. Can you point me to the documentation for this as I have not found that or missed it, sorry.
Beware that if the device did in fact receive the OTAA Join Accept, it will no longer try another join. Instead, it will be sending data uplinks, but using a DevAddr and secrets that are no longer known to TTN. So, keep an eye on that gateway Traffic page!
Thanks @arjanvanb have not read it all yet, but just a quick update, still not working
I just got a join request coming through the gateway as below.
but its not hitting the registered device on the TTN network as below.
Am I right in saying that if the join request was getting through to the device on the TTN network that I should see a join and acknowledgement sequence on the data tab for the device as below?
The issue must be down to rooting and how the request is being picked up by TTN?
Yes, if the configuration of device and TTN match, then you should see an Activation (orange icon) in the application and device’s Data page, if you have that open at the time the Join Request is received. And even if not open, you should see a DevAddr on the device’s Overview page after an accepted Join Request.
From the screenshots, it seems the AppEUI and DevEUI are correct. You can use the online decoder with the AppKey to see if the AppKey is correct too (leave the field for NwkSKey empty); probably not. You may want to reverse the bytes in the key (say, from 01 02 03 ... 15 16 to 16 15 ... 03 02 01) to see if that helps in that online decoder. And if not, use some of the other values that the supplier gave you? It would not be the first time a supplier messed up the keys:
…and from the same topic quoted above, for another device than yours:
Anyway, you can use the online decoder to check; you know that the gateway is receiving the Join Requests, so for troubleshooting there is no need to wait for another Join Request to be sent by the device. Just ensure that the online decoder shows that the MIC is valid and then you know which value for the AppKey to configure in TTN Console.
Ok, to be supper clear, if I understand correctly I have used the decoder to and copied in the payload from the join request.
I then pasted in all the keys I have into the “Secret AppKey or AppSKey” field and you would expect one of them to NOT to say “Invalid” on the MAC line… unfortunately they all did
Could the two possibilities be that I have the wrong KEY’s or could it be that the device is just not sending right. I then checked out the interface for the device and I see an option for AES key? as below.
I am trying to get more information from the supplier on this but in the mean time I am going to try and set the AES value and see what happens.
been copying them out of a spreadsheet from the manufacture.
