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

erikg · February 4, 2021, 4:14am

Buried in the “All Changes” section of the 2021.2 release notes, it mentions that the core Lutron Caseta integration now supports Pico remotes (and the requisite Pro bridge). (YAY!!)

I’ve been using the (custom component) lutron-caseta-pro integration for the better part of a year now, and it works well. It’s a pain to download the integration report, manually update the JSON file in HA, and then restart HA whenever I need to make a change, but lately, that’s not very often.

Now that the core integration supports the Pro bridge and exposes the Pico buttons as sensors, I think there’s no reason for me to be using a custom component anymore.

One potential downside I see is that the core integration exposes the Pico buttons as device triggers instead of sensor entities. The implications of that that I can see are:

I’d have to update my automations to reference the device triggers instead of sensor values. As I was planning to convert to blueprints when I have time, this might not be too bad.
Writing automations in YAML would be more tedious because device IDs aren’t as easy to find. Again, blueprints could mitigate this… I think.
Automations would need to change whenever a device is changed/replaced/re-added, as the device ID would be new, unlike current entity IDs. But hopefully this is rare, and blueprints would lessen this impact.

A few questions:

Is there anything that the lutron-caseta-pro component does that the core integration doesn’t do now? Anything I’d miss after switching?
Does the core Lutron Caseta integration integration allow for device add/remove/update operations without restarting Home Assistant?
Any reasons not to consider moving to the core Lutron Caseta integration?
Finally: has anyone switched from the custom component to the core integration recently? Anything to watch out for?

dproffer · February 4, 2021, 4:29am

Good questions, thanks! I have been on the custom component for a very long time. Not sure I can answer all your question, due to fact my config is pretty simple compared to most. That said, here are my three points:

If it is working, do NOT mess with it
I’m not sure if I am 100% correct on this, but I think the custom component is all LOCAL. Does not go to internet to manage your devices at all, very good thing I believe. I do not know how the new built in component (even with Pro hub) works.
I like to contribute to new improvements to HA, but that needs to be balanced with being on the ‘bleeding edge’, combine that with keeping the ‘significant other’ happy

Good hunting!

stephack · February 4, 2021, 1:20pm

I installed it on a test instance of HA. The new setup is different now and the Lutron hub is auto discovered. It can be configured without yaml and does not require a login to your caseta account…which tells me that it is all local now too. The Picos are added as devices that now appear as options in automation dropdowns. The button presses also appear as user readable options and don’t require mapping numeric values to each button. I’m very impressed and plan to move over my production instance of HA…when I have a bit of free time to redo my automations.

danboth · February 4, 2021, 11:18pm

Does anyone know how to create an automation blueprint using the new pico feature in the standard lutron caseta integration? I tried and failed miserably.

erikg · February 5, 2021, 1:45am

Thanks @stephack for the info and the screenshot. Based on the change log, that’s roughly what I’d expected to see on the automation triggers section. Nice to see the specifics.

Since this integration connects directly with the hub, I think it might be able to co-exist with the lutron-caseta-pro component (which uses the telnet interface AFAIK).

That makes me think that I might be able to install the new core integration, make sure all devices are set up, happy and perform well; and then migrate my automations over to using the devices/entities from the core integration. Once the original entities from the lutron-caseta-pro integration are no longer referenced in any automations or dashboards, then I could remove the lutron-caseta-pro custom component. Maybe. I think. Possibly. Or am I too much in the wishful thinking realm today? That would certainly be a low-risk option if it’s a possibility.

stephack · February 5, 2021, 3:24am

@erikg Hadn’t thought of that and it sounds like it could work. Let me know if you try it because that’s definitely a route I would like to go if it is in fact possible.

danboth · February 5, 2021, 3:41pm

They do coexist fine. I did just that. I add the standard interface and slowly migrated all my automation as and such to it and removed the custom interface this morning.

stephack · February 5, 2021, 3:58pm

Lol…I did the same since I had the day off from work… but I’m still in the process of recreating my automations as I type this…such fun

stephack · February 5, 2021, 4:26pm

@danboth, do you have any automation configured for your picos? I’m having difficulty recreating mine primarily because the built-in integration does not create entities for them…only devices. I don’t want to create a separate automation for every button on every pico .
With the upsert component I used templates like shown below to create one automation per pico (instead of 5). I didn’t realize that templating was not available for the device platform and I’m not sure how to proceed. I know I could parse the event data from Developer Tools but I’m hoping there’s an easier way.

