Lutron Integrators?

In my system they do. I will look into the programming and see how it's set up. I recall messing with LED settings at some point for this very reason, but it was quite some time ago.

I'm not keen on the idea of night being a phantom button, as it makes the Lutron system totally dependent on Hubitat. As it is, if the hub were to go down, the keypads still work. You can always press a button, and then brighten with the up button.

I agree w/not all phantom buttons. Thanks for looking.

I don't know why your keypad button LEDs don't light up, but probably because they aren't setup right. Mine are all setup as Shared Toggle with a Shared Scene. The phantom buttons are Single/Multi Room Scenes. Here is an example of Lutron Button Integrator setup below. This one has an Alexa name (Kitchen), and when Alexa turns it on, it gets the correct level (thanks to phantom button) and the keypad LEDs come on.

By using a Shared Toggle, when any light in the scene is turned on, the keypad LED turns on. In Inclusive, if you look at the button programming, it has a little pop-up called "When to use" that explains how the LED works.

OK, making the scene a toggle works to turn on the keypad LEDs. I only have Essentials (no shared scenes or toggles), Inclusive isn't necessary to make it work in the way that you are describing. But that brings up more comments/questions!

  1. There are some implications to making the Night scene a toggle. When any dimmer that is part of a toggle scene is turned on, the toggle is set to "on" in the Lutron main repeater (this allows the toggle scene to function as a monitor). I have a dimmer that I activate separately before I get to the keypad. If I then press the keypad button, the lights go out.

  2. Now that I see you intended the base Night scene to be a toggle, I understand (I think) the "Select button for off" input (4 in your example). This button seems to only be used to turn off physical lights when telling Alexa to turn off the virtual switch. It is not used from the keypad.

  3. The "Select dimmers for Alexa" doesn't seem to do anything?

  4. In Night mode, telling Alexa to turn the virtual switch "on" doesn't work. There is no Telnet activity noted in the logs. It works when telling Alexa to turn the virtual switch "off".

  5. Having figured these issues out, I'm changing my base Night scene back to a regular single/multi room scene, It works better for my use cases. Except for keypad indicator lights.

  6. (Not related to toggles) One of the things that I do is to add the keypad in the Button Controller as I have Philips Hue bulbs that need to be added to the base Lutron scene. When I do that, that the Button Controller action seems to takes precedence over base keypad button pushes in other actions. Example: I have a Habitat-programmed/controlled Pico. I map a Pico button to the keypad button. That Pico button now executes that actions from the Button Controller app, even though it's mapped to the keypad device. This is Good even if it is not evident in the flow precedence!

  7. IMO, I think a consequence of the complexities in some of what I describe above is a reason for implementing scene functionality (that includes buttons) in Hubitat as soon as possible.

I hope I've been clear and concise in this reply.

Yes, this is a phantom button that turns the lights off.

This is used for causing the associated optional virtual disable switch to be thrown when a physical dimmer is used to change dimmer levels. That virtual switch could be used to disable other automations. Telling Alexa to change levels does the same thing.

This works for me. Telling Alexa to turn on kitchen results in the first keypad night button being pushed. In my example that is Button 2 on two keypads (labelled Kitchen). Test to verify that pushing the button selected does what you expect in Night mode.

Do you mean that you have programmed that Pico button in Lutron to map it to the keypad button? If so, you would expect it to do both things, its Lutron programming and its Hubitat programming. I use the Pico toggle part of the app to link a Pico button into the app (is that what you mean by map?). If that same Pico button is included in other automations, through Button Controller or any other, it will do all of the actions its programmed for -- it can fire multiple automations. The reason that Pico buttons are included in this app is for the toggle synchronization.

"Scenes" is a much discussed concept, unfortunately with multiple meanings and connotations. Our existing built-in apps DO implement scenes by one definition (e.g. button causing a group of lights to turn on to a preprogrammed level, as is done with Lutron Button Integrator).

What we mean by a "scene" is a predetermined set of light/switch settings, activated by some mechanism. This is what Lutron does with scenes -- you have some predetermined levels that you activate with a keypad button. Our scenes implementation will include both parts of that definition: the predetermination of light/switch settings, and the activation mechanism(s). In Lutron, one must use Essentials (or Inclusive) to do the predetermined settings and associate the activation mechanism (keypad or phantom button). Our existing built-in apps use the same approach. In our "scene" implementation, we will use a capture mechanism, and associate captured levels/switches with an activation mechanism(s).

All Alexa on/off commands work as expected except for Night mode 'On'. In night mode the Alexa virtual switch shows a "Dimmer On" command in the logs, but no action is taken and nothing is shown in the Lutron logs. This is not important to me as I don't use the functionality here.

No in-Lutron Pico programming. I am talking about Button Controller app programming only. Sorry if my previous statement may have been confusing as it is in this thread that has been mostly about the "Button Integrator" app.

