Hey there @JonGilmore, mind taking a look at this pull request as its been labeled with a integration (lutron) you are listed as a codeowner for? Thanks!

@thecynic I'm curious to know your thoughts on this PR with how LEDs were implemented. I haven't gotten a chance to fully review/test it yet

@alistairg finally got a chance to pull this down to test it out. Seems like there might be a little more work required on it. Here are some observations:

• when I first booted HA, all LED switches were off, even though multiple keypads had LEDs on
• does it make more sense to make the LEDs sensors rather than switches? When I switch an LED off, the scene itself doesnt turn off, but the LED does. This just seems a bit confusing to me.

@koreth @bdunks @achatham @benjimatt @nickovs would love to hear input from you guys on this PR

Hmm - I’d have expected it to sync with the keypad LEDs at boot, but there’s a broader bug in the Lutron integration I’ve yet to track down that doesn’t properly queue commands. This could be another symptom of that (I notice this issue on my home system when sending multiple “Cover Close” commands)

The use case I have requires switches vs sensors, and that’s been the root of all my testing. Most of the keypads in my home are “virtual” (controlling no local load) and I use the buttons to trigger actions within HASS. That’s why I added the “Full ID” parameter to the event - such that it can be tracked back to the right keypad.

The LED control allows me to mirror an internal state within HASS at the keypad - for example, showing that a set of lights in a room are on, or that automated control for a room is active. For the most part, this functionality could technically be achieved using phantom switches within Lutron, but this is a significant waste of capacity within the Lutron system - notably for folks that are limited to the “Essentials” 100 device limit. I use the switch entity within HASS to directly control the LED at keypad(s) as needed.

Why a switch and not light platform?

Thats a good question. Technically, this doesn't control anything except for the led on the keypad itself. Does HA have any other integrations like this? Seems like this is a very unique case...

Ended up here to request keypad LED control as well... after reading above I would just chime in as a user that if it's a switch it will stand out differently than all the lights in the lutron system... but I think it's splitting hairs.

I just hope this isn't idling around just for the sake of deciding if it should be a light or a switch.

Ended up here to request keypad LED control as well... after reading above I would just chime in as a user that if it's a switch it will stand out differently than all the lights in the lutron system... but I think it's splitting hairs.

I just hope this isn't idling around just for the sake of deciding if it should be a light or a switch.

I'm curious, what is your use case with wanting to control the keypad LEDs? Do you have an opinion one way or another? Did you actually test this PR out? I had issues when testing it that I stated above:

when I first booted HA, all LED switches were off, even though multiple keypads had LEDs on

Would be interested on whether this is going to go forward or die on the "PR" vine, also. I'm running this in my own home, and would love to not be running forked custom components if at all possible ;)

Would be interested on whether this is going to go forward or die on the "PR" vine, also. I'm running this in my own home, and would love to not be running forked custom components if at all possible ;)

@alistairg have you tested the startup issue I described? Can you reproduce it? I think it'd be worth resolving that before merging.

I'm curious, what is your use case with wanting to control the keypad LEDs? Do you have an opinion one way or another? Did you actually test this PR out?

My use case... in my master bedroom I have a keypad with keys labeled "Locks" and "Heat Pump".

If I have any locks on exterior doors unlocked, I would like to light the LED. Pressing the button on the keypad would trigger an automation to lock every exterior door. Once the locks report they are locked, the LED is turned off.

Second case for the Heat Pump... if the thermostat is on Auto, Heat, or Cool, the LED is on. Pressing the keypad button toggles between Off and Auto. If the thermostat is turned to Off, the LED is turned off.

I haven't tested the PR yet. I should have some time tomorrow to check it out. I have an 80 device RA2 install, with about 10 keypads so I'll see what happens.

In general, this looks reasonable, but I don't use LEDs via hass so don't know if i can comment on whether or not this is integrated correctly here. switch does seem like the right thing since the controlled entity isn't actually a light but an LED on the keypad, but I'm not sure if hass has another paradigm for such things.

Realized I never commented back on some things... switch appears to be the convention used on other devices. I have a Skybell wi-fi doorbell cam, and changing the settings for the LED backlight is a switch. Same for my pool interface integration, changing status for things is done via switch, even if it may turn lights on or off.

Testing on my 0.106.5 system with these changes shows it working great on my dual repeater system.

thanks @neillt - I tested on my dev system running the latest 0.107.4 and things look to be working as I'd expect them to be.

Why a switch and not light platform?

I agree with pvizeli, an LED emits light and should be a light, not a switch.