- id: '1608503146029'
  alias: Pico - Bedroom - Stephan old
  description: ''
  trigger:
  - platform: state
    entity_id: sensor.bedroom_pico_1_stephan
  condition: []
  action:
  - choose:
    - conditions:
      - condition: template
        value_template: '{{ trigger.to_state.state == "1" }}'
      sequence:
      - service: light.turn_on
        data:
          brightness: 255
        entity_id: light.bedroom_lamps_group
    - conditions:
      - condition: template
        value_template: '{{ trigger.to_state.state == "2" }}'
      sequence:
      - service: light.turn_on
        data:
          brightness: 25
        entity_id: light.bedroom_lamps_group
    - conditions:
      - condition: template
        value_template: '{{ trigger.to_state.state == "4" }}'
      sequence:
      - service: light.turn_off
        data: {}
        entity_id: light.bedroom_lamps_group
    - conditions:
      - condition: template
        value_template: '{{ trigger.to_state.state == "8" }}'
      sequence:
      - service: light.turn_on
        data:
          brightness_step: 25
        entity_id: light.bedroom_lamps_group
    - conditions:
      - condition: template
        value_template: '{{ trigger.to_state.state == "16" }}'
      sequence:
      - service: light.turn_on
        data:
          brightness_step: -25
        entity_id: light.bedroom_lamps_group
    default: []
  mode: queued
  max: 10

xman111 · February 5, 2021, 4:27pm

i updated HA and noticed it discovered my Pro bridge. Didn’t realize it would be this easy, may switch over to the built in and get rid of the custom component.

erikg · February 5, 2021, 4:29pm

Awesome - thanks for letting us know!

Any issues with naming conflicts when setting up the core integration? I’m guessing the Friendly Names and entity names are still imported based on the names in the Lutron app… which is the same for both integrations. So I expect the new entities show up as things like light.kitchen_sink_2 for the newly installed one and then you do some musical-~~chairs~~-names as you update automations and such?

stephack · February 5, 2021, 4:38pm

Exactly what happens. I didn’t update any of my light automations. Simply renamed the upsert entities to _old and renamed the new entities by removing the _2

erikg · February 5, 2021, 4:42pm

Now that you mention it, I remember thinking about this as I went to update my automations when the choose functionality was released last year. Like you, I have one automation for each Pico remote, and it uses a choose action to determine which button was pressed and thus which sequence to execute.

I was going to update my Phillips Hue remote automations similarly and then found that I couldn’t because they only have device triggers for the buttons, not entities. For now, I left the Hue remote automations as 4 automations per remote, but that wasn’t terrible because they were already written and I only have 2 of those remotes.

Now Pico remotes… I’ve lost count of how many I have of those. They’re so useful and dead-reliable. Making a separate automation for all 5 buttons on each Pico would be a little crazy.

I haven’t converted my Pico automations over to blueprints (that’s in the queue), but that might be a solution. I’ve mainly converted entity-based automations so far, but it looks like you can do device-based interactions, too.

Another workaround (assuming the integrations coexist happily together) would be to use the Pro integration for the Pico remotes only (only define those in the JSON/config files) and then use the core integration for all the other devices. Then you’d get the benefits of the UI-based integration and if you need an entity for a Pico, you could use that, too.

erikg · February 5, 2021, 4:45pm

LOL. Exactly what I was thinking to do… except maybe rename to _old before adding the core integration so I don’t have to deal with _2 entities, and then I just delete _old from automation/lovelace code once the new integration is installed.

stephack · February 5, 2021, 4:54pm

The both seem to coexist without issue but I don’t want the unneeded processing for double the events being updated…especially with regard to database writes (I use both mariadb and influxdb).
Also, my OCD wont allow me to have my automation list swamped with sinple automations per button. That would be 8x5(40) automation just for picos…hellll no. If I dont find a better solution I’m going to use the event data below to create my templates again.

