Lutron Caseta Pico (Core Integration Only)

[stephack]

[Updated: Support released events]
[Update 2: re-factored code for simplicity]
[Update 3: added automation mode options (single, restart, queued or parallel)]
[Update 4: removed “integration” from input selector to avoid weird 2022.6.x issue]

Please Note:

• This will NOT work with the upsert custom component. It’s for the core Lutron Caseta integration only.
• It supports both pressed and released events. Thanks @mattsheffiel for inspiring me to add released as well.
• It currently only supports the 5 button Pico with model PJ2-3BRL-GXX-X01 (Pico3ButtonRaiseLower) which I believe is the most common.

Use this button to start the Blueprint import if you have configured the My Home Assistant url or import manually using the yaml below.

blueprint:
  name: BP - Pico Config
  description: "This is for the 5 button picos that have the following model:\n\n
  PJ2-3BRL-GXX-X01 (Pico3ButtonRaiseLower)\n\nSelect an action for each button listed below. "
  domain: automation
  input:
    pico_remote:
      name: Pico Remote
      description: "Select the pico remote to configure:"
      selector:
        device:
          #integration: lutron_caseta
          model: PJ2-3BRL-GXX-X01 (Pico3ButtonRaiseLower)
    auto_mode:
      name: Automation Mode
      description: "Mode that automation runs in (single,  restart, queued, parallel)."
      default: restart
      selector:
        select:
          options:
            - single
            - restart
            - queued
            - parallel
    mode_max:
      name: "Mode Max (ignored by Single and Restart Modes)"
      description: "Maximum number of runs that can be executed or queued at a time."
      default: 10
      selector:
        number:
          min: 1
          max: 15
    top_on:
      name: Top (On) Button Pressed
      description: "Execute when TOP button is PRESSED"
      default: []
      selector:
        action: {}
    top_on_release:
      name: Top (On) Button Released
      description: "Execute when TOP button is RELEASED"
      default: []
      selector:
        action: {}
    up_raise:
      name: Up (Raise) Arrow Button Pressed
      description: "Execute when UP button is PRESSED"
      default: []
      selector:
        action: {}
    up_raise_release:
      name: Up (Raise) Arrow Button Released
      description: "Execute when UP button is RELEASED"
      default: []
      selector:
        action: {}
    middle_stop:
      name: Middle (Fav) Button Pressed
      description: "Execute when MIDDLE button is PRESSED"
      default: []
      selector:
        action: {}
    middle_stop_release:
      name: Middle (Fav) Button Released
      description: "Execute when MIDDLE button is RELEASED"
      default: []
      selector:
        action: {}
    down_lower:
      name: Down (Lower) Arrow Button Pressed
      description: "Execute when DOWN button is PRESSED"
      default: []
      selector:
        action: {}
    down_lower_release:
      name: Down (Lower) Arrow Button Released
      description: "Execute when DOWN button is RELEASED"
      default: []
      selector:
        action: {}
    bottom_off:
      name: Bottom (Off) Button Pressed
      description: "Execute when BOTTOM button is PRESSED"
      default: []
      selector:
        action: {}
    bottom_off_release:
      name: Bottom (Off) Button Released
      description: "Execute when BOTTOM button is RELEASED"
      default: []
      selector:
        action: {}
trigger:
  - platform: device
    device_id: !input pico_remote
    domain: lutron_caseta
    type: press
    subtype: 'on'
  - platform: device
    device_id: !input pico_remote
    domain: lutron_caseta
    type: press
    subtype: 'raise'
  - platform: device
    device_id: !input pico_remote
    domain: lutron_caseta
    type: press
    subtype: 'stop'
  - platform: device
    device_id: !input pico_remote
    domain: lutron_caseta
    type: press
    subtype: 'lower'
  - platform: device
    device_id: !input pico_remote
    domain: lutron_caseta
    type: press
    subtype: 'off'
  - platform: device
    device_id: !input pico_remote
    domain: lutron_caseta
    type: release
    subtype: 'on'
  - platform: device
    device_id: !input pico_remote
    domain: lutron_caseta
    type: release
    subtype: 'raise'
  - platform: device
    device_id: !input pico_remote
    domain: lutron_caseta
    type: release
    subtype: 'stop'
  - platform: device
    device_id: !input pico_remote
    domain: lutron_caseta
    type: release
    subtype: 'lower'
  - platform: device
    device_id: !input pico_remote
    domain: lutron_caseta
    type: release
    subtype: 'off'
