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 (no TCP/HTTP/WebSocket possible)
• slow to boot (minutes can be normal)
• reachable only after specific startup phases
• inconsistent in their network identity (DHCP changes, multiple NICs, Wi-Fi vs Ethernet)

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 (and IP is not enough)

IP addresses are routing identities. They are not stable device identities. In home networks, devices can change IP (DHCP lease changes, mesh routing, sleep/wake cycles). A MAC address is the closest thing to a stable hardware identifier in a LAN environment.

Wake-on-LAN requires a MAC address by design: the packet targets the NIC at layer 2. Therefore, any reliable WOL implementation needs a stable mapping:

device identity → MAC address → WOL broadcast

In practice this becomes tricky because many modern TVs expose multiple MACs: Wi-Fi, Ethernet, Wi-Fi Direct / P2P, Bluetooth, Always-On adapter, etc. Only one of them actually wakes the device.

3. Why “just pick the MAC” doesn’t work

In the field, MyURemote has to deal with real device behaviour, for example:

• Samsung: can expose multiple candidates (Wi-Fi MAC, P2P MAC, etc.)
• LG: often exposes one “good” MAC, but not always consistently labeled
• Different firmware versions change which MAC is returned where
• Discovery may fail temporarily (network conditions, timing, power state)

This is why MyURemote treats MAC handling as a learning + persistence mechanism, not as a one-time “scan and store”.

4. The MyURemote reliability contract for WOL

MyURemote uses a strict platform-independent contract:

• Collect candidates (discovery produces one or more MACs + context labels)
• Never throw candidates away (we may sort, but not permanently filter)
• Prefer “best” (the last proven working MAC gets first attempt)
• Learn by success (when a MAC works, it becomes the new best)
• Persist “best” locally and centrally

The outcome is not “we found a MAC”. The outcome is: we know which MAC actually wakes this device.

5. Where MAC data lives (local vs shared)

MAC handling is intentionally split into two storage layers:

5.1 Local runtime storage (the source of truth)

On each phone/tablet, MyURemote keeps local MAC storage for immediate runtime decisions:

• Candidate MACs per IP (with context labels)
• Best MAC per IP (the last proven working MAC)

Local storage is what native WOL logic reads from. This ensures WOL does not depend on an online call.

5.2 Shared database storage (cross-device memory)

The backend database stores a single value per configured device: the best MAC. This is “shared memory” so other devices can reuse proven knowledge.

Important: the database is not used at runtime by native WOL. It is used to seed local storage.

6. Why the WebView bridges seeding (and native does not)

MyURemote is designed so that device execution remains LAN-local, while configuration and persistence live online. The WebView has the user session (cookies / login) and therefore can read/write the configuration database.

Native runtime layers intentionally remain “offline capable” and focus on:

• discovery and low-level networking
• local storage
• WOL execution

Therefore the WebView is the correct place to: read best-MAC from the database and seed it into local runtime storage.

7. Practical dataflow (high level)

The lifecycle looks like this:

1. Discovery phase (optional, opportunistic): candidates are found and stored locally.
2. Wake phase (critical): native WOL tries the best MAC first, then falls back to other candidates.
3. Learning phase: when a candidate succeeds, it becomes the new best MAC.
4. Sync phase: the frontend writes the best MAC to the database.
5. Seeding phase (new device / reinstall): the frontend reads DB best and seeds it back into local storage.

Discovery → Local candidates
WOL attempt → Best-first, fallback
Success → Local best updated
Frontend sync → DB best updated
New device → DB best seeded → Local best restored

8. Key design decisions (and why they exist)

8.1 Best-first is mandatory

Most devices take time to wake. Trying random candidates wastes time. “Best-first” makes wake time consistent and predictable.

8.2 Never permanently discard candidates

Firmware updates, Wi-Fi vs Ethernet changes, and network topology can change which MAC works. Keeping candidates avoids dead ends.

8.3 Database is not runtime – it is recovery

WOL must work without relying on an online request, but a database is essential for: reinstall recovery and cross-device learning.

8.4 Platform-independent contract reduces bugs

iOS and Android expose the same semantics to the WebView. This prevents platform-specific divergence, which is a major source of reliability issues.

9. What this enables in real-world use

• Stable “Power On” macros even when the device is in deep standby
• Cross-device learning: once any device learns the best MAC, others benefit
• Resilience against discovery failures and temporary network issues
• Faster wake cycles because best-first avoids repeated wrong attempts
• Field supportability: candidates and best can be inspected via the local endpoint

10. Summary

• Wake-on-LAN requires MAC addresses and many devices expose multiple candidates.
• MyURemote treats MAC handling as a learning system: candidates + best.
• Local runtime storage is the source of truth for WOL execution.
• The database is shared memory: it enables recovery and cross-device reuse.
• The WebView bridges DB ↔ local seeding because it holds the authenticated session.
• Best-first + fallback + learning is what makes power control predictable across brands.

Bottom line: MAC handling exists so “Power On” is deterministic, not hopeful.