"event_type": "lutron_caseta_button_event",
    "data": {
        "serial": 12345678,
        "type": "Pico3ButtonRaiseLower",
        "button_number": 2,
        "device_name": "Pico Stephan",
        "area_name": "Bedroom",
        "action": "release"

Edit:
Just realized what you meant here:

might be worth doing for now…and I’ll submit a feature request to have the core integration create sensor entities for the picos. Thanks for the suggestions.

danboth · February 5, 2021, 9:50pm

I had to revert to the 5 automations per remote. Under the custom integration I used a single automation per remote with a python script. The automation was:
clipboard

‘- id: foyer_light_by_pico
  alias: Foyer Light controlled by pico
  initial_state: True
  trigger:
    - platform: state
      from: 0
      entity_id: sensor.foyer_pico
  action:
  - data_template:
      entity_id: light.foyer_light
      new_state: "{{ trigger.to_state.state }}"
    service: python_script.pico_light_switch_std`

The Python script is here:

gist.github.com

https://gist.github.com/catchdave/a6dc17be9a4f55559d12c1a094573707

pico_light_switch_std.py

#
# Script to manage a light using standard controls from a Lutron Pico Remote
# This will translate the standard button meanings on a Pico to any light controlled
# by Home Assistant.
# The "favourite" button is presumed to be 50% brightness (but can be overriden).
# Expected data packet is: { new_state: X, entity_id: entity_id, fav_brightness: [0-100] }
#     new_state: REQUIRED. The pico value that triggered the event.
#     entity_id: REQUIRED. The entity_id of the light to control
#     fav_brightness: OPTIONAL. What brightness percentage to set when the favourite button is pressed (int 1 - 100).
#

This file has been truncated. show original

I do not have the technical knowledge to adapt it. Open if anyone else can tackle it.

stephack · February 5, 2021, 11:59pm

@danboth @erikg 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.

As I said in a previous post, this is what is generated when a button is pushed:

"event_type": "lutron_caseta_button_event",
    "data": {
        "serial": 12345678,
        "type": "Pico3ButtonRaiseLower",
        "button_number": 2,
        "device_name": "Pico Stephan",
        "area_name": "Bedroom",
        "action": "release"

So the event type is “lutron_caseta_button_event”
The “serial” ~~and the “device_name”~~ can be used to identify the specific pico. ~~I chose the device_name since it doesn’t require me to watch the event log for every pico. If you have multiple picos with the same name (why would you?) then serial is your best bet.~~
“button_number” is the numerical value of the button pushed. For the 5 button pico it would be as follows: Top Button = 2; Fav = 3; Bottom = 4; Up = 5; Down = 6
“action” would be “press” or “release”. I would be using “press” 99% of the time so the actions are performed immediately.

Based on the above, I used the Automation editor to easily create automations like the one below.

  trigger:
  - platform: event
    event_type: lutron_caseta_button_event
    event_data:
      #device_name: Pico Stephan
      serial: 12345678
      action: press
  condition: []
  action:
  - choose:
    - conditions:
      - condition: template
        value_template: '{{ trigger.event.data.button_number == 2 }}'
      sequence:
      - service: light.turn_on
        data:
          brightness: 255
        entity_id: light.bedroom_lamps_group
    - conditions:
      - condition: template
        value_template: '{{ trigger.event.data.button_number == 3 }}'
      sequence:
      - service: light.turn_on
        data:
          brightness: 25
        entity_id: light.bedroom_lamps_group
    - conditions:
      - condition: template
        value_template: '{{ trigger.event.data.button_number == 4 }}'
      sequence:
      - service: light.turn_off
        data: {}
        entity_id: light.bedroom_lamps_group
    - conditions:
      - condition: template
        value_template: '{{ trigger.event.data.button_number == 5 }}'
      sequence:
      - service: light.turn_on
        data:
          brightness_step: 25
        entity_id: light.bedroom_lamps_group
    - conditions:
      - condition: template
        value_template: '{{ trigger.event.data.button_number == 6 }}'
      sequence:
      - service: light.turn_on
        data:
          brightness_step: -25
        entity_id: light.bedroom_lamps_group
    default: []
  mode: queued
  max: 10

danboth · February 6, 2021, 3:57am

Thank you Stephack. This automation is fantastic

stephack · February 6, 2021, 1:02pm

So after a fun morning of my bedroom lights coming on randomly…Wife was NOT happy…I now realize that using the device name is not ideal and using the serial should be the default method to identify the individual picos. The “device_name” in the event is actually the name of the device “type” in the Lutron App. Below is a screenshot from the Lutron android app. The “device_name” in this case is “Pico” and not Master Bathroom Pico. So…when my son woke up at 4am and turned on one of his lamps using the middle button, it also took my bedroom out of Sleep Mode and reactivated my motion sensors. Immediately resulted in a precipitous drop in WAF.

TLDR - user “serial” and not “device_name” from the “lutron_caseta_button_event”. I edited my previous post accordingly.

erikg · February 12, 2021, 2:25am

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:

Rename all entities associated with the lutron-caseta-pro integration to [entity]_lutronxx.
Update all automations, scripts, template sensors, scenes, groups, lovelace, etc. to refer to the new (*_lutronxx) entity names.
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).
Confirm that everything is still working with the _lutronxx entities
Check out the new devices/entities from the core integration - make sure everything responds to commands and state updates are happening
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.
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.
Confirm there are no references to _lutronxx anywhere in my YAML files.
Delete entries related to non-Pico devices from lutron-caseta-pro JSON config file
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.
Restart HA
Find all *_lutronxx entities and delete them via the Entities page in the UI