condition: []
action:
  - choose:
      - conditions: '{{ trigger.event.data.action == "press" }}'
        sequence:
        - choose:
          - conditions: '{{ trigger.event.data.button_number == 2 }}'
            sequence: !input top_on
          - conditions: '{{ trigger.event.data.button_number == 5 }}'
            sequence: !input up_raise
          - conditions: '{{ trigger.event.data.button_number == 3 }}'
            sequence: !input middle_stop
          - conditions: '{{ trigger.event.data.button_number == 6 }}'
            sequence: !input down_lower
          - conditions: '{{ trigger.event.data.button_number == 4 }}'
            sequence: !input bottom_off

      - conditions: '{{ trigger.event.data.action == "release" }}'
        sequence:
        - choose:
          - conditions: '{{ trigger.event.data.button_number == 2 }}'
            sequence: !input top_on_release
          - conditions: '{{ trigger.event.data.button_number == 5 }}'
            sequence: !input up_raise_release
          - conditions: '{{ trigger.event.data.button_number == 3 }}'
            sequence: !input middle_stop_release
          - conditions: '{{ trigger.event.data.button_number == 6 }}'
            sequence: !input down_lower_release
          - conditions: '{{ trigger.event.data.button_number == 4 }}'
            sequence: !input bottom_off_release
    default: []
mode: !input auto_mode
max: !input mode_max

Thanks to @erikg for getting this started.

2 Button version (PJ2-2B-GXX-X01) created by @ogiewon can be found here:
Lutron Caseta Pico 2-Button Remote (Core Integration Only)

4 Button version (PJ2-4B-GXX-X31) created by @mattsheffiel can be found here:
Lutron Caseta Pico 4-Button Scene Remote

[erikg (Erik)]

You could simplify the action section of the blueprint like this:

action:
- variables:
    PICO_ON: 2
    PICO_FAVORITE: 3
    PICO_OFF: 4
    PICO_RAISE: 5
    PICO_LOWER: 6
    action: '{{ trigger.event.data.action }}'
    button_number: '{{ trigger.event.data.button_number }}'

- choose:
  - conditions: '{{ action == "press" }}'
    sequence:
    - choose:
      - conditions: '{{ button_number == PICO_ON }}'
        sequence: !input top_on
      - conditions: '{{ button_number == PICO_RAISE }}'
        sequence: !input up_raise
      - conditions: '{{ button_number == PICO_FAVORITE }}'
        sequence: !input middle_stop
      - conditions: '{{ button_number == PICO_LOWER }}'
        sequence: !input down_lower
      - conditions: '{{ button_number == PICO_OFF }}'
        sequence: !input bottom_off

  - conditions: '{{ action == "release" }}'
    sequence:
    - choose:
      - conditions: '{{ button_number == PICO_ON }}'
        sequence: !input top_on_release
      - conditions: '{{ button_number == PICO_RAISE }}'
        sequence: !input up_raise_release
      - conditions: '{{ button_number == PICO_FAVORITE }}'
        sequence: !input middle_stop_release
      - conditions: '{{ button_number == PICO_LOWER }}'
        sequence: !input down_lower_release
      - conditions: '{{ button_number == PICO_OFF }}'
        sequence: !input bottom_off_release

[stephack]

Thanks @erikg. I like to minimize lines of code so I personally don’t use variables for static values. However, I will update the BP to use the nested choose statements since it would optimize the code logic.

[stephack]

I updated the BP with the nested choose statements.
I also forgot that templating support was changed a few updates ago to be automatically “understood”. Makes for much cleaner code. Thanks again @erikg

[erikg (Erik)]

So the 2-button remote has a name of PJ2-2B-GXX-X01 (Pico2Button) and has the same button numbers (2 == on, 4 == off). Is there any way to specify multiple device constraints for a selector? Or a regex for the model string?

I tried a few variations of:

        device:
          integration: lutron_caseta
          model: PJ2-3BRL-GXX-X01 (Pico3ButtonRaiseLower)                

and

        device:
          integration: lutron_caseta
          model: PJ2-2B-GXX-X01 (Pico2Button)

However, selector will only accept a dictionary (not a list), and model will only accept a string (no list or regex). If there’s a workaround, you could cover both remotes with this one blueprint vs. having to have separate blueprints for each.

An alternative would be to leave off the ‘model:’ entirely, but then you get ALL the Lutron devices, not just Pico remotes.

[jsdphilly]

Thank you!

I made the custom component version and I could not figure this one out!

[stephack]

You can probably replace the model with a variable or allow the model to also be a separate input…even a toggle eg. If PJ2-2B-GXX-X01 toggled on then.....etc

