feat(spinner): Display a configurable spinning wheel (eg. while a script is running)

[RomRider]

- type: 'custom:button-card'
  entity: script.delay_script
  name: Spinner script main
  tap_action:
    action: perform-action
    perform_action: script.delay_script
  show_label: state
  spinner: '[[[ return entity.state === "on" ]]]'

- type: 'custom:button-card'
  entity: script.delay_script
  name: Spinner script state
  tap_action:
    action: perform-action
    perform_action: script.delay_script
  show_label: state
  styles:
    spinner:
      - pointer-events: none !important # unlocks the interaction with the card
      - --button-card-spinner-background-color: none # removes the partially opaque overlay
  state:
    - value: 'on'
      spinner: true
      styles:
        spinner:
          - --button-card-spinner-color: red # make the spinner red

[github-actions]

🎉 This PR is included in version 5.1.0-dev.3 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀

[il77781]

@RomRider, do I understand correctly that the spinner will be displayed in any case, for example, when performing multi-actions (apparently with a set delay), even if spinner: false is set?

[RomRider]

Correct

[RomRider]

If that's something which bothers you, please open a feature request with your request :-)

[Mariusthvdb]

found an issue here, maybe user error, but still

using a template

button_ha_modes:
  template: button_picture_script
  tap_action:
    action: perform-action
    perform_action: input_select.select_option
    target:
      entity_id: input_select.mode
    data:
      option: >
        [[[ return variables.mode; ]]]
  state:
    - operator: template
      value: >
        [[[ return states['input_select.mode'].state === variables.mode; ]]]
      color: var(--background-color-on)
    - operator: default
      color: var(--background-color-off)
      styles:
        entity_picture:
          - filter: grayscale()

which in itself uses another template:

button_picture_script:
  ...
  ...
  spinner: '[[[ return states[variables.perform].state === "on" ]]]'

so, requires a var perform.

now, the button_ha_modes button dont have that, so show:

seems fine up to now.
next, I try to fix that by setting

spinner: none in the button_ha_modes template to override that, and hope not to see any spinner logic result. However, this is what is displayed

shouldnt spinner: none be leading in this case? Or, should I load that at the highest button-card, namely the config. That would be a pity, as these all use the same template, so I had hoped to add it there:

  - type: grid
    columns: 4
    cards:

      - type: custom:button-card
        template: button_ha_modes
        tooltip: Regulier
        entity_picture: /local/home-assistant/picture.png
        variables:
          mode: Regulier

      - type: custom:button-card
        template: button_ha_modes
        tooltip: Kiosk
        entity_picture: /local/modes/kiosk.png
        variables:
          mode: Kiosk

      - type: custom:button-card
        template: button_ha_modes
        tooltip: Full house
        entity_picture: /local/modes/full_house.png
        variables:
          mode: Full house

      - type: custom:button-card
        template: button_ha_modes
        tooltip: Developer
        entity_picture: /local/modes/developer.png
        variables:
          mode: Developer

[RomRider]

spinner is a boolean. None is not a valid configuration. true or false only. none is a string and a non empty string is equal to true in javascript.

[Mariusthvdb]

right, sorry for that...

can confirm that to override correctly.....

shouldnt my wrong config error somewhere?

[Mariusthvdb]

styles:
spinner:
- pointer-events: none !important # unlocks the interaction with the card

fwiw, that !important shouldnt be there. it's probably a remnant of a true css modification, inside the card config this suffices

      - type: custom:button-card
        template: button_picture
        tooltip: Party
        entity: input_boolean.home_mode_party
        variables:
          feest: >
            [[[return entity.state === 'on'; ]]]
        entity_picture: /local/modes/party.png
        spinner: >
          [[[ return variables.feest; ]]]
        styles:
          card:
            - background: >
               [[[ var rgb = states['light.home_theater'].attributes.rgb_color;
                   return rgb && variables.feest
                   ? 'rgb(' + rgb + ')' : 'var(--background-color-off)'; ]]]
          spinner:
            - pointer-events: none # unlocks the interaction with the card
            - --button-card-spinner-background-color: none # removes the partially opaque overlay

[RomRider]

It's not necessary, you're right. But it doesn't change anything if it's there 😄

[Mariusthvdb]

it can be hard to see it spin on colorful backgrounds. it moves a bit, but the actual spinner is not visible:

like on a plain card:

as a matter of fact, it wasnt there at all, because of

color_type: card

commenting that makes the spinner spin like crazy ;-)

might want to make a note for that in the docs

[RomRider]

That's an issue, please open a bug. It should work with color_type: card too

[il77781]

If that's something which bothers you, please open a feature request with your request :-)

I can't say that I'm bothered by this... I just don't know if it's a bug or a feature... Perhaps it's just the way it should be... Therefore, given that some members of the community are highly triggered by my questions, I'm a bit wary of opening new entities...
However, in my specific case, I encountered the following: after tapping the button, the spinner is displayed for a time that is even shorter than the time specified in the delay parameter (between actions). Consequently, the time for "locking" the button from subsequent taps is also reduced, and the actions specified after the delay parameter are not executed at all... It feels like the multi-actions are interrupted or "reset"... At the same time, of course, it is necessary to say that I do not switch the page on which the button-card is located, nor do I do any other actions...
As far as I was able to investigate, this happens for nested button-cards if some parameters of the elements of these nested cards (for example, in styles) contain javascript templates that are enclosed in the "wrong" (not corresponding to the nesting level of the button-card) number of square brackets (for example, [[[ ]]] instead of [[[[ ]]]]).
And if the specified delay time between actions is longer than the sensor (which is specified in the JavaScript template in the nested card) update interval, the spinner (and the "blocking" of the card from being tapped) is displayed until the state (or attribute value) of the sensor is updated. At this point, the nested button-card is probably "recalculated" and the multi-actions are reset - actions (after a delay) are not executed...
To be honest, I don't know if there's any way to do something about it... Or if there's even a need to do anything... Maybe, at the very least, it should be specified in the documentation that the number of square brackets for JavaScript templates in the nested cards must be strictly followed, at least when multi-actions are used...
At the same time, of course, I want to say that the "mismatch" in the number of square brackets with the level of nesting of the card works without any problems in all other cases... In my specific case, I used triple square brackets (instead of [[[[ ]]]]) for javascript templates in nested cards to access variables defined in the main ("parent") button-card (as far as I understand, there is currently no other way to do this)...
In addition, it should be noted that using
1.action: javascript with the corresponding sequence of actions in the form of javascript (here, too, the number of square brackets must match the level of nesting of the card)
or
2.action: call-service with service: browser_mod.sequence
when using the "incorrect" number of square brackets in JavaScript templates on nested cards does not result in the "reset" of actions after a delay. All actions specified in the sequence are performed with the correct delays, but there are also some drawbacks: in this case, there is no spinner or "locking" of buttons from subsequent taps during the execution of the sequence of actions.

[RomRider]

Please stop commenting on a closed PR, open new issues and share a minimal config example. Those 2 points are valid, either doc update or bug fix.

[il77781]

Okay, whatever you say... It's like there's no bug here (it can be interpreted as normal behavior), and the documentation can be read in different ways... So, it's like there's nothing to open... I'm sorry for the time you've wasted. With deep respect for you!

[RomRider]

That's not what I'm saying 😅 I'm saying those are valid points and should be opened as issues so that we can deal with them accordingly (either by making the documentation better or by finding a way to avoid the situation)