Bug? Devices with different DevEUIs using same DevEUI for Join

TTN Network and Services The Things Stack v3
1

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.

2

If you want the developers to investigate it is better to log an issue on GitHub against the backend source. TTI staff rarely visits the forum and probably won’t notice your report.

3

A ping to @johan may be an option :slight_smile:

4

It’s very hard for people to review logs if they look like a scrabble board and run in reverse chronological order. I suspect you copied the console line entries. Formatting them with </> would make them marginally more readable. What would be useful would be to click on the console line for each JR and copy the JSON and paste, formatted with </>.

But glancing through it, I can see you’ve got the last entry at 20:25:42 showing the DevAddr which looks to be assigned to 8680000130765278 on it’s JA but the payload field is reporting the other serial number. As it’s the payload formatter decoding, sight of this would be appropriate.

It’s not clear what a downlink would have a payload that includes power info & the serial number - usually they have settings information in them.

The Frame Counter would be useful too.

Overall, Ockham’s Razor comes to mind - Sherlock Holmes would put it another way - is there any chance that devices & serial numbers have got mixed up?

As @kersing says, this is an informal support forum, even if we can definitively prove an issue with the last release (have you looked at the commits for it to see if the Join Server / Network Server have been changed?), it is not the way to submit bug reports. Either use your TTI support contract or lodge this on GitHub.