custom-cards / decluttering-card

🧹 Declutter your lovelace configuration with the help of this card
MIT License
386 stars 30 forks source link

[FR] Fallback value of a variable to another variable #84

Open clau-bucur opened 5 months ago

clau-bucur commented 5 months ago

Describe the solution you'd like Is it possible to define the default value of a variable, as the value of another variable?

Someting like:

my_template:
  default:
    - history_entity: '[[entity]]'
  card:
    type: my_card
    entity: '[[entity]]'
    tap_action:
      action: fire-dom-event
      browser_mod:
        service: browser_mod.more_info
        data:
          entity: '[[history_entity]]'

And when I call it withoiut specifying a value for history_entity it will use the value specified for the entity variable:

- type: custom:decluttering-card
  template: my_template
  variables:
    - entity: sensor.my_entity
ildar170975 commented 5 months ago

Agree, a good idea, was thinking about same many times.

droans commented 4 months ago

Use a conditional card.

my_template:
  defaults:
    - history_entity: 'fake'
  card:
    type: vertical-stack
    cards:
      - type: conditional
        conditions:
          - condition: state
            entity: '[[ history_entity]]'
            state: "unavailable"
        card:
          - type: my_card
            entity: '[[entity]]'
            tap_action:
              action: fire-dom-event
              browser_mod:
                service: browser_mod.more_info
                data:
                  entity: '[[entity]]'
      - type: conditional
        conditions:
          - condition: state
            entity: '[[ history_entity]]'
            state_not: "unavailable"
        card:
          - type: my_card
            entity: '[[entity]]'
            tap_action:
              action: fire-dom-event
              browser_mod:
                service: browser_mod.more_info
                data:
                  entity: '[[history_entity]]'

A non-existent sensor will always return unavailable.

ildar170975 commented 4 months ago

A non-existent sensor will always return unavailable.

I would say this is a bug in HA frontend because a non-existing entity's state is unknown.

droans commented 4 months ago

Woops, sorry. I meant unknown, not unavailable.

On Fri, Jul 12, 2024, 4:30 PM ildar170975 @.***> wrote:

A non-existent sensor will always return unavailable.

I would say this is a bug in HA frontend because a non-existing entity's state is unknown.

— Reply to this email directly, view it on GitHub https://github.com/custom-cards/decluttering-card/issues/84#issuecomment-2226309736, or unsubscribe https://github.com/notifications/unsubscribe-auth/AL3LCMMQOXF7K2H76P5T2N3ZMA4FFAVCNFSM6AAAAABJ7TG5PCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEMRWGMYDSNZTGY . You are receiving this because you commented.Message ID: @.***>

clau-bucur commented 4 months ago

Use a conditional card.

my_template:
  defaults:
    - history_entity: 'fake'
  card:
    type: vertical-stack
    cards:
      - type: conditional
        conditions:
          - condition: state
            entity: '[[ history_entity]]'
            state: "unavailable"
        card:
          - type: my_card
            entity: '[[entity]]'
            tap_action:
              action: fire-dom-event
              browser_mod:
                service: browser_mod.more_info
                data:
                  entity: '[[entity]]'
      - type: conditional
        conditions:
          - condition: state
            entity: '[[ history_entity]]'
            state_not: "unavailable"
        card:
          - type: my_card
            entity: '[[entity]]'
            tap_action:
              action: fire-dom-event
              browser_mod:
                service: browser_mod.more_info
                data:
                  entity: '[[history_entity]]'

A non-existent sensor will always return unavailable.

Thanks for the suggestion, however that example is only a simple use-case where the request would be useful.

There are many more cases where the request comes handy. Even in your example, the same end-result is much cleaner and easier achieved by using variable fallback.

igorsantos07 commented 4 months ago

It is important to allow "templating" in the default values as well, so one could do as follows:

defaults:
  - entity: 'binary_sensor.[[area]]_presence'

This way, you could override the entity to be something else, or just go with the default based on the area name :sunglasses: