How I built a single iOS app that controls all four Hisense smart-TV platforms

hisuperdev — Thu, 28 May 2026 13:27:48 +0000

Hisense ships TVs with four different operating systems — VIDAA,
Roku TV, Google TV, and Fire TV. The official "Remote for Hisense
TV" you find in their app store only works with VIDAA. When I lost
my own remote, I had a Google TV-flavored Hisense, so I built a
single-app solution that pairs with whichever platform the user has.

Here's how each of the four local-network protocols works, and how
the app picks the right one without asking the user.

TL;DR

Platform	Local protocol	Pairing
VIDAA	MQTT over TLS	Direct local connection
Roku TV	ECP over HTTP	Open by default on port 8060
Google TV	gRPC, TLS)	4-digit PIN
Fire TV	ADB-over-Wi-Fi	One-time TV-side prompt

All four are LAN-only — no cloud involvement once paired.

1. VIDAA — MQTT over TLS

VIDAA TVs accept TLS connections on port 36669 and speak MQTT
underneath. The control message format publishes button presses as
small JSON payloads — {"key": "KEY_VOLUMEUP"} etc. — to predictable
topics scoped by the TV's MAC address. Other developers in the Home
Assistant community have written about this in detail; my Swift
implementation is on top of that prior work.

2. Roku TV — ECP is HTTP

Almost too easy. Roku publishes the External Control Protocol
publicly. Every Roku and Hisense Roku TV listens on port 8060:

curl -X POST http://192.168.1.100:8060/keypress/Home curl -X POST http://192.168.1.100:8060/keypress/VolumeUp curl http://192.168.1.100:8060/query/active-app curl http://192.168.1.100:8060/query/device-info curl -X POST http://192.168.1.100:8060/launch/12

No pairing. No PIN. If your phone and the TV are on the same LAN,
you can drive it from a curl one-liner. This is why I shipped an in-browser Roku remote — for Hisense Roku TV owners, you don't actually need an app at all. The page implements ECP from JavaScript and runs in any modern browser. Cannibalises my own install funnel for that segment, but it's the right call for the user.

3. Google TV — gRPC dance

Google TV uses gRPC over TLS with cert pinning. Pairing exchanges a
4-digit PIN through paired proto messages — the Android TV Remote v2
protocol. The .proto definitions are discussed in various developer
communities; from there it's standard gRPC client work.

4. Fire TV — ADB-style local connection

Fire TV runs Android and supports network-mode ADB on port 5555.
After the user enables developer-friendly settings on the TV, the
app authorizes once via a permission prompt on the TV screen.

Platform detection via mDNS

The app browses for service types:

_androidtvremote._tcp → Google TV
_roku-rsp._tcp → Roku TV
_amzn-wplay._tcp → Fire TV
Port-scan port 36669 fallback → VIDAA

The first responder wins. The user never picks "what kind of Hisense
TV is this" unless detection fails.

The implementation ships as Remote for Hisense TV on the App Store, free with a Pro tier ($9.99/year) that adds the Apple Watch app, Lock Screen widget, and removes ads. The marketing site with deeper troubleshooting articles is at hiremote.app.

Happy to answer iOS protocol questions in the comments.

I built an in-browser Roku TV remote with ~80 lines of TypeScript. Here's how Roku's ECP API actually works

hisuperdev — Sun, 24 May 2026 21:50:15 +0000

Roku ships an HTTP API on every device they sell. It has no authentication, no API key, no documentation page on a marketing site — but it powers every third-party Roku remote app on the App Store and Play Store. It's called ECP (External Control Protocol) and once you've seen it, you'll wonder why the rest of the smart-TV world isn't this simple.

I needed an in-browser remote for HiRemote's Hisense Roku TV landing page — the idea being a visitor who lands on the page can press buttons in the page itself without first installing the iOS app. Three quirks made it harder than the marketing-page version suggests; here's the actual implementation.

1. Discovery — SSDP is overrated, the user types the IP

Every Roku tutorial starts with "use SSDP multicast on 239.255.255.250:1900". This is true but useless from a browser: browsers can't send UDP. You can't run SSDP from JavaScript.

