Roku changed one default and took away the buttons

Available now in the HomeSeer plugin store.

Roku's External Control Protocol is plain HTTP on port 8060 with no authentication, no pairing and no cloud. Every call is a local one. It is the most pleasant protocol in this entire suite and it took the least work to support, which is exactly why the interesting parts of this plugin are all about the things that went wrong anyway.

The update that broke half of it

Roku OS 14.1 added a per-device setting — Control by mobile apps → Network access — and defaulted it to limited. Under that setting:

/query/device-info    allowed
/query/active-app     allowed
/launch/<id>          allowed
/keypress/*           403
/query/apps           403
/query/media-player   403

So a plugin that worked perfectly yesterday can report what is playing and launch things, but can no longer press a single button — and does so without any announcement, on whatever schedule Roku pushes firmware.

The plugin reads that setting explicitly and reports it. A 403 here is a switch on the device, not a fault in the code, and it is retried never and explained plainly. The difference between "this is broken" and "this device is set to limited; here is where to change it" is about forty minutes of somebody's evening.

The discovery trap, which is a Windows problem

SSDP is the polite way to find Rokus, and on a Windows machine it fails silently.

The replies arrive as inbound UDP to a plugin executable nobody has written a firewall rule for, and Windows Firewall drops them by default. There is no error. The socket simply never receives anything, and an empty result looks exactly like a house with no Rokus in it.

So there is a fallback that makes only outbound connections, which the firewall permits: probe each address on the local subnet for an ECP responder. It is deliberately modest — 32 at a time, and only networks of /24 or smaller, so pointing this at a business LAN does not fire thousands of requests at it.

I have since hit the identical trap twice more: Plex's GDM discovery, and Wemo's SSDP. Same cause, same silent failure, same outbound-only fix. It has become the first thing I check when discovery finds nothing on Windows.

Identity, and a rule that keeps recurring

A Roku is identified by its serial number, never its address. These are DHCP clients; a lease change would otherwise orphan the HomeSeer device and every event written against it. The same rule appears in the Wemo plugin, the Hubspace one, and anywhere else the thing being tracked can move.

The artwork problem

Session artwork looked like it should be easy: point the device card's graphic at the media server's URL and let the browser fetch it.

That fails in the one place that matters. The browser does the fetching, and a media server answers 503 to clients it has not authorised — even on the same LAN. The plugin's own machine can always fetch it, because it talks to the server all day. So it downloads the thumbnail once and hands HomeSeer a local file instead.

Then a second, sillier problem: the card's art slot is a fixed square that stretches whatever it is given, so a 2:3 poster came out visibly squashed. Native aspect was tried; the slot won. The images are now letterboxed onto a square canvas, which keeps the poster the right shape at the cost of two clear bars.

The wall that started something bigger

A Roku Ultra cannot report its own volume. Not an oversight — when it is plugged into a television over HDMI it hands volume control to the display via CEC, and genuinely does not know what happens next. It is forwarding keypresses into the dark.

Which means there is no route to the real state of the room through the Roku at all. The only thing that knows how loud the television is, is the television.

That realisation is what started the AV plugin. A limitation in a small piece of work turning into the design of a much larger one is, in my experience, how most of the interesting projects actually begin.