Lutron Integration: 2021.2 core integration vs. custom lutron-caseta-pro?

[erikg (Erik)]

Quick update: I’ve successfully migrated all my non-Pico devices to the core Lutron Caseta integration and removed them from the lutron-caseta-pro integration. The Picos remain while I figure out how to convert my blueprints. Everything seems to work fine, and the process went as smoothly as I’d hoped.

For reference, here are the steps I took:

1. Rename all entities associated with the lutron-caseta-pro integration to [entity]_lutronxx.
2. Update all automations, scripts, template sensors, scenes, groups, lovelace, etc. to refer to the new (*_lutronxx) entity names.
3. Allow HA to auto-detect my Caseta-Pro bridge and then use the UI to set up the integration (i.e. push the black button on the bridge and watch magic happen).
4. Confirm that everything is still working with the _lutronxx entities
5. Check out the new devices/entities from the core integration - make sure everything responds to commands and state updates are happening
6. Rename any new devices/entities that aren’t how I want them - i.e. remove underscores in friendly names, delete _light from the end of entities like light.foo_light, etc.
7. Incrementally update automations, scenes, scripts, groups, template sensors, and lovelace to reference the new entity names for Lutron devices and make sure stuff still works.
8. Confirm there are no references to _lutronxx anywhere in my YAML files.
9. Delete entries related to non-Pico devices from lutron-caseta-pro JSON config file
10. Remove entries in configuration.yaml section that define switch and fan entries for lutron-caseta-pro, but leave the other entries so the Pico remotes still work.
11. Restart HA
12. Find all *_lutronxx entities and delete them via the Entities page in the UI

[erikg (Erik)]

@stephack

I got impatient and decided to recreate my “1 automation per pico” templates using the event data and it’s simple enough. I still hope they create entities in the future but for now this will work for me.

Have you figured out how to implement this with blueprints rather than individual automations? I could see how to do it by specifying the serial number as a blueprint input, but that kinda defeats the purpose of being able to select a (Pico Remote) device directly from the UI. I have a blueprint that works really well for my Pico remotes, but it uses the lutron-caseta-pro entities as triggers rather than the device triggers that the core integration provides. If I can figure out how to use device triggers in the blueprint, I could completely ditch the custom_component integration (which is the long-term goal).

[stephack]

@erikg

Have you figured out how to implement this with blueprints rather than individual automations?

I haven’t tried. I only use blueprints for my motion lighting automations. My use for button devices vary way too much so I simply create an automation for each button device.

You can select the devices (not entities) via the ui with the core integration. Maybe try using them in your blueprints instead .

Btw, for the few cases where my button automations were similar, I simply used the Duplicate feature in the Automation Editor and then edited each action/condition as needed. It would probably take the same time as using blueprints anyway.

[erikg (Erik)]

Ok, so I figured out how to implement Pico automations with the core integration via blueprints without having to track down serial numbers. This has also allowed me to completely uninstall the lutron-caseta-pro integration.

For the Pro integration, the blueprint input looks like this:

    pico_remote:
      name: Pico Remote
      description: >-
        The sensor for the Pico remote that indicates if a button is
        pressed, and if so, which one.
      selector:
        entity:
          domain: sensor

For the core integration, only the selector type needs to change:

      selector:
        device:

I need to figure out how to refine (constrain) the selector so it only shows Pico devices, but this works for now.

The next thing is that the button numbers are different:

Pro Integration:

  PICO_ON: 1
  PICO_FAVORITE: 2
  PICO_OFF: 4
  PICO_RAISE: 8
  PICO_LOWER: 16

Core Integration:

  PICO_ON: 2
  PICO_FAVORITE: 3
  PICO_OFF: 4
  PICO_RAISE: 5
  PICO_LOWER: 6

Next, the triggers are different using entities vs. devices:

Pro Integration

- platform: state
  entity_id: !input pico_remote

Core Integration:

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'

I tried leaving off the subtype from the trigger definitions (to only have one entry rather than one for each type of button press), but that doesn’t work. If anyone knows how to collapse the above into a single entry, I’m all ears.

And finally, the action section will be slightly different anytime you need to reference the trigger object:

Pro Integration:

    - conditions:
        - condition: template
          value_template: '{{ trigger.to_state.state|int == PICO_OFF }}'

Core Integration:

    - conditions:
        - condition: template
          value_template: '{{ trigger.event.data.button_number|int == PICO_OFF }}'

