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”).
hello in my case, I am using a heltec device in a group of atmospheric sensors, a dragino LG308 as a gategay and I have this same problem, I already reviewed many possible solutions but the problem still persists that I never receive the join accept, I only receive the join request
Hi, I have the same problem. I was using V3 and everything was working fine. Now I created a new V4 machine to test it, but I’m struggling. I checked that the app key parameter is correct because if I change it, I get an error in the logs. In the LoRaWAN frames, I only see Join requests. In the logs, instead of the gateway, I see the Join requests and then some UnconfirmedDataUp messages. Can you help me? Additionally, I also found out that the HTTP integrations have changed, and the current application we are using doesn’t support the message format. Does it make sense for me to continue using V3? Thank you very much for your help.
We have had this issue a few times during testing on chirpstack v3. This typically involves adding, removing, activating, re-activating devices, changing OTAA keys etc. etc.
Normally, deleting the device and adding the device again solves the issue
On one occasion, we had to restart the chirpstack-application-server service as no devices was accepted at all. Th logs did not indicate that anything was wrong, and restarting the chirpstack-network-server did not help. We did not keep any logs or anything, so I have no “hard evidence”, but something went wrong in the application server for sure…
The strange thing is that the OTAA and activation sees to be working. The session keys and device address are correctly added/updated, but no join accept is sent.
Tip 1: If the OTAA key is wrong, the Device Data (tab on the device pages) will show error messages: “join-server returned error: response error, code: MICFailed, description: invalid mic”
Tip 2:: If the OTAA key is initially wrong, Device Data will report error… BUT if the OTAA key is changed (to correct key) in Chirpstack, the errors stops, activation is done (session keys are updated), but Chirpstack will not send a join accept until the device is reset!
To reproduce this error:
Set up and connect a (OTAA) device. Make sure everything is working correctly.
Change the OTAA key in Chirpstack to a wrong key
Verify that Device Data reports “… invalid mic”.
Correct the OTAA key in Chirpstack
Verify that the device stops reporting errors in Device Data, and that Lorawan Frames only reports Join Requests (and no Join Accepts)
Same situation here; it already worked with v3.0; eui & appkey double checked. join requests are not successful with message: Handle join-request error error=Object does not exist (id: 0018b20000023060)
Device is enabled with Otaa capability on
anybody here who can give me a hint how to diagnose further?
2023-11-11T22:53:29.993685Z INFO chirpstack::gateway::backend::mqtt: Message received from gateway region_config_id="eu868" topic="eu868/gateway/3530362036004900/event/up" qos=0 json=false
2023-11-11T22:53:29.994042Z TRACE chirpstack::uplink: Adding uplink event to deduplication set key="up:collect:08a084919e03120a1a0808c8d007100c2801:003246524144b218006030020000b21800e6d2a25b3339"
2023-11-11T22:53:29.995565Z TRACE chirpstack::uplink: Requesting deduplication lock lock_key="up:collect:08a084919e03120a1a0808c8d007100c2801:003246524144b218006030020000b21800e6d2a25b3339:lock"
2023-11-11T22:53:29.996477Z TRACE chirpstack::uplink: Waiting for more uplink events to receive key="up:collect:08a084919e03120a1a0808c8d007100c2801:003246524144b218006030020000b21800e6d2a25b3339"
2023-11-11T22:53:30.025665Z TRACE chirpstack::downlink::scheduler: Starting multicast-group queue scheduler loop run
2023-11-11T22:53:30.025693Z TRACE chirpstack::downlink::scheduler: Getting schedulable multicast-group queue items
2023-11-11T22:53:30.028908Z TRACE chirpstack::downlink::scheduler: Got this number of multicast-group queue items count=0
2023-11-11T22:53:30.028930Z TRACE chirpstack::downlink::scheduler: Multicast-group queue scheduler run completed successfully
2023-11-11T22:53:30.033997Z TRACE chirpstack::downlink::scheduler: Starting class_b_c_scheduler_loop run
2023-11-11T22:53:30.034016Z TRACE chirpstack::downlink::scheduler: Getting devices that have schedulable queue-items
2023-11-11T22:53:30.037514Z TRACE chirpstack::downlink::scheduler: Got this number of devices with schedulable queue-items device_count=0
2023-11-11T22:53:30.037530Z TRACE chirpstack::downlink::scheduler: class_b_c_scheduler_loop completed successfully
2023-11-11T22:53:30.197837Z TRACE chirpstack::uplink: Collecting received uplink events key="up:collect:08a084919e03120a1a0808c8d007100c2801:003246524144b218006030020000b21800e6d2a25b3339"
2023-11-11T22:53:30.199282Z INFO up{deduplication_id=9f7c744c-9bc3-40e6-9147-30590b12977b}: chirpstack::uplink: Uplink received m_type="JoinRequest"
2023-11-11T22:53:30.199315Z DEBUG up{deduplication_id=9f7c744c-9bc3-40e6-9147-30590b12977b}: chirpstack::uplink: Updating gateway meta-data for uplink frame-set
2023-11-11T22:53:30.202645Z DEBUG up{deduplication_id=9f7c744c-9bc3-40e6-9147-30590b12977b}: chirpstack::uplink: Logging uplink frame to Redis Stream
2023-11-11T22:53:30.204077Z TRACE up{deduplication_id=9f7c744c-9bc3-40e6-9147-30590b12977b}:join_request: chirpstack::uplink::join: Getting JoinRequestPayload
2023-11-11T22:53:30.204118Z TRACE up{deduplication_id=9f7c744c-9bc3-40e6-9147-30590b12977b}:join_request: chirpstack::uplink::join: Getting device
2023-11-11T22:53:30.206335Z ERROR up{deduplication_id=9f7c744c-9bc3-40e6-9147-30590b12977b}: chirpstack::uplink::join: Handle join-request error error=Object does not exist (id: 0018b20000023060)
2023-11-11T22:53:31.030277Z TRACE chirpstack::downlink::scheduler: Starting multicast-group queue scheduler loop run
2023-11-11T22:53:31.030297Z TRACE chirpstack::downlink::scheduler: Getting schedulable multicast-group queue items
