That is good to know but I am running it in a docker which presents unique issues with adding custom components. I was going to try to carve out some time to setup HA on my computer and update all of my configs. Figure it is going to be a pretty big task since it has been almost a year since I updated.
I use hassio and run custom_components, I believe docker would be the same, you just add a custom_components folder into your config directory.
Except you have to commit it to the docker container otherwise the changes are lost. Just need to refamiliarize myself with docker and plow through it. Like I said it is mostly because of the config changes that I am putting this off. Also I used a different caseta component from jhanssen so that will need rebuilt along with my automations. It is good that they support custom components now, at the time we had to dump the files into the components folder.
Custom components donāt need to be committed into the container. They can just go in a custom_components folder in the same directory as your configuration.
Yes I think custom_components is newer than when I last updated. I am running 0.53.1
Well then, yes, if you upgrade (minding all of the potential breaking changes between 0.53 and now) youāll have support for custom_components and those will persist through container changes. The upgrade is likely to take some effort, but the component installation is super easy and this Lutron component works very, very well.
Does this component work with the Lutron RA2 Main repeater āRR-MAIN-REPā, that is the non-Select version? From what I understand the interface is identical to the Select version and this component seems to have much better support for Picos and other devices.
I note that in one of the posts above, there is mention of issues with the integration report being in a different format, is that the āonlyā issue? Would getting a Lutron Connect Bridge make is work, Iād be happy to get oneā¦ (a bit desperate to ditch my Vera when hooking up Lutron RA2 to HA).
I have several RA2 Main systems is use, including shades, fans, keypads and what not; would be happy to test/debug.
Thank you.
The custom component is only for Ra2 Select and Lutron Caseta Bridge Pro. From what I can tell the Connect Bridge does not have an interface and is acting as a gateway to the telnet interface on the RR-MAIN-REP.
As you mentioned there are differences in the integration report and features not found on the Ra2 Select / Caseta products. The big reason though is that I do not want to duplicate the functionality of the existing Lutron component and would rather see that improved.
Based on the code, it has light, switch, cover and scenes. Instead of a sensor, it generates events for pico remote buttons. That should cover most use cases. There could be some more work done to support occupancy sensors (which incidentally do not output to telnet on Ra2 Select) and to break out fan controllers, but that could be done with some code contributions to pylutron and the lutron component.
Thank you very much for your detailed reply.
Your custom component seems to have the broadest device support and I thought Iād ask. It seems the pylutron is poorly supported and a single Lutron component covering Caseta, Select and the RA2 would be desirable.
I did just order a connect pro and will give your component a run when it arrives.
Has anyone looked into the speed at which the notification of state change come from the smart bridge or the smart bridge pro? I noticed from an in-wall dimmer, the state is not broadcast (or doesnāt show up in HA) until after the ramp-up / ramp-down. But the pico buttons are broadcast almost instantly. I would LOVE it if I could have this update speed from the in-wall dimmer so I can run timely automations! I would even buy the smartbridge pro if the telnet interface has a different behaviour.
Sorry this is a late reply to the topic, but this question came up over on the Hubitat forms as well and the developers said that the hub does not send the on/off event until the ramp up/down process is complete, so there is nothing that can be done to speed up the integrations. Since that platform only supports the pro hub, itās true or that one as well (it may be that the switch itself doesnāt even send the status immediately).
Even more annoying is that the non-dimming switches have the same delay! I have an older house with two separate switches and two lights in the same hallway. I have them paired with a Hubitat automation, but I still get the 2-3 second lag because of that issue. Itās one of the few things I dislike about the casetas.
The pro with the unofficial integration is instant. I just tested it.
Perhaps John & I are talking about different things. I will grant that Iām only about a week into using HA, but Iāve reproduced the situation using the upsert/lutron-caseta-pro add-on and a Caseta Pro hub.
To reproduce what Iām talking about (and what I think Graham is talking about), open HA on a mobile device so you can see the switch status and hold it next to each of the followingā¦
- In-wall dimmer. With the light off, press the on button. The on status will not be reflected in HA until after the light has ramped up and is fully on (a few seconds). Oddly, the off status gets reflected when the light is about 60% through the process.
- Pico remote. Regardless of the state of the light, the state in HA is updated immediately after pressing the pico button.
- In-wall switch. Despite the switch not actually dimming, the status in HA is still delayed roughly the same amount of time as it is for a dimmer.
I could post some videos if this isnāt clear, but theyāre terrible quality because I didnāt have enough hands to hold a camera and a phone, and press a wall button. Based on comments from the engineers on the Lutron forums, it seems to be an acknowledged ādesign choiceā because the caseta hardware hasnāt been updated since 2004 and only has a tiny bit of ram, so for some reason they have to work this way. Thus, any automations triggered by an in-wall switch will be delayed.
Lowering the default_transition_seconds setting is a nice feature, but that only effects commands sent to the wall switches. The delay from the wall switches will always be there unless Lutron were to put out a firmware update (not sure thatās even possible). But Lutron is very proud of their stuff, they havenāt looked at their competition since about 2005, and apparently there is a really big market for their $$$ light switches and the installers that go with them, so it seems unlikely.
Of course, Iād be thrilled if thereās something Iām missing that makes all of this untrue.
Try this ā
Make an automation that when the device turns off it is immediately turned back on.
Then go and turn it off manually and see how quickly it turns back on.
In my case, with the transition set to 0, it is immediate. I turn off a Lutron device and it immediately turns back on. This is the same for dimmers and switches.
With the default transition in place you will see a fade off and fade on, but this is the transition and not the reporting state speed.
See the config snippet:
lutron_caseta_pro:
bridges:
- host: 192.168.xxx.xxx
mac: 60:xx:xx:xx:xx:xx
default_transition_seconds: 0
Are you sure there isnāt a Pico switch involved somewhere in your setup? I did as you suggested and got excited that you were correct, but then I realized I was turning the light on and off with a wall-mounted Pico. When I turned the light on with the actual switch, I have the ~2 second delay before it turns off, even with a non-dimmer switch.
Hereās my config and my rule, and restarted HA for good measure:
lutron_caseta_pro:
bridges:
- host: 10.59.xx.xxx
mac: c8:fd:19:xx:xx:xx
default_transition_seconds: 0
switch: [ 2, 6, 19, 26, 27, 29, 32, 36, 37, 42, 49, 54, 56 ]
fan: [ 46 ]
- alias: Test 3
description: ''
trigger:
- entity_id: switch.dana_s_office_closet_light
from: 'off'
platform: state
to: 'on'
condition: []
action:
- entity_id: switch.dana_s_office_closet_light
service: switch.turn_off
I run āupsertā integration with a Pro bridge. It is instant here.
Very nice integration, the update for configuration changes is as easy as it gets.
Hereās a video of how long the above automation takes to fire (I did invert on/off to ensure I was testing exactly what jwelter suggested). Also, Iām not blaming the code - Iāve seen it discussed in two other forums that this is ājust the way it isā so Iām trying to figure out what the difference is (Iād even suspect a difference in newer switches, but I just installed that particular switch in last month).
Iām using the Pro bridge, upsert, and Iāve tested with at least 4 switches now. Itās instant with a pico remote, but not with the switch itself, which is the same experience I had with other platforms. 
Very odd. Do you see this with the on/off switches by Lutron as well?
Are you using wifi to the pro-bridge or ethernet?
Yes, same delay with on/off switches - the one in the video is a non-dimmer, actually. Iām using the Pro bridge on the same ethernet switch as my HA server. To really confuse things, hereās the official explanation from Lutron that was posted over in the Hubitat forum:
Lutron RF dimmers always wait 3 seconds before reporting changes made locally at the dimmer. This is because the user is often fine-tuning or adjusting the dimmer with multiple back-to-back events (on/raise/lower/etc), so the dimmer waits until local activity has stopped (3 seconds after the last local activity) before reporting the final level back to the system. The level reported by the dimmer is intended for status purposes only, and is not intended to be used for triggering other events.
A better solution is to use Pico and Keypad events. These are reported immediately to the system, and will result in much faster response time, as the events from a Pico are intended to result in other devices (dimmers, for example) changing in response to the button events. If setting up automation, Lutron recommends using button events rather than level status updates if quick response time is desirable.
The only possibility I see based on that explanation is if this integration is somehow getting the ābutton eventā from the in-wall devices (Iām not even sure if thatās possible) and those seeing instant reactions have a different rule setup. Could someone getting an instant response from an in-wall device post their automation to see if weāre taking different approaches?
What is the use case for needing the state update in less than 2 seconds? Is it to trigger other non-Lutron lights?