New widget type: double-button with visible state

Is your feature request related to a problem? Please describe.

I want to be able to do some actions very quickly:

• Turn a light on or off.
• Make a light dimmer or brighter.
• Change the volume of a media player
• etc.

The current way to do those actions is:

1. Open the Home Assistant app.
2. Wait for the splash screen to go away (the one with the white background; which kind hurts my eyes as everything else is dark on my device, but that’s a different issue).
3. Wait for the Lovelace webview to load.
4. Navigate to the input I need (either a different sidebar item, and/or a different tab, and/or scroll down to the card).
5. Finally, interact with the input.

Describe the solution you’d like

If you notice, most actions have a duality: turn on/off, change the volume up/down, dim the light darker/lighter, make the white balance colder/warmer, roll the blinds up/down…

Thus, I propose a new widget type that contains two buttons, and an optional visible state. Look at this ASCII Art mockup with a few examples (slightly broken because unicode/emoji characters are not the same width as other characters):

.-------.   .-------.   .-------.   .-----.
|   ⇧   |   |   ⏽   |   |   🔆   |   |  🔊  |
| Blind |   | Swtch |   |  Lamp |   | 42% |
|   ⇩   |   |   ⭘   |   |   🔅   |   |  🔉  |
'-------'   '-------'   '-------'   '-----'

The widget can have either two or three interactive areas:

• The top half (or top third) will call a service (e.g. light.turn_on).
• The bottom half (or bottom third) will call another service (bonus points for automatically suggesting the complementary service in the UI).
• The middle third can update the visible state upon touch. That way, the user can refresh the visible state manually (similar to the current template widget).
  • This state should be automatically updated a couple of seconds after the service was called if the other thirds were tapped.
  • If this state is static (i.e. a literal string), then the middle third could be ignored, and thus the interactive area could be changed to halves instead of thirds. This can be helpful if the user prefers a very compact-size widget.

Bonus idea: I know some widgets have scrolling support (e.g. the calendar widget from your phone calendar). Thus, it’s possible to detect up/down swipes in a widget. Then, instead of just tapping (which is a binary action), we could have some analog-ish interaction. The user could swipe up/down and then the amount of brightness/volume changed would be proportional to the length of the swipe. This could be implemented by repeatedly calling the up/down services for each “Y” amount of finger movement. In other words, it would behave similarly as an incremental encoder.

Describe alternatives you’ve considered, if any

My alternative, so far, is to have many widgets. Look at this screenshot:

And the same widgets, after I rotate my device to landscape orientation:

There are four button widgets, plus one template widget in the middle. Five widgets in total. Their paddings were removed (a feature of the Nova Launcher), and they were resized to the minimum “usable” size. There are many issues with my current solution:

• Too many widgets (4+1).
• Button widgets can’t have dynamic (template-based) label, forcing me to use a template widget.
• Template widgets can’t have any interaction, forcing me to use button widgets.
• Tapping on buttons doesn’t update the template; I have to remember to tap the template as well.
• Button widgets can’t have an empty label (i.e., if the label is an empty string, there is a wasted “empty” space reserved for the label).
• The label for up/down actions is duplicated (because button widgets must have a label).

Additional context

Somewhat related issues:

• #402 Feature Request: Show entity state in a widget, like a toggle switch
• #755 Add option to set attribute value as label for entity state widget
• #987 Editable widgets - as widgets get more complicated, we must be able to edit them.

Further refactoring idea

If we take a step back, this widget that I’m suggesting is a superset of the current widgets. Thus, we could imagine a future where we have only one very flexible widget type, and that type contains multiple pieces:

• If it contains only one “button” piece, then it emulates the current button widget.
• If it contains only one “template” piece, then it emulates the current template widget.
• If it contains a button piece, followed by a template piece, followed by another button piece; then it emulates the ASCII-Art mockup I described above.
• This also means we could have a 3-button widget: [volume up, mute, volume down] or [previous, play/pause, next] or [brighter, toggle, darker]
• This also means the user could have some arbitrary presets: set brightness to [100%, 75%, 50%, 25%, 1%]

So, this new flexible widget idea would be one widget to rule them all. Or almost. And I understand it takes quite some work to make it usable (specially building the UI, I know UIs are surprisingly time-consuming to build).

[KBerstene]

@denilsonsa Check out the PR I have open. The only thing I think I don’t have that you have suggested here is a 3-button widget, though I have already created a media player widget that would cover your previous/playpause/next use case.

[Mincka]

Thanks to the latest update with websockets support and instant status update, this kind of feature, or even more simple ideas like #402 would make even more sense. 😄