you can try mine, Ive updated it yesterday to use @thomasloven 's new hui-element custom-card, so you can use an entities card as main card, and be done with the stack-in-card or vertical-stack-in-card custom cards, which all have their specific needs.
didnt notice it when I posted above, but now that I did:
because of the change to the entities card listing entities, among these the horizontal stack with picture entities, the formatting went off… If you look closely you see the right picture to be larger than the other 2, the middle being smallest.
Ive tried to take out the style formatting for the 3 picture elements, and bring that 1 level up to the horizontal stack, but that doesnt work.
what does work (almost) is changing the styling to:
left image: margin: 0px 0px 0px -16px;
middle: margin: 0px -8px 0px -8px;
right image: margin: 0px -16px 0px 0px;
but even with that, there s a tiny scratch of separation visible, which I find very annoying. Especially since that wasnt the case before, so I’ll return to the previous setup.
second thing I noticed: my afvalwijzer apparently stopped ending plastic, but now does pbd… no issue of course, but just explaining why the above image shows an mdi icon (and ‘none’ ) instead of the nice button image…
nice plugin! i’am new to Home Assistant…Is it possible to add two addresses? I created a second trash.yaml (inside /packages)
changed all sensor.trash_xxx to sensor.trash_xxx_2 but that unfortunately doesnt work.
no idea, without the full section. Note I described why I stopped the entities card using custom:ui-element cards for this setup. Couldn’t get the style for the images correct.
rephrase: If today has a pickup, the group of next pickups, should begin with the pickup following today’s pickup, and not include it. There’s no way I can get it to do that unfortunately. Or is there. I could maybe exclude it from the Lovelace config…? not sure if there are 4 sensors available though in the case of a pickup on the current day…
we probably cant do it with the attribute next_pickup_in_days, but we could do it if we had the full list of pickup days, which Saver provides, but the integration doesn’t yet import.
@xirixiz would that be a FR you could allow? so we have more than the first 4 next dates created by the integration?
Of course, if the integration would import more than the first 4 dates, it could also calculate the next_pickup_in_days attribute for those. And then we could again use it in the auto-entities
Correct the only thing now possible is to really exclude the “todays pickup type”
Meaning you would only see 2 type in the next pick up days part.
Edit:
Alho we do have trash_first_next_date and sensor.trash_first_next_item
But that would be really hard putting it altogether in the auto sorting part
and no, that isnt really an option since it would have to be conditional for having a todays’ pickup. And would require yet again an extra binary_sensor on which we could do that. Even so, if we had it, we wouldn’t have the next 4 dates for the various trash-types.
@Mariusthvdb
With the help of a friend i got it finally the way i like it.
There are only 2 sensors that i cannot get working.
First 1 is: sensor.trash_next_icon
I think i should be using this for it but when i add it to sensors it gives me errors (invalid slug) and adding it to customize.yaml doesn’t do anything.
sensor.trash_next:
friendly_name: Days to next pickup
templates:
icon: >
if (state === ‘Geen’) return ‘mdi:calendar-question’;
if (state === ‘0’ || state === ‘1’ || state === ‘2’ || state === ‘3’ || state === ‘4’
|| state === ‘5’ || state === ‘6’ || state === ‘7’ || state === ‘8’ || state === ‘9’)
return ‘mdi:numeric-’ + state + ‘-box-multiple-outline’;
return ‘mdi:numeric-9-plus-box-multiple-outline’;
And the second missing sensor is: sensor.trash_color
I found some old post (“markdown-card-with-template-wont-format-correctly”) but cannot figure out how to fit this in my setup.
dont know what your setup looks like, so not sure where you need help.
both sensors you mention above are standalone, and not parts of the template sensor you quote. Ive also added the trash_next_color, to use that in the markdown (and custom-header tab icon )
trash_next_icon:
value_template: >
{% set days = states('sensor.saver_trash_first_next_in_days') %}
{% if days != 'Geen' %}
{% if days <= '9'%} mdi:numeric-{{days}}-box-multiple-outline
{% else %} mdi:numeric-9-plus-box-multiple-outline
{% endif%}
{% else %} mdi:checkbox-blank-outline
{% endif %}
trash_next_color:
value_template: >
{% set next = states('sensor.saver_trash_first_next_item') %}
{% set mapper = {'papier':'#00b2ef',
'gft':'green',
'pbd':'orange',
'restafval':'black'} %}
{% set color = mapper[next] if next in mapper else 'grey' %}
{{color}}
trash_color:
value_template: >
{% set vandaag = states('sensor.saver_trash_today') %}
{% set mapper = {'papier':'#00b2ef',
'gft':'green',
'pbd':'orange',
'restafval':'black'} %}
{% set color = mapper[vandaag] if vandaag in mapper else 'grey' %}
{{color}}
Note I have prefixed all my senors with saver_ so if you dont use that, take it out of the templates.
sure, but that would be useful for changing the icon of another sensor to show in the frontend. You can see here how to do that.
My sensor above is a template sensor with a value_template for the icon. This sensor isn’t used in the frontend itself, it is used in the markdown card to show an icon here:
I do that in places where the config of the markdown card, or other style sections would become to complicated and error prone, let alone difficult to read. using the state of this sensor is hassle free.
update
to illustrate what is happening even better, please see below. We have a pickup today: Papier.
the next_pickup_in_days shows todays pickup ( 0 days) ,