I'm not sure I agree - the LED on these things is not a light, but a binary indicator. As HASS groups anything that looks 'binary' to a switch (e.g. input_boolean), this makes sense to be a switch. It doesn't provide useful or measurable light, it's just state tracking.

Why a switch and not light platform?

I agree with pvizeli, an LED emits light and should be a light, not a switch.

There is already precedent in other integrations (like Skybell) where indicator LEDs that are not used for useful illumination are switches, not lights.

Just curious when we might see this roll into an actual release? 107 is getting point updates almost every day and this is just hanging there.

There is already precedent in other integrations

In software development it doesn't work like that. There is no reason to assume past decisions are still the right one.

It doesn't provide useful or measurable light, it's just state tracking.

It isn't just state tracking, since you can change the state.

@neillt About releases; 0.107 is the current stable, the patch releases only contain bug fixes, never new features. So not sure how patch releases are related to your comment.

Feel free to help us lower the workload by pre-reviewing other PR's. That is always greatly appreciated 👍

It isn't just state tracking, since you can change the state.

@frenck I meant that from a Lutron perspective it's just state tracking. You can't directly control the keypad LED from a Lutron button or similar, it just tracks the state of either other Lutron devices or reflects an internal variable (which can now be controlled by HA).

This isn't control of a Lutron "light" from HA, but a Lutron state indicator. That indicator could reflect the on/off state of a further light (which would be represented as a light in HA).

It gets more complicated than that... what about phantom keypads you program into the lutron system? In that case, there isn't a physical LED at all, just a variable being tracked within the lutron system when a particular scene or condition is met.

For example, if I created a phantom keypad button for a "night" scene, and it's called programmatically say by the astro clock, there may not be a physical button. But there is still an "LED" that can be queried and tracked to determine if that scene is active.

@neillt About releases; 0.107 is the current stable, the patch releases only contain bug fixes, never new features. So not sure how patch releases are related to your comment.

True... I suppose this is a new feature rather than a bug fix. I understand.

Welp, it looks like this didn't make it into 0.108, even though it's ready and works great.

How do we reach a resolution on what to call the LED control entities. This code has been working for over 45 days now.

Similar to @thecynic, I’m not sure if I have a vote. If I do: Merge as switch.

I’ve been following since @JonGilmore tagged me three months ago, and somewhere along the way we got sideways.

The LED is fundamentally not a light in the Lutron ecosystem. It only exists within the scope of another Lutron “DEVICE” (light, scene, shade, etc.). While it’s referenced as an LED in the Lutron technical integration documentation, and can be queries or set independently, its state is also used to show scene and light state in the LutronConnect app - I.e., no light emitted from the LED.

Additionally, as pointed out earlier, LEDs could be associated with DEVICES on the “HOMEOWNER_KEYPAD,” or the reserved Phantom Buttons on the “MAIN_REPEATER,” both of which have no physical representation.

Let’s merge as switch and then take the debate to another pull request if folks have pragmatic use cases to control these as a light.

FWIW, I vote for LEDs being switches too.

Ditto; switch seems more appropriate to me.

Do we need to update the docs?
https://www.home-assistant.io/integrations/lutron/

Please check if we should update the docs. Ping me when that's done and I'll merge.

Docs do need updating. I tried to create a PR and my noobness with git was ALL too apparent. I quickly canceled the PR. Here is the markdown I tried to incorporate, to be inserted right after the keypads section:

Keypad LEDs

Each full-width button on a Lutron SeeTouch, Hybrid SeeTouch, and Tabletop SeeTouch Keypad has an LED that can be controlled by Home Assistant. A service call of switch.turn_off or switch.turn_on against the appropriate LED entity will control the keypad LED.

Keep in mind that the Lutron system will also control the LED state independent of Home Assistant, according to the programming of the RadioRA2 system. This also means you can query LED states to determine if a certain scene is active, since the LED will have been illuminated by the RadioRA2 repeaters. This includes the "phantom" LEDs of Main Repeater Keypad buttons; even though there is no physical button or LED, the RadioRA2 system tracks the scenes and will "light" the LED that can be queried.

If a button is not programmed to control any lights or other devices in the RadioRA2 system but is given a name in the programming software, it will be available to fire events in Home Assistant. However, since there is no way to have a scene "active" on a button with no devices associated, the Main Repeater will automatically extinguish the keypad LED a few seconds after the button press. If you wish to have Home Assistant light the keypad LED after a button press, you will need to delay your service call to light the LED for several seconds, so it arrives after the Main Repeater has sent the command to turn it off.

@MartinHjelmare here's the documentation PR: home-assistant/home-assistant.io#13096

Also, thanks @neillt :D

Thanks for creating the Docs PR @JonGilmore 👍