Closed ymgupta closed 2 years ago
Hi @nejraselimovic,
Here is an additional case to document apart from the points mentioned above.
Getting no decoder defined for codec {codec_id}
error after every downlink message.
Cause: The downlinkEncoder
and downlinkDecoder
functions are not defined in the codec file of the device in the Device Repository.
Resolution: Reach out to the device manufacturer in this regard to update the downlink payload encoder and decoder in the Device Repository. Alternatively, add the downlink payload encoder and decoder in the TTS console (if you know it) by selecting the Formatter type as Java Script
.
Summary
Add the commonly encountered device join and downlink issues described below to the troubleshooting guide.
Scheduling a downlink from The Things Stack Console is disabled with a warning Simulation is disabled for devices that skip paload crypto
section heading.Why do we need this?
Adding common device join and downlink issues to the Devices troubleshooting documentation will be useful for the Users.
What is already there? What do you see now?
Troubleshooting Devices
What is missing? What do you want to see?
Add the below troubleshooting points in the documentation.
My device had the correct AppKey configuration. Still, the device is failing to join the network with a MIC mismatch error. What do I do? (Add this point in the My device will not join. What do I do?) Cause: When devices are configured with LoRaWAN version
1.0.x
and have both AppKey and NwkKey, the Network Server considers that the device is capable of LoRaWANv1.1
. In such cases,NwkKey
will be used for MIC and session key derivation in TTS when activating the device, even if the LoRaWAN1.0.x
is configured for the device. In that case, the physical end device is also expected to use its NwkKey, not AppKey. If not, joins will fail withMIC mismatch
error. Resolution: Use the below command to unset theNwkKey
of the devices if the device configured with LoRaWANv1.0.x
and also containsNwkKey
.I scheduled the
Reset downlink command
to my device as a confirmed downlink, and now the device is in a continuous Join loop. What do I do? (Add this case in the My device is stuck in a continuous join loop. What can I do? section)It is not recommended to schedule a confirmed downlink to reboot the device as the confirmation from the device will never arrive. To avoid these problems, schedule the downlink commands to reboot the device as an unconfirmed downlink. For the affected devices, use the
Reset session and MAC state
option in the TTS Console to clear the session (including the downlink queue) and then manually rejoin them.This might be due to the end device not answering the MAC commands scheduled by the Network Server. Due to this, the Network Server will continuously schedule the MAC commands until the end device answers them. Enable the
Verbose stream
option in the device Live data section to identify which MAC commands are not answered by the end device. Ideally, the device is expected to answer the MAC Commands scheduled by the Network Server. We recommend you to check with the device manufacturer to sort the issue at the end device level.The Network Server contains large amounts of checks that try to ensure that the end device MAC state and MAC settings are valid with respect to band and frequency plan definitions. Hence, updating end devices frequency plans is not supported in TTS and should always be achieved by recreating the end device.
payload crypto
spelling in Scheduling a downlink from The Things Stack Console is disabled with a warning Simulation is disabled for devices that skip paload crypto section.How do you propose to document this?
...
Can you do this yourself and submit a Pull Request?
No.