That’s it… pretty straightforward once you know the details about device triggers. You could also do the above without blueprints by just replacing the !input parts with the actual Device ID for your Pico remote.

[stephack]

@erikg

I need to figure out how to refine (constrain) the selector so it only shows Pico devices, but this works for now.

I only have the 5 button picos that have this model type:

PJ2-3BRL-GXX-X01 (Pico3ButtonRaiseLower)

Based on this model you can use the following selector to refine you pico input.

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

You can also leave out the “model” section and it will limit the options to devices that are part of the core Lutron integration. This will include all the Pico models but will also include the lights, etc.
I’ll probably throw together a blueprint some time this weekend and post in the BP Exchange.

[stephack]

This turned out to be pretty simple so I posted a full blueprint on the exchange sub forum for this. Thanks for posting your details.

Lutron Caseta Pico (Core Integration Only)

[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 support…

Edit:
Updated the blueprint to support released events as well.

[erikg (Erik)]

Nicely done! The blueprint looks great. I’ll post my light-specific one (that has more built-in functionality) once I finish testing it.

And thanks for the details on the model/integration. For future reference, how did you determine the the specific text for those fields? I see where to get event data from the event listener, but I wasn’t sure how to get the device details. I have a 2-button Pico (still in packaging), so I can get the text for that model once I install it.

[stephack]

Configuration -> Devices

The Heading for each column for example “Model” and the corresponding value for the Pico device.

[andrew3 (Andrew)]

Thanks guys. These blueprints are great!

[andrew3 (Andrew)]

I’ve been testing 2021.3 beta. Unfortunately the included changes to the fan domain have broken the lutron fan controllers I have as part of this integration. Hoping this gets fixed when out of beta.

[stephack]

From what I read in the release notes, they’re changing the fan states from L/M/H to numeric values. You probably just need to update your actions accordingly.

[andrew3 (Andrew)]

Here’s the associated error in the logs. Looks like maybe the Lutron integration needs to be updated to work with the updates to the fan domain in home assistant core.

[stephack]

Please let them know via whatever feedback mechanism they have for the Beta. Luckily I don’t use Caseta for my fans but it would save a lot of others the grief of waiting for an x.1 to correct that issue.

[andrew3 (Andrew)]

I just posted the issue to the github tracker. Thanks.

[bdraco (J. Nick Koston)]

Handle lutron_caseta fan speed being none

Should be fixed here. We need someone who experienced the issue to validate it is resolved.

[andrew3 (Andrew)]

I’m not sure how to validate?

[bdraco (J. Nick Koston)]

Manually apply the code change or wait for beta4

[andrew3 (Andrew)]

Installed beta5. Still having issues with the lutron fans:

Logger: homeassistant.components.fan
Source: util/percentage.py:22
Integration: Fan ([documentation](https://www.home-assistant.io/integrations/fan), [issues](https://github.com/home-assistant/home-assistant/issues?q=is%3Aissue+is%3Aopen+label%3A%22integration%3A+fan%22))
First occurred: 3:33:37 PM (2 occurrences)
Last logged: 3:33:37 PM

* Error adding entities for domain fan with platform lutron_caseta
* Error while setting up lutron_caseta platform for fan

Traceback (most recent call last): File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 317, in async_add_entities await asyncio.gather(*tasks) File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 509, in _async_add_entity await entity.add_to_platform_finish() File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 530, in add_to_platform_finish self.async_write_ha_state() File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 295, in async_write_ha_state self._async_write_ha_state() File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 319, in _async_write_ha_state sstate = self.state File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 693, in state return STATE_ON if self.is_on else STATE_OFF File "/usr/src/homeassistant/homeassistant/components/lutron_caseta/fan.py", line 94, in is_on return self.percentage and self.percentage > 0 File "/usr/src/homeassistant/homeassistant/components/lutron_caseta/fan.py", line 49, in percentage return ordered_list_item_to_percentage( File "/usr/src/homeassistant/homeassistant/util/percentage.py", line 22, in ordered_list_item_to_percentage raise ValueError(f'The item "{item}"" is not in "{ordered_list}"') ValueError: The item "Off"" is not in "['Low', 'Medium', 'MediumHigh', 'High']"

[bdraco (J. Nick Koston)]

Can you try this PR?

Fix lutron caseta fan handling of speed off

[andrew3 (Andrew)]

Sorry, this is my first time point out bugs to the team. How can I try a pull request?