Open clau-bucur opened 5 months ago
Agree, a good idea, was thinking about same many times.
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.
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
.
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: @.***>
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.
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:
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:
And when I call it withoiut specifying a value for
history_entity
it will use the value specified for theentity
variable: