Hello, Is it possible to (re)name Lutron keypad buttons (and buttonLeds) in Hubitat?
Doing so would greatly help debugging in the Logs:
and on Device pages:
There isn't a Code on the Lutron Integration page to create a Button device:
We're working on a new driver specifically for the SeeTouch keypads where each button will be represented by a child switch device.
The parent will present all the button events, each child will control a specific load/led.
Which keypad are you using?
But to answer your question, with the Keypad driver it's not possible to rename the button values displayed in current states.
Great to hear that you're continuing to add capabilities for Lutron, thank you.
Shouldn't buttons be represented by a button device (not a switch)?
Virtual seeTouch.
the parent device has the button capability, the children are switches...
I means which actual Lutron keypad device is this
I have no physical keypads. I use virtual seeTouch keypads:
I don't understand what you mean by parent and child in this context. Assuming the parent device is the seeTouch. What are the child devices?
the child devices are a new type of child switch
I guess I don't quite understand either.
The only thing that Hubitat can even attempt to switch on a keypad is the LED. And that's only possible if there is no Lutron native programming on a button. There is no mapping between buttons and loads available for Hubitat to know from the Lutron system.
In any case, please remember to add the capability for the main repeater and its 100 buttons too.
Also, something more comprehensive, but would apply to making these changes to keypads. Would you consider parsing the main repeater XML (http://main repeater ip/DbXmlInfo.xml) as a starting point for device/button names? Home Assistant does it, so you can see the process in their code. I'd make it overridable but refreshable - there are some devices/buttons I have named differently in the 2 systems. I wouldn't put that too high on the list though, as it is mostly a 1 time operation to set up.
not true, i'm controlling from Hubitat a SeeTouch keypad button that's programmed in essentials to toggle output 4 of a RA2 visor control, this is being done via the new child switch device of the new SeeTouch driver.
If there's no essentials programming on the keypad button, the switch turns the led on and off, if there is then the switch fires the keypad event that's been programmed, and also turns the led on and off.
this is also in process, however this will lead to pretty much an entire re-write of the Integration app, call it v2...
Lutron buttons have no state and can do more than toggle. The LEDs do have state. Hubitat can't do anything more than virtually push keypad button X. Lutron is the system that knows how button X maps to output 4 and how to set the LED. There's no way for Hubitat to know that button X is controlling a switched output even by examining the state of the LED.
That's because Lutron has different programming modes for keypad buttons. Lighting has 3 different modes: 1) Single/Multi-Room Scene, 2) Toggle Control/Room Monitoring, and 3) Path of Light. They have different criteria for setting the LED. There's other modes for shades. See page 8/9:
In this case there's no need for Hubitat to try to control the LED as the main repeater will set it based on its programming. In fact, if there is a conflict, the main repeater will override the Hubitat setting within a couple seconds.
Right, point was you said Hubitat could only control the LED of any unprogrammed buttons...
and in fact it doesn't...
Hey, listen if you don't think there's value in what this new driver is about you won't have to use it...
and yeah, of course i already use the LIP documentation...
Come on, I'm genuinely trying to understand what you've written.
The Hubitat driver is pushing a button, not controlling a load. Hubitat has no idea what a button does if programmed via Lutron software. Hubitat can directly control an LED in a switch-like manner if there is no Lutron programming on it. Thus my questions.
You keep on saying switch. How do buttons become switches? Are they some sort of momentary switch? Or are just the LEDs a type of switch?
The way you've described the driver sounds to me more like a good candidate for a specialized case of a Button Controller app with some specialized LED handling added. I already use Button Controller apps with all my keypads. I only have a few buttons that don't have Lutron programming, and I control their LED status via RM rules.
Sorry to sound pedantic, but the different button programming modes are not part of the LIP document. They're documented in the Programming Examples and Templates document I linked and in the RadioRA 2 software.
they don't, the button events are handled by the parent device, the child switch represents the state of the led on the keypad, depending on the switch programming preference selected it can turn on off the led, or send a button event to the keypad for the associated button, in these cases the on/off commands simply act as a proxy for a button press command that could be generated by the parent.
I'm probably 30% through designing this thing, the goal of it was to enable hold/double taped events for a non programmed button and break out the led's as child devices, then figure out how to deal with and what can be done with buttons/leds that have Lutron programming...
Once I fully understand how the interactions with the keypad change depending on the Lutron programming being applied to it, I can probably do a better job of explaining how it works and what options will be available.
I appreciate you adding capabilities to Lutron Keypads - even if I don't yet fully understand how it will work. Also, I'm happy to test if you need assistance.
A couple of questions:
I don't believe a Lutron keypad button can be held or double tapped. Are you considering a software overlay to somehow add functionality?
What's the purpose of breaking out the LEDs as child devices?
Yes, we already do this to generate held for the picos.
It allows them to be treated just like all other switches in the schema, extending their availability within applications.
Mike,
Can you offer a quick Q2'23 update on this topic?
I too am interested in any facility to capture (or specify) Main Repeater Phantom Button for use in Hubitat. I gather the core issue is that phantom button names are exposed via Telnet.
You've mentioned work on a new SeeTouch driver and/or parsing the Main Repeater's XML.
- Did either pan out?
- Are there any places where some volunteer coding time would help?
the seetouch driver is complete and published.
As RA2 has reached end of life, no further work is planed on that project.
Thanks for the quick response.
Is there a URL to see/leverage the seetouch driver code?
I did not find a URL for the seetouch driver (e.g., at Hubitat Example Drivers).
My understanding is that a move to RA3 isn't advised until Lutron publishes an API and facilitates third-party integration.
What he meant is that the driver is built in to the hub:
Like most Hubitat drivers, it is closed-source (and this one in particular would probably not do much good without the rest of the integration).
1 Like
correct
for now you have Caséta with the pro bridge or RA2, select or standard
1 Like