Allowing multiple pico remote options isn’t the point of concern for me though. It’s with regard to how confusing the UI will become and also how bloated the yaml structure would become for such a simple automation. Having used a few other consumer automation platforms has made me a firm believer in the KISS principle.
To me, adding multiple remotes does not increase the value of the BP enough to make it worth the extra complexity. Just my opinion of course and I’m sure many may disagree. I’d be happy to test and help implement such a blueprint but I won’t be updating my BP to support that. At least not until the HA devs allow for better UI options with the Blueprint editor (like hiding entire sections based on user input). At that point, at least it would act more like an app and wouldn’t be confusing to the user.

[erikg (Erik)]

@stephack

Allowing multiple pico remote options isn’t the point of concern for me though. It’s with regard to how confusing the UI will become and also how bloated the yaml structure would become for such a simple automation. Having used a few other consumer automation platforms has made me a firm believer in the KISS principle.

Absolutely agree with KISS.

In this case, though, the 2-button remote can work with this blueprint without any modifications to the trigger/action sections. Obviously any actions you assign to the middle/raise/lower buttons will have no effect for the 2-button remote, but the rest of it works as-is. That’s why I was looking for a way to allow both types of remotes to be selected in the input selector.

[danboth]

This and the 2 and 4 button BPs are great. I had to make a 4th BP just for the Fan Pico. As it’s model number is 1 character different from the standard Pico. (PJ2-3BRL-GXX-F01). I just copied stephs and swapped out the model number. Other than leaving the model selector out is there an easier way without having to add another BP?

[stephack]

@danboth

Other than leaving the model selector out is there an easier way without having to add another BP?

Unfortunately, BP’s don’t let you pick and choose models…so the only options would be a single Pico model or All Lutron devices. There is a feature request to allow lists in selectors but I dont think that feature would be added anytime soon.

[CMfly]

There was a pretty sweet automation in Lutron Caseta Pico Remotes and Node-Red that detects multiple and long press from a pico remote, I know this is using a different integration where the remote is an entity and not just firing events but I was wondering if the same logic could be added to the blueprint to surface these interactions with the remotes?

[stephack]

The picos don’t natively send any “held” events. The only was to capture these would be by using timestamps, etc. I have tried these type of synthetic button events on other automation systems and historically they haven’t been reliable. I haven’t tried it with HA but I suspect it would be the same…unreliable. I may give it a shot when I have some extra time in the future. Feel free to use my existing BP as a template if you feel comfortable editing it.

[2carlos (Carlos)]

When did the core integration get updated to work with pico remotes? I thought that was only possible on the upsert custom integration… any reason to stay on that now that it’s available in core?

[stephack]

@2carlos

When did the core integration get updated to work with pico remotes

The last upgrade added picos.

@2carlos

any reason to stay on that now that it’s available in core

None that I can think of.

[glward (Garrett L Ward)]

I’m not sure “restart” is the best mode for this (though I’m not sure which is tbh). Took me a few minutes to figure out, but I had a script that I was triggering off of the “favorite” button that takes several seconds to run (Sonos grouping) and it was failing to complete until I changed the mode to “queued”.

I assume “restart” was stopping the execution of the script when the “Release” event came in, as the script ran fine if I held the button down until it finished . Probably only relevant for complex scripts/actions – I would assume single actions would complete before the “Release” event came in.

Anyway, with that little tweak it seems fine – this will make setting up the rest of my pico remotes much easier. Thanks!

[stephack]

Yeah…there’s no “correct” mode as it would depend on what the Automation is designed to do (ie multiple quick actions, long extended actions with delays, etc).

I wonder if I can have the mode as a UI option now that the latest HA update allows “select” selectors.
Will look into it.

[stephack]

@glward

I’m not sure “restart” is the best mode for this (though I’m not sure which is tbh)

@stephack

Yeah…there’s no “correct” mode as it would depend on what the Automation is designed to do (ie multiple quick actions, long extended actions with delays, etc).

I added an option to select the mode the automation will run in. The select selector worked perfectly for this use case.
@ogiewon, @mattsheffiel (in case you wanted to update your BP’s to include this functionality).

[stevenpoint]

Does anyone have an example for Up/Down for dimming/increasing lights or opening/closing shades? I’m currently just setting it to say 25% but there must be some good way to jump in 5-10% increments or something any ideas?

[stephack]

@stevenpoint Can’t speak for shades but I do precisely this for lights using brightness_step.

service: light.turn_on
data:
  brightness_step: 20
entity_id: light.bedroom_lamps_group

Use negative numbers for lowering brightness.

[Yanal]

Thanks for all of the work you’ve done on this, I’ve been using it and it works great. I like the brightness increase but I really wanted to replicate the regular Caseta dimmers press and hold to increase and decrees brightness.

I followed these instructions to create an automation for smooth dimming since I use Deconz for most of my lights. Is this something that can be ammended to this blueprint or a whole new one has to be created?