Here are my steps:

  1. I set up my keypad in Hubitat. It is listed as a "Lutron Keypad" device.
  2. I add a Button Controller instance to control the keypad. I add other non-Lutron lights like Philips Hue color bulbs to the associated keypad buttons. This works exactly as expected - keypad button pressed, Lutron scene (including mode-based scene selection controlled by Lutron Integrator app settings) is set, non Lutron dimmers are set.
  3. I add a blank Pico to Hubitiat. It has no in-Lutron programming.
  4. In Hubitat programming I set the Pico button to trigger a "Lutron Keypad" device button.
  5. That Pico button triggers the actions set in the "Button Controller" instance, so actions include the Hue lights in my example.

I don't think I would expect that. But I like it as it avoids having to use RM.

I think the Lutron comparison is a good one. In Essentials each scene is unique (no shared scenes), so you have to uniquely program each keypad/phantom button, even if you want 2 buttons to be the same. In Inclusive you can have shared scenes, so set once and then just point each button to the shared scene.

Hubitat is currently closer to Essentials. One can set levels on buttons and switches in Hubitat in many ways and places and can call those the same settings from many other ways and places. But that flexibility creates many opportunities for spaghetti-like automations that are hard to trace.

What I want is to see in Hubitat is the Inclusive definition. I think it can be a very powerful way of simplifying automations. There's a Scene Manager app that works fine for switches and dimmers (it sets the switches and creates a virtual momentary switch that will trigger the scene including Alexa). But it doesn't (currently) include the ability for button devices.

I think scenes makes Alexa automations a fair amount easier and more intuitive too. Tell Alexa to turn the scene on - "Alexa turn on Downstairs Bright". Also have a group device in Alexa - "Alexa turn off Downstairs Lights". That's better than saying "Alexa turn off Downstairs Bright" IMO.

Do you mean 'pushing a button', as you're doing with Button Controller? If so, that's an interesting point.

There are two types of scenes, those that toggle and those that just are set. Both Lutron and Control4 support both. We intend to support both as well. The toggle scenes can be activated by a switch or a button, and the non-toggle scenes can be activated by a momentary switch or a button.

Yes, exactly.

This feature should be added to Groups also. Or maybe not. Not clear when it would be used. Makes good sense for a scene. If a Lutron scene were attached to such a button, the type of the scene (toggle vs non-toggle) would have to line up.

I'm not sure how valuable a button selection is for groups. It seems the button number would have to be the same for all the buttons.

I use groups almost exclusively as on/off switch (esp. for Alexa as I said above). Setting other group attributes really only works well if the lights are identical. Anything more then I'd use a scene.

I'd like to have a per mode option for scenes too

I don't follow. Are you saying you want to be able to activate a different scene for each mode? From the same button? So which scene the button fires depends on the mode?

If so, that's simply a mode restriction on each scene, where each scene includes activation by the same button.

Yes, I think that's right. It seems like that's pretty close to the equivalent of how the Lutron Button integrator works. You already have some of the same per mode dimmer and color flow in the Button Controller app. It's not a strictly necessary requirement. But it would be one fewer time to go to RM.

@bravenel - new question/request:

Is there a way to determine if and what scene is set on a keypad? I'd like to be able to take an action based on a scene being active.

I could see this being based on LED status for buttons on a physical keypad or main repeater. It would have to be an array as more than one LED/scene can be active at a time.

I see there is a Custom Command getLed() for the Lutron keypad. Is this something that would work? If so, how would one use that in a rule?

The getLed() command has not actually been implemented, despite the definition for it being in that driver (which should be removed). Due to the asynchronous nature of the Lutron interface, completing this implementation would take a little effort -- basically keeping the LED state in the driver for each button.

LED events are reported for each LED, and these can be subscribed to in an app (Button Integrator does so). So it would be possible to maintain the LED state in an app. The name of these events is "buttonLed", the event value is "on" or "off", and the evt.data element called "ledNumber" is the button number.

Doing any of this would required a custom app. As an event, the setting of a button LED would not be usable in Rule Machine unless RM were extended to support that as one of its capabilities. A small custom app could be written (using info from above) that would map keypad buttons to virtual switches, and then those virtual switches could be incorporated into rules or other automations, where the switch represents the LED being turned on or off. I will look at the possibility of adding this to RM.

Check this out:

So I can do triggers, but won't be able to do rules unless/until the Lutron Keypad driver gets updated.

This will be in the next release.

2 Likes

The feature to allow Keypad LEDs in Rule Machine has been added:

The functionality works. Thanks.

The rule version is more useful to me, I'd like to know if LED "is on".

My use case: I want to set lights based on mode only if the lights are on. The light levels are the Button Integrator night button and phantom day/evening button levels. I currently adequately approximate the condition by testing that all dimmer levels>threshold.