This is the approach I took too, multiple cards with various entities with a conditional type.
Well, in pre-Lovelace world it was easy, wasn’t it?
Would monster-card work? Not sure if you can use the state of one entity to filter the visibility of another inside monster-card. I’ve never tried.
If not, you might create an automation on the switch to set an attribute on input_number. Then use that attribute inside the filter of monster-card. A small hack.
- type: custom:monster-card show_empty: false card: type: entities title: Lights On filter: include: - entity_id: switch.bathroom_extractor_fan - entity_id: automation.climate_turn_bathroom_extractor_fan_on_based_on_humdity_threshold - entity_id: input_number.climate_shower_threshold_humidity_value attributes: custom_value: 1
You would just need to have the automation.climate_turn_bathroom_extractor_fan_on_based_on_humdity_threshold also set “custom_value” (or whatever you want to call it) on input_number.climate_shower_threshold_humidity_value when it toggles
Rinse and repeat for the others
Well, thanks for the suggestion. I’ve just installed monster-card and haven’t played with it yet, but form reading docs I got that it’s just a better filter card.
Could you show me how exactly to do this
as I’ve never done that before?
I haven’t either, but I found this:
So, maybe inside your automation, when you are calling the turn_on service, add in the name of the attribute you want.
But, the more I read, the more I think my hack idea won’t work:
So, in order for monster-card to do what you need, you might want to add a feature request monster-card to have it look at a different entity.
I might play around with it and see how hard it would be to add that feature and submit a pull request, but I have no idea when I can get around to it.
Ok, here is a hacked monster-card. See if it’ll work. If so, I’ll see about contacting the author about getting it “official”.
You’ll need to add it like (adjust path to match your location)
resources: - url: /local/my-monster-card.js?v=0.0.1 type: js
Then refer to it in lovelace like: (note the name is “my-monster-card”)
- type: custom:my-monster-card show_empty: false card: type: entities title: Test show_header_toggle: false filter: include: - entity_id: input_boolean.alarm_mode - entity_id: input_boolean.vacation_mode - entity_id: light.back_door_lights when: - entity_id: input_boolean.alarm_mode state: 'on'
In this example, light.back_door_lights will only be visible when input_boolean.alarm_mode is “on”
Hopefully I didn’t just re-create existing functionality somewhere. In theory, you could add multiple entities. It would require all of them to be true.
filter: include: - entity_id: domain.entity when: - entity_id: domain.parent_entity state: (optional) attributes: (optional) key: '< 10'
Edit: FYI, this received about 30 seconds of testing along the happy path. Your mileage may vary.
wow, thanks a lot for such an effort!
However, I cannot get Lovelace to accept the card. It works without that
when part, and when I add it, Lovelace complains:
YAML Error: YAMLException: bad indentation of a sequence entry at line 10, column 10: state: ‘on’ ^
do you know how to fix that? I definitely use my-custom-card
Make sure the s in state is directly under the e in entity_id and the w in when is directly under the e in entity_id That was a copy/paste from my setup that I used to test it.
Also, you used
type: custom:my-monster-card correct?
Ok, managed to make it work. The code was right, but the YAML is very naughty, I used ‘live’ mode rather than Raw editor, and it seems like at some point it’s stuck and the only way to make it rescan input was to copy code, click Cancel, create a manual card and paste code back.
It works for one entity, yet to extend it to the whole card.
By the way, I used Lovelace’s feature to assign name to an automation:
- entity: automation.climate_turn_bathroom_extractor_fan_on_based_on_humdity_threshold name: auto ON by humidity value
but I cannot do that using monster card, can I? So the alternative is to customise my automations’ friendly names, right?
Yeah, I do all my lovelace stuff in yaml file mode.
options: option. I think this should work untested:
- type: custom:my-monster-card show_empty: false card: type: entities title: Test show_header_toggle: false filter: include: - entity_id: input_boolean.alarm_mode options: name: A different name - entity_id: input_boolean.vacation_mode - entity_id: light.back_door_lights when: - entity_id: input_boolean.alarm_mode state: 'on'
it works (as described in docs, just didn’t understand what configuration options they mean), tested! thanks a lot again.
will try to reproduce my initial 9-card effort with this great card
do you know if it’s possible to create a complex
when condition with this card?
for example, if automation1 or automation1 and automation2 are both enabled, I want to show entity1, if only automation2 is enabled, it should be entity2, and with both automations enabled there should be no extra entities. is it too much?
type: 'custom:my-monster-card' card: type: entities title: Ventilation show_header_toggle: false filter: include: - entity_id: switch.bathroom_extractor_fan - entity_id: automation.climate_turn_bathroom_extractor_fan_on_based_on_humdity_threshold options: name: auto ON by humidity value - entity_id: input_number.climate_shower_threshold_humidity_value when: - entity_id: automation.climate_turn_bathroom_extractor_fan_on_based_on_humdity_threshold state: 'on' - entity_id: automation.climate_turn_bathroom_extractor_fan_on_based_on_humdity_gradient options: name: auto ON by humidity gradient - entity_id: input_number.climate_shower_humidity_gradient_threshold when: - entity_id: automation.climate_turn_bathroom_extractor_fan_on_based_on_humdity_gradient state: 'on' - entity_id: automation.climate_turn_bathroom_extractor_fan_off_based_on_target_humidity options: name: auto OFF by humidity value - entity_id: input_number.climate_shower_default_target_humidity_value options: name: if less than when: - entity_id: automation.climate_turn_bathroom_extractor_fan_off_based_on_target_humidity state: 'on' - entity_id: automation.climate_turn_bathroom_extractor_fan_on_based_on_humdity_gradient state: 'off' - entity_id: input_number.climate_shower_target_humidity_value when: - entity_id: automation.climate_turn_bathroom_extractor_fan_on_based_on_humdity_gradient state: 'on' - entity_id: automation.climate_turn_bathroom_extractor_fan_off_based_on_target_humidity state: 'on' - entity_id: input_number.climate_shower_target_humidity_value_correction when: - entity_id: automation.climate_turn_bathroom_extractor_fan_on_based_on_humdity_gradient state: 'on' - entity_id: automation.climate_turn_bathroom_extractor_fan_off_based_on_target_humidity state: 'on' - entity_id: automation.climate_turn_bathroom_extractor_fan_back_on_if_turned_off_before_target_humidity_reached options: name: prevent manual off if target not met when: - entity_id: automation.climate_turn_bathroom_extractor_fan_off_based_on_target_humidity state: 'on'
Thanks a million, you made my day!
I’m glad I could be of help. Of course, it wouldn’t be possible without the original monster-card’s author! Thanks @ciotlosm!
Just remember, this now a loosely supported one-off card. I won’t be able to implement changes as quickly as needed as the original author of monster-card.
I’ll put in a pull request later this week to try and get these changes, or a variation, added. Keep in mind, if implemented, it might be a little different. I can almost guarantee the word “when” will be changed to something different, probably “depends_on” or something that is more descriptive.
Experimentally I’ve found out that
when can accept more than one condition (as in my code, states of 2 different entities) and performs logical AND to decide whether to display the entity or not.
Is it only
state that can be used as condition in
when, and is there any way to combine multiple conditions by logical OR, for example?
You can also, should be able to, use attributes as part of the
when. Check out the monster-card documentation. Ignore
when inside its documentation, that is different (and one of the reasons why I will rename it). See the example about battery < 25.
No, there is not a logical OR grouping. Depending on how complicated you want, that can get messy with grouping and stuff. If you really need that, I would suggest creating a template sensor based with all that, hide that template sensor, and use it inside the
I looked at the monster-card documentation, but had a feeling that only when: state is supported.
That’s probably why you said it’s not the right tag and I should check filter options.
The idea with a binary sensor is great, it took me good 30 seconds to get it. Yes, it’s not ideal (but there is no need to hide that afaik as it’s not added anywhere automatically, right?) and might get out of hands, but it’s an interesting way of overcoming limitations
Just an hour ago I spent some time on how to turn on or off a input_boolean in action based on a sensor that might be on, off, unknown or unavailable
It was just a template condition accepting only on or off states and then service_template… easy it looks now
Does this “my-monster-card” still work? I have am trying to implement it but keep getting "cannot read property ‘include’ of undefined
It works with 0.96.
Are you still planning on integrating this into the original monster card? This feature would be really great.
it’s better to ask the owner of the original monster card I presume…