No join response for tabs temperature sensor

End Devices (Nodes)
#1

Hi,
i recently started with lorawan/ttn and successfully registered my own gateway (dragino lps8).
Ttn says it is ‘connected’.

Now i’m trying to set up my first temperature/humidity Sensor (tabs tbhh100).
These sensors are pre-configured, so when i bought it, i got dev eui, app eui and an app key.
Both gateway and sensor are using the eu-868 frequency range.

Next step was to create an app in ttn console and to register this sensor with those given values.
The app contains both the ttn generated app eui and the given app eui.
Now this sensor sends join requests which i can see in my gateways traffic overview (using different frequencies, backoff strategy etc).
The request contain the dev eui, app eui and app key (and the values are correct, just like the ones i used to register that sensor device - i already checked that multiple times…)
And the request has an encoded payload field, which contains a dev nonce value, which gets incremented with every join message.
So from my point of view everything seems to be correct.

If i understand that right, ttn would have to send a join response, but i can’t see anything like that - neither in gateway traffic list nor in the data overview of the device itself
And aside from that there’s no error message at all (at least i can’t find anything like that)

What can i do to debug this situation? How can i find out what’s going on , if ther’s any error with ids/eui, payload etc? What settings should i check?
I kindly appreciate any help!

regards
Frank

#2

TTN will record and reject all DevNonces the device ever used before, so make sure you’re not testing with values that start at zero. See OTAA shows "Activation DevNonce not valid: already used" for a workaround. (Also, an incremental DevNonce sounds like a LoRaWAN 1.1 device. The TTN community network uses 1.0.2, but 1.1.x devices should be backwards compatible.)

A Join Request should not hold the secret AppKey. It should include a MIC (calculated using the secret AppKey), like any message. Is that what you mean, and is that what you validated to be correct? You can validate the MIC of an OTAA Join Request using this online decoder and set a dummy value for NwkSKey, and paste your AppKey as known in TTN Console as the AppSKey.

Do you think that the AppEUI and DevEUI you got with the device are unique? (They should be. And they are not secret.)

#3

Did you set the device to the right AppEUI? Just adding it to the application does not mean the device will use that appeui when you create a new device.

1 Like
#4

according to the message/payload decoder the DevNonce-values have been incremented with each message (i decoded the payload of some consecutive messages during the last two days)

unfortunately i’m currently not seeing any join message at all
i think the sensor uses some kind of backoff strategy when sending those messages… seems like it’s having a break at the moment :slight_smile:

and - my fault - the join requests didn’t contain the app key, only the dev eui and app eui…
what i meant - i double checked the app eui and dev eui to be the same in the join requests (coming from the device) and what i entered in ttn console as the device configuration

i’ll try to check the mic values when the next join requests will be available

and how can i know if the app eui and dev eui are unique? they look pretty random to me, but…

do you think i should copy a join request and post it here?

#5

i think i set the correct app eui for the device
what i’m not sure about is that the device came with its own app eui (58A0CB…) which of course is different from the app eui generated by ttn (70B3D5…)

i already tried different setups/configurations
a) application with both app eui + device set to each of them
b) application only with app eui given by the manufacturer + device set to this app eui

do you think that the pre-configured app eui might cause the problem?
acccording to Adding Application with specific AppEUI that might be possible
but i’m not sure if i can change/set the app eui of my sensor…

#6

You could first check if they are a properly registered EUI-64. We’ve seen very simple AppEUIs that are clearly not registered to the manufacturer of the devices, but if yours look random then they’re probably fine (though likely not random, but that’s great).

Its details are not secret; the message is not encrypted and anyone in your (wide) area could receive it. So you could surely post those, and a screenshot of the device settings, if you want an extra pair of eyes to check. The AppKey is secret of course, so you’d better validate the MIC yourself.

I doubt that, but it’s actually easily tested with another (even different) device, if you got one? Note that @laurens uses a Tabs GPS, which seems to work fine, and likely also uses the built-in (non TTN-generated) AppEUI.

