I have Chirpstack up and running on a Raspberrypi and was able to connect my Multitech Conduit-AP gateway. Now I’m trying to connect end devices but they can’t seem to join. I followed this guide: Connecting a device - ChirpStack open-source LoRaWAN<sup>®</sup> Network Server. I get a JoinRequest but there is no response. The guide referenced the Device data tab I assume this is the events tab under device where no data is displayed. The requests can be found under the LoRaWAN frames in the device section and the gateway section. I tried to let the device join using OTAA. I did this by setting the LoRaWAN version to 1.0.3 found on the website of the device producer. Set the device EUI and this matches the EUI used in the Join-Requests. I didn’t touch OTAA keys since if I understand correctly this is only applicable for version 1.0.0 and my devices use 1.0.3. The devices I used are the Dragino LoRaWAN Temperature Transmitter: LTC2-SI and the Dragino LoRaWAN RS485 converter: RS485-BL.
I tried restarting the gateway, server and gateway bridge. Tried joining with two different devices. Screenshots provided with the information I have.
I am not sure what steps I can take to troubleshoot the problem and couldn’t find a solution in other topics on the forum. If anyone knows what steps I could take to troubleshoot the problem or link me to documentation that might help.
Edit:
I found out how to check the chirpstack logs and found this:
Nov 18 13:36:36 raspberrypi chirpstack[1129]: 2022-11-18T13:36:36.808096Z INFO chirpstack::gateway::backend::mqtt: Message received from gateway region_name=“eu868” topic=“eu868/gateway/0080000000021ed9/event/up” qos=0 json=false
Nov 18 13:36:37 raspberrypi chirpstack[1129]: 2022-11-18T13:36:37.012332Z INFO up{deduplication_id=6a82426f-839b-4d99-89c4-32f49a1f06e1}: chirpstack::uplink: Uplink received m_type=“JoinRequest”
Nov 18 13:36:37 raspberrypi chirpstack[1129]: 2022-11-18T13:36:37.027710Z ERROR up{deduplication_id=6a82426f-839b-4d99-89c4-32f49a1f06e1}: chirpstack::uplink::join: Handle join-request error error=Object does not exist (id: a840417351851d4e)
Handle join-request error error=Object does not exist (id: a840417351851d4e) for both devices does anyone know what this might point to?
@NULL1
Dragino instructed me on how I could access the appkey data through AT commands. I double checked if the appkey they provided was correct. I used “joirnalctl -u chirpstack -f” to view what was going on.
Could you provide me with some more information about your problem? How did you connect your device using the appkey?
Thanks for your time.
I connected all my dragino end nodes through OTAA using APP key and Dev EUI. I’m having problems with just one, and it already worked.
You changed APP key that’s it? I already thought that, by changing APP key it should generate a new APP key session for this particular end node. It worked fine?
Thanks
Hi NULL1
I also reinstalled and set up the database dependancy for Chirpstack I think the problem was the app key but can’t be sure for me everything works fine now.
In your post you mention you checked the AppEUI you need to fill in the correct AppKey to complete the handshake.
I don’t know what nodes you are using but with Dragino you can check the app key through a Serial terminal with an AP command. I have had instances where the one on the box was different to the one on the device.
Edit: the devices I’ve worked with come with a DevEUI, AppEUI and AppKey
It looks like the join-request was correct and that ChirpStack is sending the downlink to your gateway. What I miss in the logs is a .../gateway.../event/ack message indicating that the gateway has acknowledged the downlink transmission. Either the downlink does not arrive at the gateway or the packet-forwarder is not sending back an acknowledgement.
There is also this case…
If you set your Gateway (service profile) to “PRIVATE” but the device is set “PUBLIC”, you will get the Join requests in ChirpStack and the gateway will actually send the Acknowledge the Join-Request if the Keys match but your end device will still ignore it.
The reason is that within the protocol layer the “private” flagged data is filltered out. This issue did cost me several weeks of time until it finally found the reason that it was Gateway “private” vs Node “public”.
All I saw were incoming Join Requests that were answered by the Gateway and still the device could not join. I thought I ran into some kind of timing issue as the gateway and node distance was not very far and when I used TTN it did directly work (because that gateway used for TTN was actually configured to be “public”).