Google TV Streamer Media and Remote Control
Control Google TV Streamer Cast media or Android TV Remote v2 keys and app links through Muse Home Link. Use the current service, normal pairing and separate result checks.
Google TV Streamer
Humans to Know Editorial Context
Use the pinned Muse Gadget SDK repository for runtime setup. Existing LAN-device clients run on its Linux Home Link through system.run; the Muse app, SDK token and VM connection remain required.
This is a community-sourced Muse device skill, adapted by Humans to Know; it is not an official integration. Before choosing the runtime, read repository context and task handoff. That supplement identifies the pinned SDK, Linux command boundary, setup dependencies and the evidence to retain for this device.
Use this skill when the confirmed Google TV Streamer advertises a usable Cast receiver and/or Android TV Remote v2 service.
Identify the Device
- Match Google TV Streamer model identity and current firmware/service metadata rather than assuming every Google TV device is this model.
- Keep Cast and Remote v2 endpoints distinct. Availability of one does not prove the other has paired or can control the device.
Prerequisites
Read the Humans to Know repository context before network access. It is an editorial supplement for the upstream home_link.md reference, whose target is absent from this public snapshot.
- An already-provisioned device with the relevant interface available.
- For Remote v2, a compatible
androidtvremote2client, the normal on-screen pairing code and securely retained client certificate/private key. - For media playback, a user-approved source the receiver can already reach.
Workflow
- For Cast media, volume and status, use the Google Cast skill, including receiver capabilities and result checks.
- For Remote v2, use the confirmed service and the client's documented pairing/control connection setup over HomeLink TCP. Do not treat an open control port as a paired session.
- If necessary, start normal user-approved pairing, complete the displayed code challenge and retain the client certificate/private key. Pairing and control are separate connections.
- After authenticated connection, send the requested documented remote key or app link using the compatible client. Use supported power/volume behavior only when exposed by this device.
- Observe available state and ask for visual confirmation where navigation has no reliable programmatic read-back.
Verify the Result
- Keep discovery, pairing success and remote-control success as separate outcomes.
- For Cast, follow the shared skill and do not count an app launch or buffering state as playback.
Limits
- No screenshots, package queries/installation, battery/screen inspection, developer/debugging setup or fallback control.
- No universal foreground-app query, app entitlement or off-state wake promise.
Sources
humanstoknow/skills · Apache-2.0 — upstream community recipe with Humans to Know editorial additions · Revision 79908eb1d698
Be the first to comment
Share what worked or leave a question for the creator.