Migrate from TTN to Loraserver

I would like to migrate from TTN to a loraserver instance (docker-desktop on laptop)
I can redirect my gateway (Sentrius RG168) to the docker instance of loraserver, the status is connected.

I copied the keys from TTN to the Loraserver device configuration

TTN delivers an “APPLICATION EUI”, the firmware of a node also requires this.
I see this mentioned with respect to the Loraserver application configuration in the forum but I can’t see where this is to be entered/retrieved in the UI to be used with the docker approach.

There are some strange aspects when I connect the node:

  • The device claims to be joined
  • LoraServer claims the device did not join yet ??

I can see life data come in on the gateway life view but nothing at the device life view.

I can see a join request on the device but I can’t see where it goes wrong to get in this strange situation.

I’m using the B-L072Z-LRWAN module from ST/Murata as I intend to use these modules in the future on sensors.

The device claims to be joined

Assuming you restarted the device or that this is a new session, any chance your device re-joined TTN via someone else’s gateway? Things can get confusing quite quickly if there are records matching an OTAA node in two different servers to which marginally in-range gateways report.

You are right: TTN picks up the signal on another gateway
My local private gateway shows my messages and other nodes which I don’t know.
Data is encrypted, I assume using keys exchanged on joining.
Or can I decrypt the data with the keys I put in the device?

Since you say “join” it appears you have OTAA, and a session that has been completed between a TTN OTAA server and the node.

You basically have two choices:

  1. You can delete the device in TTN so it stops getting acks, and eventually starts trying to issue new joins which your custom LoRaServer setup can handle.

  2. You can extract the temporary keys and device address of the OTAA session from the TTN console and create an ABP device in LoRaServer and put those keys in temporarily under the activation tab, so that you get data at least until the node decides those sessions are broken and tries to register again. If you want it to ack you may need to guess the downlink frame counter or move that over, too.

In actuality, you can do both of the above at the same time - you can create a new OTAA device in LoRaServer, and you can temporarily port the current OTAA session details over an put them in as an ABP device. The only real catch is that you’ll have to give the two “identities” of the node different EUI’s.

Just to close the issue: as I’m mastering the firmware I could put is any key/ devEUI I wanted.
Which is exactly what I did: I changed the devEUI to a domain I hope no-one is using and kept the original TTN generated key. This combination should be sufficient to avoid TTN to pick up my sensor and process it outside my environment.

Hi @Gwen_Stouthuysen and @cstratton, is it working then?
I am also facing an issue when I move a device from TTN to chirpstack!
FYI I have deleted the device (DevEUI) from TTN.