OTAA Activation on second chirpstack server fails

Hi,

I am using the docker image from GitHub - chirpstack/chirpstack-docker: Setup ChirpStack using Docker Compose on my server1 and my first chirpstack server runs fine and I was able to OTAA activate the Tektelic Vivid Smart Room sensor succesfully. So far so good.

Now I installed a second chirpstack docker image on server2. I was able to successfully register the gateway, but the OTAA activation of my Tektelic Vivid Smart Room sensor is not working even though I used the same data like on server1.

Do I have to setup something to allow the OTAA activation on server2?

chirpstack on server2:

chirpstack on server1:

I found this code snippet in the region_eu865.toml:

# Rejoin-request configuration (LoRaWAN 1.1)
    [regions.network.rejoin_request]

      # Request devices to periodically send rejoin-requests.
      enabled=false

Do I have to set enabled=true to make it work? Note that the sensor is using Lorawan 1.02.

Thanks in advance.

Are the gateways for the these servers in the same/overlapping areas? Or have you shut down the first server? A device will only join one (independent) server at a time, so it sounds like you have a race between the two.

I am using the same Dragino gateway on both servers. I am not sure if I have tried shutting one server1 down.

On the Dragino gateway i have the setup primary server = server2 and secondary server=server1

Will it work when i shutdown server1 until it OTAA activates with server2? An then i turn back on server1 and it is receiving data on both servers?

I haven’t used Dragino gateways recently, but I now see what you’re attempting. For that to work, you will need either a.) a device with an aggressive rejoin algorithm or b.) ChirpStack instances that are sufficiently geographically separate enough to be useful, but at the same time sharing activation data.

Personally, I would skip the secondary server setting and focus on an HA configuration + configure your gateway, Gateway Bridge, and/or MQTT Forwarder to support queuing payloads when disconnected.

Thanks for your suggestions. I tried shutting server1 down and keeping only server2 for the past 8 hours. But sadly the OTAA activation was not successful. Do you think I have to press a reset button on my LoRaWAN sensor to reset the activation?

My original idea was to use server1 for debugging and some tests and keep the server2 as productive server for my home automation.

That seems likely. The LoRaWAN join process is a cryptographic handshake, so it is intentional that a server not privy to the private keys will discard data it can’t decrypt/recognize.

Thank you for pointing me into the right direction. You were right, that the hidden reset button on my sensor made OTAA activation work instantly.