Downlinks being routed to the wrong DevAddr

hsors
Sun, 22 Jun 2025 14:31:42 +0000
The Things Stack v3

I’m experiencing a persistent issue with downlinks being routed to the wrong DevAddr, despite using the correct device_id.

Device info:

Device ID: hso-energysaver

DevEUI: 70B3D57ED0053EED

Application ID: ardbeescale-af01

Observed behavior:

I initiate a downlink using either the **TTN Console (“Live data” > “Send a downlink”) or via a Blynk application, targeting hso-energysaver.
The downlink immediately appears in the Live Data feed, but is routed to an incorrect DevAddr: 260B21C1, which does not correspond to this device (and does not exist in my account).
Meanwhile, the correct DevAddr assigned to hso-energysaver after OTAA join is currently 260B6A22.

OTAA Join confirmed:
15:58:07 Accept join-request - DevAddr: 260B6A22
15:58:08 Forward join-accept - DevAddr: 260B6A22
15:58:12 Forward uplink - DevAddr: 260B6A22

Downlink wrongly routed:
15:59:11 Receive downlink for hso-energysaver DevAddr: 260B21C1 (incorrect!) FPort: 100 Payload: C1

Additional details:

I do not own or have ever registered a device with DevAddr 260B21C1.
This incorrect routing persists even after a fresh OTAA join.
Other devices in my account receive downlinks correctly (no DevAddr mismatch).
It seems that the backend still associates hso-energysaver with a ghost DevAddr (260B21C1) despite having a valid new one.

Unsuccessful temporary fix attempted:

I tried forcing a new OTAA join (successful, new DevAddr assigned).
I cleared browser cache, reloaded the console, used incognito — same result.
Issue occurs regardless of whether the downlink is triggered via Blynk or TTN Console.

This looks like an internal mapping issue between device_id and DevAddr on the backend or routing layer.

Is there any way to resolve this? I’m happy to provide additional logs or re-test as needed.

Thank you,

1 post - 1 participant