I’ve opened PR #21147 for the Lutron binding and would like feedback before it goes further, since it contains a deliberate breaking change.
What changes
Physical keypad buttons (seeTouch, Tabletop seeTouch, Pico, GRAFIK Eye, Palladiom, International seeTouch, VCRX, WCI) are currently modeled as Switch state channels with an autorelease workaround that immediately forces the state back to OFF after a press. The PR replaces these with trigger channels:
- PRESSED and RELEASED fire as the button is pressed and released.
- Buttons programmed for hold or double-tap in the Lutron software also fire LONG_PRESSED and DOUBLE_PRESSED (LIP actions 5, 6, and 32).
- Picos get a dedicated channel type advertising only PRESSED/RELEASED, since Pico hardware reports only press and release.
- The LEAP bridge maps RA3 LongHold/MultiTap events to the same trigger events.
- Virtual keypads are unchanged, they stay Switch-based because they’re bidirectional (openHAB sends ON to trigger Lutron scenes).
Why breaking instead of adding parallel channels
A momentary button press is an event, not a state, system.rawbutton-style trigger channels are how deconz, hue, and mqtt model the same hardware. Keeping the old Switch channels alongside trigger channels would roughly double the channel count on every keypad (a Pico would go from 5 channels to 10) and permanently document two ways to do the same thing, one of them conceptually broken. Channel ids are unchanged, so the migration for existing users is small and mechanical.
Migration for existing setups
- Items linked to button channels: add a system:rawbutton-* profile to the existing link (e.g. rawbutton-toggle-switch), or move rules to Channel “…:button1” triggered PRESSED.
- Sending ON to a physical button channel to simulate pressing that button is no longer supported, trigger channels don’t accept commands. On systems with integration (phantom) buttons, RadioRA 2 main repeater, HomeWorks processor, Caséta Smart Bridge scene buttons, the same Lutron programming can be invoked through the virtualkeypad Thing, but this requires assigning it to an integration button in the Lutron software; it is not a 1:1 substitute for simulating a specific physical button.
Things convert in place (channels are rebuilt on initialization, and thing-type update instructions are included), so no re-creation of Things or links is needed.
I’ve tested on a Caséta Smart Bridge Pro system (LIP/ipbridge) with Picos and dimmers: Things convert in place, events flow, dimmers unaffected. Interested in opinions on the breaking-change approach, particularly whether the loss of command-driven press simulation matters to anyone, and any RadioRA 2, HomeWorks QS, or RA3 (LEAP) users willing to test, especially the hold/double-tap events, which my Picos can’t produce.