What are the Button Integrators in the Lutron Integrator?
I see “Create New RA2 Button Integrator” and “Create New RA2 Button Integrator No Modes” but I’m unclear on what these are and when to use/not use them.
2 Likes
The Button Integrator app is used to create the level per mode lighting I described to you before, where phantom buttons of the main repeater are used, and are also tied to physical keypad buttons, including Pico buttons. There is also an Alexa virtual device created, and the app keeps all of the state information straight.
The no mode version of this simply ties a Pico button and a Keypad button together with Alexa for toggle use.
These Picos are not programmed in Ra2 to the device in question, but are general use Picos only controlling Hubitat automations. Other buttons of such a Pico might be doing other, non-Ra2 tasks, or are used to control several different Ra2 scenes. Hence the need for a glue app to tie everything together, and keep track of state.
1 Like
I decided to go with the full RA2 (as opposed to Select) for the keypad functionality (both native Lutron and Hubitat). Thanks for the general RA2 information that you provided to me in a different thread.
I've got the native Lutron programming down (even as I'm still a novice). And I can get Hubitat involved too. Example: I've used the Advanced Button Controller to add Hue bulbs to seeTouch buttons.
But I'm having a hard time understanding the Button Integrator. Starting with the first prompt to choose the main repeater. I get a choice of " Select Pushable Button" instead of a list of repeaters.
Can you please help me understand how to use the button integrator? I get the idea of changing button functions based on time of day. I just don't get how to translate that idea into the app(s).
Thanks
You need to add your main repeater to your Lutron Integration as a keypad. It has integration id 1. Then it will become available for selection in the app.
The way this app works is a bit tricky, and requires doing some special programming in your Lutron system. The general idea is that it can make the lights tied to a keypad button come on at different levels depending on the mode. To accomplish this, the lights associated with the desired keypad button should be programmed in the Lutron system for whatever setting you would want for Night mode (very dim, presumably). Next, you would have to program phantom buttons of the main repeater corresponding to that keypad button (same loads selected), for each of Evening and Day mode levels. The programming of those main repeater buttons will look pretty much identical to the programming for the keypad button, just with different levels.
Each of these main repeater buttons (make a guide for yourself with the buttons numbers for each mode), get entered into the Lutron Button Integrator app for the appropriate mode.
What happens is that when you hit the keypad button, Lutron starts to turn on the lights to night setting, but at the same time Hubitat catches the key press and responds by pushing the phantom main repeater button as appropriate for any mode other than night. The lights will continue their gradual ramp up in level to the desired level smoothly, as all of this is happening much faster than the ramp rate that Lutron uses (2 seconds, or whatever you set in the programming). The net result is that those keypad buttons now have light-level-per-mode instead of just a single level.
In my system, some of the loads in question (e.g. Kitchen) appeared in different button locations on different keypads. There were only two different keypad positions used throughout my system for any of the buttons I was interested in. So the app has the ability to recognize two different buttons. Some of mine were on as many as five keypads -- but a single one would do. All of those buttons for Kitchen on each keypad have to be programmed the same way, to the night setting. Lutron makes this fairly easy to do in the software. The app makes use of the keypad LEDs to keep things synched up, so these should be left in their standard configuration.
This is complex and subtle. But worth it when all is said and done. Happy to help you with specifics if you need it....
1 Like
Thanks, that helps. I'll try setting some up buttons to test after the holiday. A few follow-up items.
- Each instance of the button configurator can identically configure 2 physical keypad buttons and 1 Pico button, correct?
- A 6 button keypad could in theory take up 18 phantom buttons. If one has multiple keypads with unique scenes a substantial percentage of available phantom buttons could quickly be used up. So the reason to use Lutron phantom buttons rather than Hubitat rules is for Lutron functionality that is not available in Hubitat. Is that understanding correct?
- Re: Alexa: I would have thought that the virtual device for Alexa would map to a Lutron physical/phantom according to the modes in the button integrator app. But the functionality looks similar to creating a group of physical dimmers and then adding that group to the Alexa skill app. Am I reading this correctly?
- How is the "Allow for disable?" section used? It looks like creating a disable switch creates a virtual dimmer. I understand how a switch might be used, but not a dimmer.
Thanks again!
Actually, 2 keypad layouts with same button. For example in some of my keypads Kitchen is the top button, and in others the 3rd button. But it appears on several keypads. So all of those keypads are selected, and the correct button number selected for each set. Same issue with Picos --> which button is used for that load.
Yes, this is correct on all counts. However, you probably don't need this functionality for every key in your system. Obviously, there is some art involved in designing the assignment of keypad buttons. What I've found in general is that most keypad buttons don't get used much.
There are multiple ways to get Alexa into the act. If you want the kitchen, in my example, to come on to the various levels per the setup of the Button Integrator, then you'd use Button Integrator as the place to use the name "kitchen" for Alexa to know about.
IIRC, it's not a dimmer for any particular reason, probably the driver I had handy that day. This is for overrides that happen due to telling Alexa to do something. I'll have to research it a bit, as I haven't used it for a long time. It may be obsolete...
1 Like
I've got the app running nicely as expected, thanks for the guidance.
I have a couple comments/requests
-
The app is hard coded to Day/Evening/Night modes. Would it be possible to make the modes and mapping user configurable? Example: I want to add a Morning mode. Or I have changed the Night mode name to 'Late Night'.
-
This applies to more than Lutron keypads, but what is the best way to add a Lutron scene to a dashboard? I only see a multi-step path: that includes setting up Custom Commands for each button push along with Virtual Buttons/Switches and Rules.
I think I said this in another thread, but I'd like to see scenes added to base Hubitat functionality. The scene idea is in so many home automation products. There's a pretty good user app 'Scene Manager' by @jason0x43 that can probably add button presses, but I don't have the programming skills to do it.
My mistake - I don't need to add Custom Commands. I still do need a virtual button/switch and a rule, though.
You are right about the hard coding. I will take a look at making it more flexible.
You can add Main Repeater buttons (or any other keypad button) directly to a Dashboard. No need for custom commands, Rules or virtual devices.
Adding scenes is on our roadmap...
Thanks again. I'm adding a lot of non-Lutron actions to Lutron keypad buttons and it's working well.
My question of the day: Is it possible for Hubitat to set the keypad LED? I'd like the keypad button to light up when one of the phantom buttons is controlling the scene.
Another question, is there any Path of Light status support? I'd like to toggle some non-Lutron lights based on a Path button. It could be fairly easily implemented via a virtual switch if reading the LED next to the keypad button is possible.
It is possible to set the keypad LED.. For the basic Lutron Button Integrator app it is relying on the Lutron treatment of keypad LEDs for synchronization, so I'd have to dig in to how that all would be affected by setting a keypad LED. The first issue would be to expose the method for setting the LED in the keypad driver (it is not), and then address how one would access this from an app.
I will have to refresh my memory about Path of Light. No, at the moment there is not support implemented for it.
I suppose that both of these could be added to Rule Machine. The first would be a condition or trigger, Lutron LED (on or off), and the second would be an action, Set Lutron LED (on/off). I'll look into doing that.
Thanks.
I think it would make sense to add LED control into the Button Integrator app as every keypad has an associated light and it would be nice for it to come on whether a physical or phantom button is pushed.
Path of Light is a toggled scene. Push once → the scene is set and LED is turned on. Push again → all the scene lights are turned off as is the LED, but only if no lights in the scene have been changed. If any lights are changed after the first push, the toggle is reset to inactive and the LED is turned off.
Path is a special use case that is useful when turning off lights is part of the activity (going to bed or bathroom at night kinds of activities).
In RM the combination of pressing the keypad button and the LED going off would trigger non-Lutron Path off actions.
I don't follow. How would you select what LED should come on? And under what circumstances? I can see easily how to do this in Rule Machine, as sort of an accessory thing (when x happens, turn on LED --> x could be a particular button is pushed).
I'm game to extend these apps, once I grok what the extension is and how it should work.
In the Lutron system (no Hubitat) the LED next to the scene button is illuminated when the scene button is pressed. And that is the case in Hubitat too when in night mode. But non-night mode scenes go on to set a scene controlled by the phantom button, so the keypad light LED is off.
I'd like the LED to light up in modes that set scenes via phantom buttons.
According to the Lutron Integration manual, there is a command to set the LED state on a keypad, but it looks like that might only work for unprogrammed buttons. Which I guess would require Hubitat to use phantom buttons for all modes including night. See page 104 of http://www.lutron.com/TechnicalDocumentLibrary/040249.pdf
It makes sense that user control of LEDs would require unprogrammed buttons as the Lutron main repeater is monitoring the status of the lights. If you sets the lights manually and that setting matches a scene, the LED for that scene is turned on. So there could be contention with more than 1 system trying to control the LED.
So I understand that might make LED control a lower priority.
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!
-
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.
-
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.
-
The "Select dimmers for Alexa" doesn't seem to do anything?
-
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".
-
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.
-
(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!
-
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).
