Concepts – MyURemote Core Gateway Architecture

This page is a technical reference that explains how MyURemote works internally. It is written for integrators, power users and developers who want to understand the design decisions and the execution model behind MyURemote’s reliability across many brands and protocols.

Key idea: MyURemote is not an app that calls APIs. MyURemote is the API.

1. What MyURemote is in essence

MyURemote is a local socket gateway that turns a generic HTML/JS user interface into a universal control system for embedded devices (TVs, receivers, streamers, extenders, IR/serial gateways, etc.).

The app receives requests from a WebView (HTML/JS), translates them into byte-exact TCP communication (or other device-specific transports), and returns results to the UI through a strict, predictable response contract.

This architecture is deliberately kept simple so the UI does not need to deal with:

  • Firmware quirks and inconsistent protocol implementations
  • Timing issues and missing EOF markers
  • Devices that reply partially, slowly, or not at all
  • Different communication stacks (TCP, HTTP, WebSockets, IR, Serial)

2. The platform-independent core

MyURemote runs on iOS and Android. The code is platform-specific, but the responsibilities are identical. The core is a three-part model:

2.1 Gateway / Handler (contract guardian)

The Gateway/Handler is the central coordinator between the frontend and the network layer. It is responsible for enforcing the MyURemote contract.

  • Receiving HTTP/JSONP requests from the WebView
  • Parsing parameters and validating intent
  • Determining whether a response is expected (based on callback)
  • Managing socket reuse (keepOpen)
  • Executing retry logic when needed
  • Returning JSONP responses that the UI can interpret deterministically

In short: this layer is the contract guardian.

2.2 Socket Client (network reality layer)

The Socket Client implements low-level TCP communication and tolerates real-world embedded device behaviour. It understands network reality, not UI assumptions.

  • Connect to ip:port
  • Write byte-exact data
  • Read responses with real-world tolerance (no EOF, burst responses, partial data)
  • Detect connect/write/read failures
  • Support long-lived connections when keepOpen is enabled

2.3 Response Synchronisation (determinism bridge)

The UI request cycle is synchronous by nature (HTTP request → one response), while sockets are asynchronous and unpredictable. The Response Synchronisation layer bridges this gap.

  • Wait for bytes or a failure condition
  • Deliver exactly one result per request
  • Timeout enforcement
  • Byte-exact conversion to a string result for the UI contract

Without this synchronisation layer, deterministic behaviour is impossible.

3. The MyURemote request contract

Requests are sent from the WebView to the local MyURemote HTTP endpoint (/myuremote). Parameters define both the target and the intent.

Parameter Type Description
ipstringTarget device IP address
portintegerTCP port
commandstringCommand (URL-encoded, sent byte-exact)
callbackstringJSONP callback name (defines whether a response is expected)
timeoutintegerTimeout in milliseconds
maxRespSizeintegerMaximum number of response bytes
keepOpenbooleanReuse socket (ip:port) for future commands

Fundamental rule: response intent is explicit

A response is expected if and only if a callback parameter is present. MyURemote never guesses.

Intent callback Behaviour
Fire-and-forget No Send only, no read phase, returns "OK" immediately
Expect feedback Yes Full cycle: open → write → read → return result via JSONP

This rule exists because MyURemote cannot know whether a device will answer:

  • Some devices never answer (IR blasters, many simple TCP devices)
  • Some devices answer only depending on state
  • Some devices answer partially or asynchronously
  • Many embedded devices never send EOF markers

Therefore: the WebView decides: “I want feedback” or “I only want to send”. The decision is expressed exclusively via callback.

4. The MyURemote response contract (UI feedback)

The frontend interprets only a small set of fixed result strings. This is a deliberate design choice to keep UI logic simple, stable, and predictable across all devices.

Result Meaning
OKFire-and-forget command (no response expected)
cannot connect to hostConnect/open/write failed
no responseWrite OK but device returned no response within timeout
Could not write dataLegacy / device-specific write error
errorUnexpected internal error
(raw response)Byte-exact response returned by the device

No other values are allowed. This strictness keeps macros, UI feedback indicators and cross-device behaviour consistent.

5. Timeout & read model (critical)

MyURemote uses a practical two-phase read model designed for embedded devices that do not behave like clean TCP servers.

Phase 1 – First byte timeout

  • Timeout starts after a successful write.
  • If no byte arrives within the timeout: return "no response".

Phase 2 – Idle finalize window

  • Once the response has started, MyURemote waits until the device becomes idle.
  • For non-HTTP protocols: a short idle window ends the response.
  • For HTTP: a longer idle window is used to tolerate larger payloads and chunk-like behaviour.

