Unable to add the same device twice with different addresses (Local IP vs. DDNS)

[Moustachauve]

In the previous version of the WLED app, it was possible to add the same physical device to the list twice using different addresses: once via Local IP (for speed/reliability at home) and once via a Dynamic Domain/Port (for remote access).

In the new version, attempting to add the device a second time with a different address overwrites the first entry. The app now uniquely identifies devices by MAC address, preventing multiple connection paths for a single controller.

Steps to Reproduce

1. Open the WLED Android app.
2. Add a device (or allow auto-discovery) via its Local IP (e.g., 192.168.x.x).
3. Attempt to manually add the same device again using an External Address/DDNS (e.g., mywled.dyndns.org:80).
4. Observe the device list.

Expected Behavior

The app should allow the creation of two distinct entries for the same device (or allow a single device to have multiple fallback addresses), preserving the ability to connect via Local IP when at home and DDNS when away.

Actual Behavior

The app detects the device is the same (likely via MAC address check) and overwrites the existing Local IP entry with the new External Address (or vice versa), making it impossible to keep both connection methods saved simultaneously.

Context / Use Case

• Local IP: Used when at home for faster load times and higher reliability.
• DDNS: Used for external access when outside the local network.
• Impact: Users currently have to manually edit the host address every time they switch between being at home and being away.

[Moustachauve]

I was thinking I could add a new field to devices like "external address" or "fallback address" that would get used if the primary address (or local address) is unreacheable.

I could also save the device last known subnet or gateway IP and check if the phone is on the same network. If it is, use the local address, otherwise (or if the connection fails) fallback on the external one.

[willmmiles]

Offhand I would suggest the happy eyeballs algorithm (RFC8305): if a device has multiple addresses registered, try them all in sequence with a brief delay between them, and take the first one that responds. You could sort the list by RFC1918 addresses first (priority further given to addresses on the phone's local subnets) as well as most recently used.

Realistically, if a device is being reached over DDNS, I don't think people would notice an extra 200ms delay to try sending a packet to the last known address first.

[Moustachauve]

I'm not planning on necessarily addressing this super quickly (low priority for now). As a temporary solution, you could add the external address by default. It shouldn't be much slower?

As people have said on Discord, make sure your external access is secure. For other people seeing this, read https://kno.wled.ge/advanced/remote-access-ifttt/