Concepts – Why MyURemote Handles MAC Addresses (WOL & Device Identity)

1. The real problem MyURemote solves

MyURemote controls devices that often behave like embedded appliances, not clean network services. A universal remote experience requires deterministic behaviour even when devices are:

• in standby, where TCP/HTTP/WebSocket control may no longer be available
• slow to boot or slow to rejoin the network
• reachable only after specific startup phases
• equipped with multiple network interfaces such as Ethernet, Wi-Fi, Wi-Fi Direct or Always-On adapters
• temporarily absent from discovery while still being wakeable by Wake-on-LAN

For many TVs and receivers, the first command is not “volume up” or “input HDMI1”. The first command is: make the device become alive.

2. Why MAC addresses matter

IP addresses are routing addresses and can change through DHCP, network changes or interface changes. Wake-on-LAN, however, is based on the network interface’s MAC address.

configured device → known MAC candidate(s) → WOL broadcast

Modern TVs often expose more than one MAC-like network identity. Depending on brand, firmware and active interface, discovery may reveal Ethernet, Wi-Fi, P2P, Always-On or other addresses.

MyURemote therefore does not assume that one discovery result is permanently authoritative.

3. Why “just pick one MAC” is fragile

In real installations, discovery is opportunistic. A scan can return a different subset of addresses depending on the TV state, firmware, active interface and network timing.

• Samsung: may expose several network-related addresses.
• LG: may expose several MAC candidates through different discovery data.
• Firmware changes: can change which fields or interfaces are visible.
• Discovery timing: can temporarily return fewer candidates than a previous scan.
• Standby behaviour: can change which interface remains capable of receiving WOL.

For this reason MyURemote now keeps the complete known candidate set instead of learning and storing a single “best” MAC.

4. The current MyURemote WOL contract

iOS and Android follow the same platform-independent contract:

• Collect all candidates discovered for the configured device/IP.
• Merge, do not replace: a later incomplete discovery must not erase previously known candidates.
• Synchronize all candidates to the MyURemote database.
• Seed all database candidates back into local native storage when the remote starts.
• Send WOL to all valid candidates, with a short interval between packets.
• No best-MAC learning: MyURemote no longer waits after every candidate to decide which one “won”.

The reliability strategy is deliberately simple: preserve every known valid candidate and try them all.

5. Where MAC data lives

5.1 Local native storage

Each iOS or Android device keeps a local candidate set per IP address. This is the runtime source used by native WOL.

context_<ip> = {
    "AA:BB:CC:DD:EE:01": "wlanMacAddress",
    "AA:BB:CC:DD:EE:02": "db",
    "AA:BB:CC:DD:EE:03": "MACAddress"
}

The context label explains where a candidate came from. It no longer determines a “best-first” order.

5.2 Shared database storage

The backend stores the complete MAC candidate list for each configured user device:

param_name  = wol_macs
param_value = ["AA:BB:CC:DD:EE:01","AA:BB:CC:DD:EE:02",...]
param_type  = extender

The database is shared memory between MyURemote clients. Native WOL remains LAN-local and does not call the database directly.

6. Why the WebView is the synchronization bridge

MyURemote deliberately separates authenticated online configuration from local device execution. The WebView has the authenticated MyURemote session; the native layer has the local networking capabilities.

The WebView therefore performs both synchronization directions:

• Local → database: read all native MAC candidates and merge them into wol_macs.
• Database → local: read wol_macs and seed every candidate into native storage.

Native iOS/Android code never needs to authenticate directly against the MyURemote backend.

7. Practical dataflow

1. Startup / seeding: the frontend reads previously known wol_macs from the database and merges them into native storage.
2. Discovery: native discovery may find additional MAC candidates and merges them into the local candidate set.
3. Sync: the frontend reads the local candidate set and merges it back into the database.
4. Wake phase: native WOL sends a magic packet to every known valid candidate, typically about 150 ms apart.

DB wol_macs
      ↓
startup seed
      ↓
local candidate set
      ↕
native discovery
      ↓
frontend sync
      ↓
DB wol_macs

KEY_POWERON → MAC 1 → ~150 ms → MAC 2 → ~150 ms → MAC 3 → ...

8. Why this is more robust than “best MAC” learning

8.1 No false certainty

A TV can expose different interfaces at different times. Preserving all candidates avoids tying WOL reliability to one historical result.

8.2 Discovery may be incomplete without losing knowledge

New discovery data is merged. If a scan temporarily returns only one address, older known candidates remain available.

8.3 New devices can wake a TV immediately

A newly installed MyURemote client can receive the shared wol_macs list at startup and use it before local discovery has run.

8.4 iOS and Android use the same semantics

The native WOL transport can differ internally by platform or SDK, but the candidate-set contract remains identical.

9. Platform notes

• Samsung: the SmartView integration can use its native Wake-on-LAN helper.
• LG / generic WOL: MyURemote can generate and broadcast the standard WOL magic packet itself.
• Standby matters: TVs may take time to enter or leave the network state in which WOL works reliably.
• Power cycling can matter: some TVs can recover their standby network behaviour after a full power cycle.

A single failed wake attempt does not automatically mean that MAC synchronization is wrong; the TV’s standby network state is part of the real-world system.

10. Summary

• Wake-on-LAN requires MAC addresses, and modern devices may expose several candidates.
• MyURemote stores and preserves the complete known candidate set.
• Local native storage is the runtime candidate source.
• The database stores wol_macs as shared persistent memory between clients.
• The WebView synchronizes local ↔ database because it owns the authenticated session.
• A newly logged-in device can be seeded from the database before discovery runs.
• Power On sends WOL to all known valid candidates with a short interval between packets.
• The old best MAC / learning architecture is no longer part of the current contract.

Bottom line: MyURemote makes “Power On” resilient by keeping shared MAC knowledge instead of betting on one address.