This model is essential for devices that:

  • Never send EOF markers
  • Respond slowly or in bursts
  • Send partial answers that only become complete after a short idle period
write →
wait for first byte →
  [timeout] → "no response"
  [first byte] →
    collect bytes →
    idle window →
    response complete

6. Socket caching & retry strategy

Sockets can be reused per ip:port to improve performance and reliability. Reuse happens only when keepOpen=true.

If a “bad” response occurs, the socket is considered unreliable and will be dropped from cache. One automatic retry is performed with a fresh connection.

Bad socket responses include:

  • cannot connect to host
  • no response
  • error
  • Could not write data

Only sockets that behave correctly are kept and reused. This keeps the UI simple while maintaining stability.

7. JSONP and WebView integration

The WebView integrates via JSONP, which provides predictable callbacks even in restricted environments. Responses are returned as: 

callback({"result":"..."})

The JSONP builder ensures safe escaping and consistent output across platforms.

8. Component map (iOS vs Android)

Layer iOS Android Main responsibility
Gateway / Handler SocketHandler.m MyURemoteHandler.java Contract guardian: parse parameters, decide callback behaviour, manage keepOpen, cache & retry, return JSONP.
Socket client Socket.m SimpleSocketClient.java Low-level TCP: connect, write, read, two-phase model, error detection, byte-exact responses.
Response synchronisation integrated in Socket.m (semaphores & delegates) ResponseHandler.java Bridge async sockets to sync HTTP lifecycle; one deterministic result per request.
Socket cache (logical) static NSMutableDictionary<NSString*, Socket*> *sockets static Map<String, SocketClient> clients Reuse sockets per ip:port, drop on bad responses, retry once.
JSONP builder BuildJsonp() in SocketHandler.m buildJsonp() in MyURemoteHandler.java Format output as callback({"result":"..."}) safely.
Bad response detection IsBadSocketResponse() isBadSocketResponse() Defines which results invalidate a cached socket.

9. Configuration, data storage and refresh behaviour

MyURemote is a local execution gateway, but configuration data is stored online. This is a deliberate separation of responsibilities:

  • Local runtime: commands are executed locally (gateway → sockets → devices on your LAN).
  • Online configuration: your setup (devices, zones, macros, extenders, parameters) is stored in the database.

This has an important consequence: when the frontend UI reloads or refreshes, the full configuration is pulled from the database and the interface is rebuilt deterministically from that configuration.

In other words: MyURemote does not require a cloud to execute commands locally, but it does rely on the online platform to store and load configuration. Execution remains LAN-local; configuration remains centrally managed.

10. Frontend execution model (HTML/JS UI)

The user interface is implemented in HTML/JS and runs inside a WebView. The UI stays device-agnostic: it does not embed vendor SDKs or protocol logic. Instead it communicates with MyURemote using the request/response contract described above.

  • HTTP/JSONP: generic command dispatch and deterministic results.
  • WebSockets: supported where needed by specific device integrations.
  • UI status indicators: the interface can show whether commands were delivered successfully or failed.

Because all low-level complexity is handled by the gateway, the WebView UI can stay consistent across brands and technologies while still supporting advanced setups (macros, multi-zone systems, mixed protocols).

11. Pairing, identification and discovery

MyURemote includes functionality to simplify setup and improve reliability:

  • Pairing flows for specific integrations that require authentication or token-based access.
  • MAC address usage where needed to uniquely identify devices or support Wake-on-LAN scenarios.
  • DLNA discovery to auto-detect compatible devices on the local network and prefill parameters.
  • Auto-preparation: when a device type is known and used successfully, MyURemote can preconfigure defaults (ports, extenders, etc.).

This is part of the philosophy: configuration should be as simple as possible, while runtime behaviour must remain deterministic.

12. Developer tooling (HTMLRemote)

For developers and integrators who want to build custom user interfaces, MyURemote provides tooling and a dedicated project path.

  • HTMLRemote is a developer-focused application to build and test custom HTML/JS interfaces.
  • A Windows version exists for rapid development and testing.
  • Note: the Windows developer tool supports TCP/IP but does not support WebSockets.

→ See also: How-To documentation

13. Summary

  • MyURemote is a local gateway that translates WebView requests into byte-exact device communication.
  • The frontend declares intent explicitly using callback; the backend never guesses.
  • A strict response contract keeps UI behaviour stable across devices and protocols.
  • Timeout and read logic is designed for embedded devices that do not send EOF and reply unpredictably.
  • Execution happens locally on the LAN, while configuration is stored and loaded online.

This architecture is the reason MyURemote can scale across many brands and technologies without forcing protocol complexity into the user interface.