Bug? Devices with different DevEUIs using same DevEUI for Join

runsolutions
Sun, 03 Aug 2025 18:37:07 +0000
The Things Stack v3

Problem Description

Since The Things Network (TTN) platform update around October 30th, we’ve observed an anomalous behavior in how our devices are being managed. Server logs indicate that two Eastron electricity meters, which have unique serial numbers and DevEUIs, are attempting to join the network in a way that suggests an incorrect association on the server side.

Specifically, the meter with serial number 230765299 appears to be attempting to join the network using the DevEUI of the other meter, which is 8680000130765278, instead of its own correct DevEUI (8680000130765299).

Device Details

Meter 1:

Serial Number: 230765278

Correct DevEUI: 8680000130765278

Meter 2:

Serial Number: 230765299

Correct DevEUI: 8680000130765299

Evidence from Server Logs

Below are the TTN server logs showing the sequence of events. The log from 20:25:24 shows a join-request with the incorrect DevEUI (8680000130765278), followed by a data message from the meter with the serial number 230765299.

`20:25:42
Forward uplink data message
DevAddr
260B873D
Payload
active_power 1285.47 crc3448 current 5.88 forward_active_power 254088. 7message_fragment_number 1 serial_number 230765299 total_number_bytes 120DC132F3010C44A0AF0F40BC283D4878222D0D78…
FPort
1
Data rate
SF8BW125
SNR
11.5
RSSI
-79

20:25:42
Successfully processed data message
DevAddr
260B873D

20:25:26
Forward join-accept message
DevAddr
260B873D
JoinEUI
8680000230765278
DevEUI
8680000130765278

20:25:24
Successfully processed join-request
DevAddr
260B3094
JoinEUI
8680000230765278
DevEUI
8680000130765278

20:25:24
Accept join-request
DevAddr
260B873D
JoinEUI
8680000230765278
DevEUI
8680000130765278

20:23:36
Schedule data downlink for transmission on Gateway Server
DevAddr
260B3094
Payload
active_power 5182.44 crc56909 current 23.62 forward_active_power 687.73 message_fragment_number 1 serial_number 230765278 total_number_bytes 120DC132DE010C45A1F38041BCFB11442BEE98DE4D…
FPort
1
Data rate
SF12BW125
SNR
5.2
RSSI
-95`

Additional Information

The issue started appearing on the 31st, one day after a platform update.

Both devices are correctly configured with their respective, unique DevEUIs on the TTN server side.

This erroneous behavior is not intermittent and has been replicated multiple times in the logs.

The cumulative consumption readings (forward_active_power) are completely different, confirming that these are two distinct physical devices.

This report is to help identify if there is a bug in the latest TTN update that may be causing this behavior and to seek a solution.

4 posts - 4 participants