Motion lighting: bug report/RFE in wording

In Motion Lighting, there's inconsistency between the names of options within the app and how the options are shown after they are selected.

Specifically, in the menu "Options for Turn-on, Disable, and Enable Lights-On", there is an option described as "Enable override with dimmer level change?".

If that option is selected, the completed rule shows two new lines:
Override for automation suspend
Override with any level change

This has several potential points of confusion:

  1. Changing a single option when configuring the rule enables multiple logical conditions in the resulting rule
  2. There is no way to enable/disable each logical statement individually
  3. There is no option within the rule that directly corresponds to the condition "Override for automation suspend"

The expected behavior would be that selecting the option "Enable override with dimmer level change?" would be displayed as just "Override with any level change" in the completed rule, or that there's a separate configuration within the rule menu to allow the user to select "Override for automation suspend" (whatever that means).

The request for enhancement is to keep the wording consistent between the menus used to create a Motion Lighting rule and how the rule is displayed when complete.

1 Like

I also noticed this while working on some rules over the weekend. I did the work on my laptop and the options were displayed all over the place. To me it looked like a hot mess. It actually looks much better on my phone but I hate doing a lot of work on such a small screen.

I noticed the inconsistent wording too.

The wording of the legends will be clarified in the next release. But, what is the "bug report"?

When "Enable override with dimmer level change" is selected, more options are presented. The first option selects between an override that completely suspends the actions of the automation, or one that simply changes the level for the duration of when the lights are on. The complete suspension of the automation means that the lights will stay on until manually turned off, which resets the automation. The second option determines whether the level change override happens only with physical changes of the dimmers, or happens with both digital and physical dimmer level changes (for example, a Dashboard changing the dimmer level).

In all there are 4 cases of Override, shown with two legends:

  1. Change the level and retain the changed level for the duration of the lights-on period, from physical dimmer changes.
  2. Change the level and suspend the automation until turned off, from physical dimmer changes.
  3. Same as 1 but for both digital and physical dimmer changes.
  4. Same as 2 but for both digital and physical dimmer changes.
1 Like

If selecting "Enable override with dimmer level change" was only intended to create a single logical condition, then my posting would have been a bug report. If it was meant to introduce multiple conditions in the rule, then it was an RFE.

Showing two legends in response to choosing a single option is, um, a confusing representation, particularly when one legend doesn't correspond to the wording within the menu or documentation.

Clarified wording will be welcome.

For me, a hierarchical display of the options (and corresponding legends) would clarify the rule, perhaps something like the following in the application menu:

[ ] Will a dimmer level change override the automation?
    [ ] override dimmer level only, but still turn off based on the rule
    [ ] use physical dimmer change only (default is physical or digital)

with the logic displayed in the legend as one of the following statements:

  1. Any dimmer level change will override the automation of rule
  2. Any dimmer level change will override the automation of the dimmer level only, but the rule will still turn off the switch[es]
  3. A physical dimmer level change will override the automation of rule
  4. A physical dimmer level change will override the automation of the dimmer level only, but the rule will still turn off the switch[es]

Hindsight offers a better vantage point than a design that came about incrementally based on user feedback and requests. Not too interested in revisiting it at this point given backwards compatibility constraints. Changing it is possible, and would entail a new child version, as has been done with other apps as needed.

1 Like

I have no idea what changing the layout of the Mode Lighting app menus would entail, but from an end-user point of view, improving the design & wording is probably better than documentation.

As I'd tell the developers on my team at $WORK, you can improve the interface or write documentation to explain something that's not intuitive....and no one ever reads the documentation until they're having a problem and are already confused or frustrated, and even then they won't read it thoroughly or closely.

Your code, your customers, your choice.

1 Like

As far as I can recall, you're the only person to ever raise concerns about it.

There are other priorities for my limited time and choices.

1 Like