Automatically Create Device on Join

ChirpStack Network Server
1

On a join request, before retrieving the device by given DevEUI, I would like to be able to insert a base device record for that DevEUI if it has not already been created when the join request first comes through. After that, the rest of the join process would flow as normal. The goal is something like an “auto-discover”/“auto-create” on first, internal join for a new device that does not already exist and has not previously been created in the database. I am planning to leverage a proprietary security/signature check on the given DevEUI to confirm that it is a device type I recognize and trust.

One option I’ve considered for implementation is to add a new task to the list of tasks executed as part of the JoinRequest flow in uplink.go:

var flow = NewFlow().JoinRequest(
setContextFromJoinRequestPHYPayload,
logJoinRequestFramesCollected,
// New task here to create base device record if not already exists
getDeviceAndDeviceProfile,
validateNonce, …

However, if there’s an available injection point across the flow into which I could inject an external routine to do this add, that would be ideal. Would like to be able to leave the existing code as is and intercept/apply this logic in the middle of the existing flow. Is there an available injection point like this that I could leverage for this functionality? Or is there a better way (or an already existing way that I have yet to come across in my review of the code) to do what I’m attempting? Thanks in advance!

2

You could create a proxy which sits in-between LoRa Server and the Join-Server API (provided by LoRa App Server). Then before forwarding the join-request to the join-server api, you extract the DevEUI, check if the device is present and if not create it. I think that would be the easiest option :slight_smile:

3

Thanks for the quick response! I think this approach sounds exactly like what I’m looking for. If I could beg your indulgence for a couple of follow-up questions/clarifications, that would be greatly appreciated…

  1. I was looking at LoRa Server as the spot to plug this in as I was not sure if LoRa Server had checks to prevent devices it did not previously know about from flowing through to the Join-Server. It sounds like that’s not the case which is good.
  2. I have requested and received the LoRaWAN Backend Interfaces specification and will review to better understand how that interface looks since I’ll need to provide a proxy for it. As I continue walking through the code, wondered if you’d be able to point me in the high-level direction of where the Join-Server API endpoints get configured on the LoRa Server and are plugged in to the flow (since I’ll need to update to point to my proxy)?
  3. Is HTTP REST supported for the Join-Server API endpoints?

Again - appreciate your assistance and quick response. Still a little new to the flows and working to get up-to-speed.

4

https://docs.loraserver.io/loraserver/install/config/

# Default join-server settings.
[join_server.default]
# hostname:port of the default join-server
#
# This API is provided by LoRa App Server.
server="http://localhost:8003"

Set that to your proxy url, then let your proxy forward to the above url. This url expects and returns JSON objects. The Go struct for the join-request is defined here:

5

This is awesome!! Thanks for sending over - exactly what I was looking for.

Best Regards!

6

I have successfully “plugged in” a new service to intercept the join request between the LoRa Server and the LoRa App Server. On power up/join, I see that my new service is picking up the request payload as expected. However, this route to my proxy join server does not occur unless there already exists a device record in the device table in the loraserver_ns database.

Is there a good external injection point at the LoRa Server level that would allow me to intercept the network traffic/forwarded packets and automatically populate a new row for the device in loraserver_ns. Basically, on power up of the device/join, I’d like to be able to automatically create a record in the device table in loraserver_ns and then route to the proxy for automatic creation in the device table in loraserver_as (and forward to downstream join server as normal).

I recognize that this will require some security checks as the flow executes end-to-end to be sure I trust the device before automatically creating records in the tables but, right now, just looking for a technical way to wire up the flow. Thanks!