What you posted is a code w/o indentation.
My bad - Thanks!
Updated - still the same message No type provided
I guess you are pasting this code into UI yaml editor.
- type: custom:auto-entities
card:
should be just
type: custom:auto-entities
card:
uppps, my bad, i copied it from a horizontal-stack( or something) even more complex … didn’t think about that
Look at your own card !, as you are using auto-entities as the first Card, the code should look like your "Every Thing has to be moved in(to the left)
because you removed the - under include ( and i dont even know whether your ‘rolladen’ works as i don’t have such )
PS: Knowledge you get by compare and read the Docs of the specific Cards/Integrations
Card_params
options
Hardly anything right, so obviously your first code you posted, is copied somewhere from, and you don’t understand it, and you haven’t looked at the examples in the Docs, so you wont understand my code either
If this is your 1st experience with auto-entities - I would suggest you to test with a standard card first, not with a custom:shutter-card.
type: custom:auto-entities
card:
square: false
columns: 2
type: grid
card_param: cards
filter:
include:
- name: '*temp*'
options:
type: entity
This you can c/p, and build from there
Or this example:
and since I got only one entity named “Sun” - the grid only contains 1 card.
So:
- Test ONLY shutter-card w/o auto-entities.
- Test auto-entities with a standard card.
- Test auto-entities with the shutter-card.
I agree - I’ll consult the documentation more in detail and try to understand the correct syntax format.
For this special case I assume it is a limitation from shutter-card side. It seems that this card always need a direct entity. So, back to my first question, I see there s no possibility to hand the entity result(s) from the auto-entities to the shutter-card.
So for now it looks like there is now resolution.
I agree - I’ll consult the documentation more in detail and try to understand the correct syntax format.
For this special case I assume it is a limitation from shutter-card side. It seems that this card always need a direct entity. So, back to my first question, I see there s no possibility to hand the entity result(s) from the auto-entities to the shutter-card.
So for now it looks like there is now resolution.
My suspicions are confirmed with the final test (thank you for providing the example code!)
Comparison
type: custom:auto-entities
card:
square: false
columns: 2
type: grid
card_param: cards
filter:
include:
- name: '*te*'
options:
type: entity
works flawless =>
type: custom:auto-entities
card:
square: false
columns: 2
type: grid
card_param: cards
filter:
include:
- name: '*te*'
options:
type: custom:shutter-card
results in
Thanks again for your time!
this first
This !, Will check all your entities for “te” in the friendly_name(name), and result in a huge bunch of NON related
include:
- entity_id: 'sensor.*sun*'
Will only fill with “entities” matching the string ( and will only check sensor. , it does not check ALL entities for “te” in the name )
And ! as lldar mention , configure the card first ( So it works !)
You havent yet presented any code of a working Shutter-card, so it’s like shooting in the dark here.
So you “marked” ( What you need to do ! )
entities:
- this.entity_id
type: custom:auto-entities
card:
type: grid
card_param: cards
filter:
include:
- domain: cover
options:
type: custom:shutter-card
entities:
- entity: this.entity_id
or
type: custom:auto-entities
card:
type: custom:shutter-card
filter:
include:
- domain: cover
dependently on what you need.
ahh common!, let him suffer and read alittle , before you reveal it
We all need to learn & read docs ofc ))).
But some people - being great experts in some other areas - may not get things fast in programming, sad but true. This needs efforts.
Much appreciate!!!
This was the final hint!
Summary
entities:
- this.entity_id
Thanks again for all your help and patience!! Next time I’ll read the docs much more in detail before posting!
THANK YOU!!
Amazing community!
Will auto-tiles
be newly developed for lovelace sections(experimental)?
Yes you better, cause what’s possible in one card, most likely won’t work in another, so it’s important to read the “options/features” of the specific card ( in it’s github repos)
You’ll eventually find out which features/options you can combine, if not else, by trail and error