I have a SenseCAP CO2 sensor and M2 gateway. When the sensor sends a join request it looks like nothing happens. not sure where to start on figuring this out.
When I look at the application and the end device the message i see is āJoin-request to cluster-local join server failedā MIC mismatch
Forum search for the win??
It means the radio path is working, but the OTAA credentials for joining the network are rejected by the join server.
This could be the credentials simply being incorrect, or entered incorrectly in the TTN console, e.g. dev EUI and app/join EUI swapped, dev EUI and/or app/join EUI entered with wrong endianness. If you have the gateways logs, you can at least see if the join request device EUI and app/join EUI are the correct values and entered in the correct order.
When I look at the settings of the end device and use the AppEUI DeviceEUI and AppKey from there the device does not produce a join request ever. But when I push the sensorās button a different appEUI/JoinEUI is shown in live view. so I created an end device using that new value and that is when i see the error.
There is a āJoin settingsā section on the āgeneral settingsā tab. Do i need to configure any settings there?
Message no longer has āMIC mismatchā, but still failed
What do you see on the GW console view? How close are the device & GW - make sure not too close - remember this is a Long Range technology and devices struggle if shouting at each other 
(Forum search)
ummā¦ well they were sitting right next to each other. now the sensor is about 20 ft away. below is what my gateway view looks like:
RSSI way to high for reliable device debug - as before Forum Search for seperation guidance (actually, its about RSSI management) - you dont want to be debugging RF issues and strange behaviours at same time as trying to debug set up/config issues - look for the goldilocks range - close is fine - if you have absorbers in between to reduce RSSI to manageable rangeā¦
P.S. no point redacting details - as you can see they show in GW console and hence in public domain - any GW hearing your node will show same details! - Only the Key is best kept secret - and Dev Addr is in a limited bounded range and hence many devices may have same value - its when used in combination with the other details/credentials that the LNS is able to route traffic correctly
Actually @808geek just noticed you are using Confirmed Uplinks - Please Dont! - Turn this off before we get into detailed assistanceā¦ (Again forum search will reveal a lot of discussion/guidance (direction!) on this - also ties into TTN FUPā¦)
I am very new to all this and appreciate your advice. I am searching and reading, having small hints help.
If you really want to hit the ground running, read this:
https://www.thethingsnetwork.org/docs/lorawan/
The fundamentals is the smallest amount to know to make good progress.
your battery are goin to last long, looks like you are sending every 10s a uplink?
Issue resolved: 100% related to being new at this. After plenty of reading it was clear that my EUI/Keys were not correct. With some tips from SeeedStudio I was able to sync all EUI/Keys up and sensor join was successful. 
1 Like
Be sure to follow TTN FUP - avoid/turn off confirmed uplinks (trigger downlinks and you are only allowed 10 DL/day - think more like 10/fortnight!), change the 10s update rate (think more like 10min or even 10 hrs!) - see below for useful tools when planning application use cases: play with payload sizes and remember you cant gurantee to use shorted airtime SF