# Downlinks being routed to the wrong DevAddr

**URL:** <https://www.thethingsnetwork.org/forum/t/downlinks-being-routed-to-the-wrong-devaddr/71688>\
**Category:** The Things Stack v3\
**Created:** [June 22, 2025, 2:31pm UTC](https://www.thethingsnetwork.org/forum/t/downlinks-being-routed-to-the-wrong-devaddr/71688 "2025-06-22T14:31:42Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![hsors](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/hsors/32/35697_2.png) [@hsors](https://www.thethingsnetwork.org/forum/u/hsors)\
**Post date:** [June 22, 2025, 2:31pm UTC](https://www.thethingsnetwork.org/forum/t/downlinks-being-routed-to-the-wrong-devaddr/71688/1 "2025-06-22T14:31:42Z")

</div>

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,