Milesight gateway + factory-preactivated OTAA device always shown as “Never seen” (no JoinRequest, MQTT and UDP tested)

Viewed 17

I would like to clarify a LoRaWAN activation behavior when using ChirpStack v4 with a Milesight gateway and a vendor-preactivated device.

Environment

Network Server: ChirpStack v4

Gateway: Milesight

Gateway integration tested:

ChirpStack v4 mode (MQTT)

Semtech UDP packet forwarder (via ChirpStack Gateway Bridge)

Region: EU868

MQTT broker and gateway connectivity are fully operational

Observed behavior

In all configurations (MQTT and UDP), both the gateway and the device are permanently shown as “Never seen” in the ChirpStack UI.

This happens even though:

The gateway is connected and visible

The device is configured correctly

RF traffic is present on the air

Transport method (MQTT vs UDP) makes no difference

Device behavior

The device is labeled by the vendor as OTAA

DevAddr, AppSKey and NwkSKey are provided by the manufacturer

The device does not send JoinRequest

There is no physical or software method to trigger a rejoin
(no button, no battery reset, no downlink-triggered rejoin)

The device was previously working with Milesight Embedded Network Server, which accepts an existing session (DevAddr + AppSKey + NwkSKey) without requiring a JoinRequest.

Root cause (as understood)

ChirpStack marks a gateway or device as “seen” only after a valid LoRaWAN uplink is successfully processed, which requires:

A valid session context

Successful MIC verification

Correct frame counter handling

Since the device cannot perform an OTAA join and the existing session was created outside ChirpStack:

ChirpStack cannot establish a session

All uplinks are dropped

Both gateway and device remain “Never seen”

This behavior is consistent and expected given ChirpStack’s strict LoRaWAN compliance.

Questions

Is the only supported way to integrate such a device with ChirpStack to use ABP mode?

Is there any supported mechanism in ChirpStack to import or continue an existing OTAA session created outside the Network Server?
(I assume the answer is no, due to LoRaWAN specification constraints.)

Is there any recommended approach for migrating vendor-preactivated devices that cannot rejoin?

I want to confirm that this behavior is expected and that ChirpStack intentionally does not support “pre-activated OTAA” devices without JoinRequest, even if the vendor labels them as OTAA.

Thanks in advance for confirmation and guidance.

2 Answers

The device is labeled by the vendor as OTAA
Since the device cannot perform an OTAA join

Then it is an ABP device, not an OTAA device? There is not such thing as a pre-activated OTAA, it is either ABP where the session-keys are already set, or OTAA when the device sends a join-request and handles the activation "over the air".

So if the device can not perform OTAA join-requests, you should configure it as an ABP device not OTAA.

We want to clarify the situation based on actual packet-level evidence.

The device does transmit uplinks, which are received by the Milesight gateway and forwarded to ChirpStack via MQTT (we can see valid event/up messages with PHY payload).

However:

the device never sends JoinRequest

the device never performs rejoin

OTAA activation is therefore impossible

We also attempted ABP activation using the exact DevAddr, AppSKey and NwkSKey provided by the factory, with:

correct EU868 region

LoRaWAN 1.0.x profiles

frame-counter validation disabled

The uplinks are still rejected and the device remains “never seen” in ChirpStack.

This proves that:

the device is not performing standard OTAA

the device is not behaving as a standard ABP device either

In practice, the device appears to operate in a vendor-locked, pre-activated session state, which only works when using Milesight Network Server (or an NS with identical internal handling).

Please confirm:

Are these devices permanently bound to Milesight NS after the initial activation?

Is there any supported way to reset or rebind the LoRaWAN session without factory reset or breaking the seal?

Is standard-compliant OTAA or ABP operation with a third-party NS (e.g. ChirpStack) officially supported at all?

How we could also make visible device on the chirpstack side on the UI. As for this moment we got stuck with no data info and "Never seen"

P.S What you can suggest to do in that case?