What it is
The Lutron Caséta integration connects Home Assistant to a supported Lutron bridge or processor. It exposes supported lighting and other device controls, along with remote-button events. My custom Pico behavior is an automation layer on top of that built-in integration, not a separate HACS package.
My Setup
My Pico as a Custom TV Remote
I use a Lutron Caséta Pico PJ2-3BRL as a compact TV remote. My Home Assistant automations give its buttons navigation, selection, power and volume functions. A short press and a held press can request different actions, so the same physical controls cover both menu navigation and everyday TV operation.
The customization lives in my Home Assistant automations. The Pico communicates through the Lutron Smart Bridge and the built-in Caséta integration; the TV commands then use SamsungTV Smart and SmartThings. This is a local automation build, not a separate integration I have published.
The Pico supplies the input; Home Assistant assigns the action
The Lutron Smart Bridge brings the Pico's button events into Home Assistant. My handler listens for press events and waits for a matching release or a short timeout before choosing the action. The button's original lighting label identifies the input; my automation decides what that input means for the TV.
Pico button → Lutron Smart Bridge → Caséta integration → Home Assistant tap/hold logic → SamsungTV Smart key command or SmartThings power request
The Pico is not paired to my Zigbee coordinator and does not send TV commands directly. Its path is separate from ZHA. Home Assistant connects the remote's input to the TV integrations.
The connections behind the custom remote
Scroll the table horizontally to compare all four columns.
| Connection | Information | How I use it | Limit or dependency |
|---|---|---|---|
| Pico and Smart Bridge | Physical button press and release events. | Provide the remote input through the Caséta integration. | The remote, bridge and Home Assistant connection must be available. |
| Custom event handler | Button identity and whether release arrived before the timeout. | Select the short-press or held-press action. | Hold classification is my automation logic, not a native Caséta long-press event. |
| Hold helpers | Raise and lower button press/release state. | Keep volume requests repeating while the corresponding helper is on. | A helper is software state; missed releases and overlapping presses matter. |
| SamsungTV Smart | Remote-key command requests. | Navigate menus, select, return, open Home and adjust volume. | Supported keys and their effect depend on the TV and current screen. |
| SmartThings | Reported power state and on/off requests. | Handle the held bottom-button power action. | Cloud access, authorization and fresh power-state reporting. |
What each button does in my setup
These are the mappings in my configured TV handler. They describe the requests the automation makes, rather than guaranteeing how every TV app responds.
Top / on
- Tap
- Navigate left.
- Hold
- Send the TV's Return command.
Bottom / off
- Tap
- Navigate right.
- Hold
- Request power on or off through SmartThings, based on the reported TV state.
Center / favorite
- Tap
- Enter or select.
- Hold
- Open the TV's Home screen.
Raise
- Tap
- Navigate up.
- Hold
- Repeat volume-up requests while the hold helper is on, up to a finite request limit.
Lower
- Tap
- Navigate down.
- Hold
- Repeat volume-down requests while the hold helper is on, up to a finite request limit.
This makes the Pico useful beyond its original lighting role: taps cover directional navigation and selection, while holds add Return, Home, power and volume. The TV's screen and selected app still determine what a navigation command does.
How tap, hold and repeating volume work
Classifying the press
After a press arrives, the handler waits briefly for release. Release before the timeout selects the tap action; no release before the timeout selects the hold action. A held action therefore starts after that threshold, rather than waiting for the eventual release.
Caséta does not provide the native long-press trigger described for some other Lutron processors. My timeout-based interpretation is a customization built from the press and release events.
Tracking volume-button holds
A companion automation turns separate raise and lower helpers on when those buttons are pressed and off when they are released. The volume loop consults the relevant helper between requests and spaces out the repeated key commands.
The loop also has a finite request count. That bounds one invocation if the hold state does not clear, but it is not a maximum TV volume and does not confirm that the TV received every request. Multiple overlapping handler runs can still make their own requests.
A local input can still lead to a cloud-dependent action
The Caséta bridge connection supplies the local input. My power action uses the separate SmartThings integration, so the full remote workflow is not entirely local. SamsungTV Smart handles the key-command side and has its own TV compatibility and connection requirements.
The held power action chooses on or off from the state reported through SmartThings. A stale or unavailable state can lead to an unsuitable request. A successful Home Assistant action also does not prove that the TV powered on, changed screen or changed volume.
Press and release handling needs care when more than one remote or automation is involved. Shared hold helpers and overlapping events can affect repetition. A missed release can leave a helper on until a later event or correction; the request cap limits a loop rather than repairing that helper state.
Home Assistant must be running for these custom mappings to work. The Pico's own bridge pairing does not preserve the custom TV behavior if the automation or target integration is unavailable.
Check the input, decision and TV response separately
- Observe the input. Confirm that the intended Pico produces both press and release events with the expected button identity.
- Inspect the decision. Use the automation trace to see whether release arrived before the timeout and which tap or hold branch ran.
- Check the hold helpers. Raise and lower should track their respective press and release events. A stuck helper explains a different problem from a failed TV command.
- Check the target integration. Diagnose SamsungTV Smart key requests separately from SmartThings power state and commands.
- Verify the TV. Observe the actual result, including volume stopping after release. A trace alone cannot establish that physical response.
The public guide describes the behavior without exposing my remote identifiers, entity names or private automation configuration. The linked documentation covers the upstream integrations; it is not a repository for my custom Pico mapping.
What it can do
Bridge-connected controls
Expose supported dimmers, switches, shades and other devices configured in the Lutron system.
Physical button inputs
Use Pico press and release events to trigger Home Assistant automations.
Custom action mappings
Connect those inputs to controls from other integrations, such as the TV actions in my setup.
Software timing
Build a tap/hold interpretation and bounded repetition in automations where native device events do not provide the behavior wanted.
Install and connect
Before you start
- A supported Lutron Smart Bridge or processor with the Pico paired to its Lutron system.
- Home Assistant able to reach and authenticate with the bridge using the supported setup flow.
- For this TV mapping: separately configured SamsungTV Smart and SmartThings connections, plus the custom automations and hold helpers.
Set up the Lutron side
Configure the supported bridge and remote in the Lutron system first. The Pico is not paired through ZHA.
Connect Home Assistant
Add Lutron Caséta through Settings > Devices & services, or accept discovery, and follow the integration's pairing instructions.
Verify physical button events
Check press and release events from the intended Pico. Home Assistant button entities send a press request; they are not the physical-press input for an automation. Use the documented events or device triggers.
Build the custom mapping
Connect verified button inputs to the desired TV commands. Scope the event handlers to the intended remote, track release events for repetition, and use a finite request limit.
Check tap, hold and release
Verify one button at a time, then check power reporting, release handling and behavior when a connection is unavailable. Installing Caséta alone does not create the custom TV mapping.
Limits and caveats
- Supported controls depend on the bridge, processor and device model.
- Caséta does not emit the native long-press event supported by some other Lutron processors. The held actions in this build are inferred by an automation timeout.
- The local remote input does not remove cloud dependencies from a downstream integration such as SmartThings.
- Repeating key requests can overlap or outlast a missed release. A finite request count is not a TV volume ceiling or delivery acknowledgement.
Sources and next steps
- Home Assistant Lutron Caséta documentationSupported bridges, pairing, physical button events and device-trigger differences.
- Lutron Caséta integration sourceThe built-in Home Assistant component, separate from my custom automations.
- SamsungTV SmartThe TV integration used for remote-key requests in this build.
- Home Assistant SmartThings documentationSetup and current service requirements for the separate power-control connection.