Lutron Smart Bridge Light and Shade Control

Lutron Smart Bridges: Light and Shade Control

Use this skill when fresh discovery identifies a compatible Lutron Smart Bridge and the user requests light or shade status/control.

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.

Community-sourced instructions, not an official integration. Read repository-context.md before using this standalone package; it identifies the exact upstream repository, runtime dependencies and evidence to hand back. The original workflow and device limits below are retained.

Modified-file notice: Humans to Know added the editorial context and standalone reference links to this upstream skill.

Identify the Device

• Match bridge model and current advertised HAP or documented LEAP service, not the brand alone.
• Use exact discovered endpoints. Lutron product families do not all expose the same protocols.

Prerequisites

Read the Humans to Know editorial repository context for the pinned SDK, Linux execution boundary and task-specific verification. This supplement resolves the missing public home_link.md reference.

• HAP requires the eight-digit setup code for a pairable bridge or previously authorized controller pairing keys.
• A bridge already in Apple Home does not automatically give Muse its credentials. Do not reset or remove an existing pairing. If access is unavailable, use only a supported independently authorized alternative or request setup.
• LEAP uses a separate physical pairing flow and client certificate/private key; HAP credentials do not substitute for them.

Workflow

1. Prefer the HAP path when authorized pairing is available. Use a maintained HAP client over the shared network access.
2. When the advertisement has ff=1, select PairSetupWithAuth; plain PairSetup can fail at M2 with kTLVError_Authentication. Keep that exchange on one persistent connection.
3. Store successful pairing material in approved credential storage (private file permissions if file-backed). Open an encrypted session and enumerate actual accessories, services and characteristics.
4. Read the target light/shade state and supported ranges. Resolve ambiguous generic accessory names before writing; any physical identification action must be explicitly requested.
5. Write only the requested characteristic, then read back the individual result. For partial batch failures, inspect each target before retrying uncertain operations.
6. For a compatible bridge using LEAP instead, follow pylutron-caseta's pairing routine with the user present, store its own credentials, enumerate devices with the authenticated client and use its documented level/cover operations.

Verify the Result

• Check the intended accessory's resulting on/brightness/position state, not merely a successful session or write acknowledgement.
• For shade movement, observe progress and final state; preserve obstruction and motor behavior.
• If pairing or a command fails, report that exact limitation without implying the bridge has no local API.

Limits

• No assumed LIP/telnet access, cloud fallback, broad product compatibility or replacement of someone's existing Home.
• Do not add schedules, change bridge configuration or discover room mappings by unrequested toggling.

Sources

• pylutron-caseta
• aiohomekit HAP client