For a browser-based remote, the pragmatic solution is: ask the user for their TV's IP. On the iPhone app side we use Bonjour. On the web page side we just show a one-time input box, then localStorage it. Roku TVs always run ECP on port 8060, so once you have the IP, the base URL is fixed:

const baseUrl = `http://${tvIp}:8060`

The only gotcha here is that the user's browser is HTTPS but the TV is HTTP. Modern browsers block mixed-content requests, so you have to either accept this and let the request fail gracefully, or proxy through your own backend. We chose the first option — the input box explains the limitation and tells the user to also try the iOS app which doesn't have this restriction.

2. Buttons — every command is a POST to a path

The control surface is one of the cleanest API designs I've seen in a consumer device:

POST http://<tv-ip>:8060/keypress/<KeyName>

<KeyName> is one of about 30 documented strings: Home, Up, Down, Left, Right, Select, Back, Play, Pause, Rev, Fwd, VolumeUp, VolumeDown, VolumeMute, PowerOn, PowerOff, plus a few platform-specific ones for Roku TV (channel up/down, input switching).

No body, no headers, no auth. Just the POST:

async function sendKey(key: RokuKey) {
  return fetch(`${baseUrl}/keypress/${key}`, {
    method: "POST",
  })
}

For typing into search boxes (Netflix login, YouTube search), there's /keypress/Lit_<urlEncodedChar> — one POST per character. Cleaner than building a virtual keyboard, ugly that it isn't batched, but it works.

3. Direct-app-launch — the surprisingly useful one

The endpoint nobody talks about:

POST http://<tv-ip>:8060/launch/<channel-id>

Channel IDs are stable Roku-assigned numbers. 12 is Netflix, 13 is Prime Video, 837 is YouTube, 291097 is Disney+. Posting to /launch/12 boots Netflix on the TV — no D-pad navigation needed.

This is the killer feature for a remote that lives on a phone or in a browser: you skip the entire "navigate the home screen" UX that makes physical Roku remotes annoying. One tap → on Netflix.

Full list of channel IDs is in the device's response to GET /query/apps (returns XML, so use DOMParser not JSON.parse).

4. Putting it together

type RokuKey =
  | "Home" | "Back" | "Select"
  | "Up" | "Down" | "Left" | "Right"
  | "VolumeUp" | "VolumeDown" | "VolumeMute"
  | "PowerOn" | "PowerOff"
  | "Play" | "Pause" | "Rev" | "Fwd"

class RokuRemote {
  constructor(private tvIp: string) {}
  private base() { return `http://${this.tvIp}:8060` }

  press(key: RokuKey) {
    return fetch(`${this.base()}/keypress/${key}`, { method: "POST" })
  }

  type(text: string) {
    return Promise.all(
      [...text].map(ch =>
        fetch(`${this.base()}/keypress/Lit_${encodeURIComponent(ch)}`, { method: "POST" })
      )
    )
  }

  launchApp(channelId: number) {
    return fetch(`${this.base()}/launch/${channelId}`, { method: "POST" })
  }
}

That's the whole remote. Render a D-pad with onClick={() => remote.press("Up")} and you have a working web-based Roku remote in 80 lines.

TL;DR

Roku's HTTP control protocol is plain POST /keypress/<KeyName>. No auth. 80 lines of TypeScript = working remote. Discovery is the only genuinely hard part for a browser context, and "ask the user for the IP" is the right answer there.

The end result is live at hiremote.app/hisense-roku-tv-remote — bring your own Roku-TV IP and try it without installing anything.

DEV Community: hisuperdev

How I built a single iOS app that controls all four Hisense smart-TV platforms

TL;DR

1. VIDAA — MQTT over TLS

2. Roku TV — ECP is HTTP

3. Google TV — gRPC dance

4. Fire TV — ADB-style local connection

Platform detection via mDNS

I built an in-browser Roku TV remote with ~80 lines of TypeScript. Here's how Roku's ECP API actually works

1. Discovery — SSDP is overrated, the user types the IP

2. Buttons — every command is a POST to a path

3. Direct-app-launch — the surprisingly useful one

4. Putting it together

TL;DR