Smart TV Remote Control APIs: How to Discover and Control TVs Over Wi-Fi

A smart TV is not just a display. It is also a network device with a control surface, and that makes it very different from a traditional infrared remote. In practice, a mobile app or a home-automation gateway can discover a TV on the local network and send commands over HTTP, WebSockets, or a vendor protocol. This is how modern remote-control apps work without pointing a beam of infrared at the screen.

The key difference is between discovery and control. Discovery answers: “Which TVs are on the network?” Control answers: “How do I send a command to this one?”

Discovery: SSDP/UPnP, mDNS, and network scanning

Most smart TVs announce themselves on the local network. The usual discovery mechanisms are:

• SSDP / UPnP on UDP 1900
• mDNS / Bonjour for host name resolution
• network scanning for common control ports

SSDP / UPnP

SSDP is the classic discovery protocol for local devices. A client sends a multicast request to UDP 1900 and the TV responds with a URL that describes itself and its services.

Example idea:

M-SEARCH * HTTP/1.1
HOST: 239.255.255.250:1900
MAN: "ssdp:discover"
MX: 3
ST: ssdp:all

A TV may respond with something like a LOCATION URL pointing to an XML description file. This is useful when building a local device browser or a home-automation integration.

mDNS

mDNS is common on Apple and some Android/Linux setups. A device advertises a hostname such as LivingRoomTV.local, which your app can resolve without a central DNS server.

Why browser-based auto-discovery is limited

A browser running in a normal web page does not have unrestricted access to local network device discovery. There are security and platform constraints, and many TV services are not exposed with browser-friendly CORS rules. That is why a local backend is often needed.

In other words, a browser can talk to a backend on the same machine or on the LAN, but it is not the best place to do raw SSDP or vendor-specific discovery.

Smart TV APIs: there is no universal standard

There is no single control API for all TVs. Every brand implements its own layer of discovery plus control. The common pattern is:

• device discovery over SSDP, mDNS, or manual IP entry
• an HTTP or WebSocket control endpoint
• optional pairing/authentication

Authentication matters. Some TVs allow basic control without pairing. Others require a one-time pairing code or signed token. This is one of the reasons a universal remote is never just a copy-paste script; it needs a protocol adapter per brand.

Practical example: Philips JointSpace API

I tested a Philips TV on the local network with the following setup:

• Model: Philips 50PUS7505/12
• OS: Linux-based Philips platform
• API: JointSpace 6.1
• HTTP port: 1925
• IP: 192.168.31.195
• Pairing type: none

The key fact here is that the API was reachable and the GET /6/system endpoint returned HTTP 200 with JointSpace API version 6.1.0. That is strong evidence that the device is exposing a control interface over Wi-Fi without needing an app pairing flow.

Check the TV information

Windows CMD version:

curl.exe -i http://192.168.31.195:1925/6/system

Example expected response (simplified):

{
  "type": "settop",
  "model": "50PUS7505/12",
  "api_version": "6.1.0",
  "pairing_type": "none"
}

This is a good proof that the device is discoverable and control-capable on the LAN.

Increase volume

curl.exe -X POST http://192.168.31.195:1925/6/input/key -H "Content-Type: application/json" -d "{\"key\":\"VolumeUp\"}"

Decrease volume

curl.exe -X POST http://192.168.31.195:1925/6/input/key -H "Content-Type: application/json" -d "{\"key\":\"VolumeDown\"}"

Navigate home

curl.exe -X POST http://192.168.31.195:1925/6/input/key -H "Content-Type: application/json" -d "{\"key\":\"Home\"}"

The JSON body is a simple object such as {"key":"VolumeUp"}. The server interprets that value as a virtual remote button. This is straightforward for a backend service, but it is still vendor-specific. A Philips TV expects Philips keys; a Samsung TV expects different commands or a different control system.

Important: the /6/system endpoint was confirmed working. The remote-control commands above are examples based on the JointSpace API contract, but they are not all confirmed working yet on this specific device and should be treated as “needs validation” until tested on the target hardware.

Building a web-based universal remote

A common design is a simple web UI that sends commands to a backend service. The backend handles the brand-specific logic and talks to the TV over LAN.

async function sendTvCommand(tvIp, brand, key) {
  const url = `http://${tvIp}:1925/6/input/key`;

  const res = await fetch(url, {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({ key })
  });

  return res.status;
}

sendTvCommand('192.168.31.195', 'philips', 'VolumeUp');

This is simple, but a browser cannot freely discover all local devices and cannot always call arbitrary vendor APIs because of CORS and browser security boundaries. A local backend or native app is usually the right place to do this reliably.

A practical architecture looks like this:

• Web UI in the browser
• Backend service in Node.js, Python, or Go
• TV adapters for Philips, Samsung, LG, Roku, Android TV
• Each adapter implements the right discovery and command format

Open-source references

Two useful references are:

• Home Assistant Core: a mature smart-home integration layer with support for many brands and discovery patterns
• amolood/Universal-Remote: a practical open-source project for building a multi-brand controller

The important lesson is that supporting multiple brands means implementing multiple protocol adapters, not one magic API.

Conclusion

Smart TV control over Wi-Fi is usually a combination of local discovery and brand-specific APIs. SSDP, mDNS, and network scanning help find devices; HTTP or WebSocket endpoints let you send real commands. For Philips, the JointSpace API is a clean example: a simple local HTTP service with a JSON payload and a REST-style command model.

That pattern is useful for custom web remotes, smart-home automation, and AI assistants that need to control the living-room screen as part of a broader environment. The real work is not in the UI; it is in choosing the right adapter for the right TV and validating the commands on the target hardware.

Suggested SEO title

Smart TV Remote Control APIs: Discover and Control TVs Over Wi-Fi

Suggested meta description

A practical guide to smart TV discovery and control over Wi-Fi: SSDP, mDNS, Philips JointSpace, Samsung, LG, Roku, and building a simple universal remote backend.