Any chance that at some point you deleted the application from TTN Console without first deleting its device? (Don’t do that.)

I assume there’s no (easy, non-destructive) way to disconnect the battery for a bit? (Like could one re-insert the plastic piece that needed removal before using it?)

#7

wow, i finally found the solution…
i checked the MIC with the online decoder you mentioned - and it was invalid
i copied app eui and dev eui from the join message, so only the app key could have been wrong
(but it definitely was the pre-defined value given to me by the distributor of the tabs sensor device!)
i went with my gut feeling and just tried using the given nwkskey in place of the app key - and bingo! i got a valid MIC
the distributor just mixed up the values…

now the join request got accepted by ttn and i’m seeing the first regular sensor messages

thanks a lot for you help and pointing me into the right direction to validate the MIC!

2 Likes
Noob - Setting up Axioma Qalcosonic E3 Heat Monitor device - all preconfigured!
#8

If they gave you a “nwkskey” for an OTAA mode device, then they are indeed quite confused.

When using OTAA the nwkskey is dynamically generated from the join exchange.

#9

The tabs node T-RH did give me the same problem with the Join action. AppEUI and DevEUI are correct reported in the console gateway traffic. But Join did not work.
Here under the information i got from the producer of the node:
Tabs T-RH node b
The “data”, “payload” received in the console givesTasbs decode

At this moment i dont now the next step, please can you give me a hint.
Where can i find the nwkskey to replace the app key.

#12

So, did you enter all 3 values (DevEUI, JoinEUI as AppEUI, and Network Key as AppKey) into TTN Console? See Registration of node with pre-configured LoRaWAN keys.

For the Join Request you could also validate the MIC by copying the value labeled “AppKey” on your scanned image into the field AppSKey of that online decoder (and just leave NwkSKey empty), to ensure that’s indeed the value that the device uses as the AppKey.

(Please don’t past images for what is text; like the output of that decoder.)

#13

Thanks verry much. The online decoder gave me the information that both Network Keys were not correct, INVALID MIC.
Looking around at Antratek found that the prescription was not correct and that you should ask for a valid AppKey for your sensor. Antratek responded verry fast with a valid AppKey. That dit the trick.
Now the tabs sebsor works correct.

Your advice was a big help for me, and now i now a lot more about DevEUI, AppEUI and AppKey.

1 Like
Noob - Setting up Axioma Qalcosonic E3 Heat Monitor device - all preconfigured!
#14

Ok, having the same issue. I have been given all of correct data, deveui appeui and appkey, I have created an application and set the appeui, created a device with the given deveui and provided appkey. Powered the device up and I see traffic from my gateway, and do see the join request with the correct dev eui and app eui, the physical payload decodes fine. But the device does not join and is never “seen”.

Assuming hex-encoded packet
004136010100E1E1E804C5040100E1E1E88D5D0F02ED83

Message Type = Join Request
PHYPayload = 004136010100E1E1E804C5040100E1E1E88D5D0F02ED83

( PHYPayload = MHDR[1] | MACPayload[…] | MIC[4] )
MHDR = 00
MACPayload = 4136010100E1E1E804C5040100E1E1E88D5D
MIC = 0F02ED83

( MACPayload = AppEUI[8] | DevEUI[8] | DevNonce[2] )
AppEUI = E8E1E10001013641
DevEUI = E8E1E1000104C504
DevNonce = 5D8D

#15

Did you got it solved @Slywombat ?
I have 4 tabs here now and only the ones with the AppEUI/DevEUI starting with 58 will join, the ones with E8 will not (“MIC Mismatch” is the error code from the things stack v3). Guess i will contact the vendor for working keys…

#16

I tried configuring with v3 as well with zero success. Gonna chat with browen tomorrow.

#17

I got new keys and the sensors are now working! Thank you @laurens and cameron from sensational systems for sorting this out.

#18

I got the new correct keys as well, and all is good. The V3 dashboard also helped a bit since it gave a bit more info as to why.