[RFC] Enhance Dimmer Things to Support Fade Start/Stop

Setup, Configuration and Use Items & Sitemaps
, ,
1

Overview

Dimmers, such as the Caseta and Maestro devices from Lutron, support the ability to be sent commands that mimic the behavior of a user pressing the fade up and fade down controls on the units and/or remotes.

The Lutron Integration Protocol achieves this through three commands:

  • Start Raising
  • Start Lowering
  • Stop Raising/Lowering

While individual dimmers can be configured to respond to a StopMoveType.STOP command, the present implementation in GroupItem.java will reject a STOP command sent to a group of Dimmers. (The IncreaseDecreaseType is already acceptable to a group.)

This RFC seeks to determine the appropriate approach and point(s) of implementation to enable this type of fade-start / fade-stop command.

Description of Issue

For the Lutron devices mentioned, three distinct commands are required:

  • Start Raising
  • Start Lowering
  • Stop Raising/Lowering

The Maestro dimmers also support a “Start Flashing” command which is canceled by setting the dimmer to a valid level. I do not know if there are dimmers from other manufacturers that have a similar function.

A typical application would be to bind the “Start Raising” command to the depress of the “up” button on the remote and the “Stop Raising/Lowering” command to the release of that button, and similarly for the “down” button.

The closest, existing “command type” that I could find to indicate the “Stop Raising/Lowering” command was that of the StopMoveType.STOP

A Dimmer does not check its own getAcceptedCommandTypes() implementation, so a single Dimmer can be commanded to STOP its fade. However, the implementation of Group does iterate over its members to ensure that all members of the group can accept the command, blocking the STOP command.

public class DimmerItem extends SwitchItem {

    private static List<Class<? extends State>> acceptedDataTypes = new ArrayList<Class<? extends State>>();
    private static List<Class<? extends Command>> acceptedCommandTypes = new ArrayList<Class<? extends Command>>();

    static {
        acceptedDataTypes.add(PercentType.class);
        acceptedDataTypes.add(OnOffType.class);
        acceptedDataTypes.add(UnDefType.class);

        acceptedCommandTypes.add(PercentType.class);
        acceptedCommandTypes.add(OnOffType.class);
        acceptedCommandTypes.add(IncreaseDecreaseType.class);
        acceptedCommandTypes.add(RefreshType.class);
    }

As a result, one cannot extend the commands accepted by the implementation of a Dimmer handler to accept other types without having a Thing that permits those commands as well.

Potential Implementation Approaches

Create “Local” LutronDimmer Thing and Reuse Existing StopMoveType

This approach would be the “minimal” approach and would not impact the smarthome code base. The Lutron binding would need to be extended to include a LutronDimmer Thing that would inherit from Dimmer and override acceptedCommandTypes

Advantages

  • Does not impact the smarthome code base

Disadvantages

  • Not generic for use with other dimmers that may have similar functionality
  • Overloads the meaning of the MOVE STOP commands

Create “Local” LutronDimmer Thing and Create New “Local” FadeStartStopType

Similar to the forgoing, but create a new command type with two (or more) commands

  • FADESTART
  • FADESTOP

and potentially a FLASHSTART and perhaps FLASHSTOP command as well.

Advantages

  • Does not impact the smarthome code base
  • Provides clear distinction between STOP and FADESTOP

Disadvantages

  • Not generic for use with other dimmers that may have similar functionality

Create “Generic” DimmerWithFade Thing and “Generic” FadeStartStopType

Similar to above, but perform the changes in the smarthome code base.

The DimmerWithFade Thing would inherit from Dimmer and override acceptedCommandTypes

Advantages

  • DimmerWithFade and FadeStartStopType would be available to all users without installing the Lutron binding.

Disadvantages

  • I would imagine that the sign-off process for the smarthome code base to be more time-consuming that that for the openHAB code base.

Discussion

The coding effort for any of these approaches is comparable. I do not know how much automated testing would be required for changes in the smarthome code base, nor the testing framework in use.

I’m open to any of the approaches, or one that I may not have thought of yet. I’m open to naming changes; what you see above is just a first-stab at describing the problem and approach.

I don’t know the preferences of the openHAB architects. Perhaps @Kai can comment at some time on this.

Apologies for the apparent missing spaces around Preformatted text in certain places.

Lutron, Caseta, Maestro, and Pico are registered trademarks of Lutron Electronics Co., Inc