thomasloven / lovelace-auto-entities

🔹Automatically populate the entities-list of lovelace cards
MIT License
1.18k stars 111 forks source link

FR: bulk rename option #166

Open RoboMagus opened 3 years ago

RoboMagus commented 3 years ago

It would be a great addition to have some sort of a bulk rename option added to the auto-entities, similar to what's been done in 'maxwroc/battery-state-card'.

I tend to group entities of the same device together, but Its a waste of space to have the name of the device repeated on every row. Being able to replace parts of entity names as a bulk renaming would cleanup such groupings a lot.

bcutter commented 3 years ago

EXACTLY what I was thinking right now! That feature would be awesome.

Example: (the black part would be the text I need, everything else before shall be removed)

grafik

See the bulk_rename option I use a lot as an inspiration @thomasloven :-) : https://github.com/maxwroc/battery-state-card#card-config

For my example a simple

bulk_rename:
  - from: 'Switch-Control_Switch '
    to: ''

would do the trick.

edenhaus commented 3 years ago

A workaround can be found in https://github.com/thomasloven/lovelace-auto-entities/issues/110#issuecomment-647013848

But this workaround is only working for cards like entities, but not for cards like history-graph. I think the best would be to support templates for all options similar to lovelace-template-entity-row. @thomasloven What do you think about this idea?

RoboMagus commented 3 years ago

Thanks for pointing me to that workaround @edenhaus! It might not be a perfect solution but it would already improve about 80% of my use cases.

bcutter commented 3 years ago

Nice workaround, would still love to see this as a config option!

genebean commented 3 years ago

+1 to the renaming from https://github.com/maxwroc/battery-state-card#card-config

coom commented 2 years ago

Hi, +1 for the renaming option, as the workaround breaks some things like the unit, as you can see in this screenshot :

image

Would be really nice if we can just add something like : name: replace('battery', '') | replace ('Motion', '')

So we can remove the useless par of the entity friendly name.

bcutter commented 2 years ago

I can only add the big need once again: huge parts of my UI are filled with unnecessary text which is annoying especially on smaller screen devices.

Replacing strings would therefore be a perfect solution and totally awesome.

As other frontend integrations already use/offer this (code is on GitHub!), it can only be a "A small step for us developers, but a big step for the whole community" thing to integrate it here 😄

chasebolt commented 2 years ago

+1

bcutter commented 2 years ago

Unfortunately still no reaction, only more "I want/need that too" signs.

How can we support the maintainer(s) so he/they are able to add this feature?

Weissnix4711 commented 2 years ago

+1 for templates. Not just for renaming, but it would open up a lot of other opportunities.

The workaround in #110 using custom:template-entity-row only works for the entities card.

I would like to set this up with mini-graph-card, but cannot. I have tried to add templating by using config-template-card, however the template is evaluated before this.entity_id is converted into the actual entity id. You would think the following would work:

type: custom:config-template-card
variables:
  fix_name: |
    entity_id => {
      return states[entity_id].attributes.pair;
    }
card:
  type: custom:auto-entities
  filter:
    include:
      - entity_id: sensor.bitfetch_.*busd
        options:
          name: ${fix_name('this.entity_id')}
  sort:
    method: state
    reverse: true
    numeric: true
  card:
    type: custom:mini-graph-card
entities:
  - idkwhattoputhere

But it does not. The string 'this.entity_id' is passed to the function instead of the actual entity id. Hence, it fails to find an entity with that name.

I have no other ideas. The only way I see for this to work is for auto-entities to add templating, or for mini-graph-card, and any other custom cards to do so.

bcutter commented 2 years ago

...or to just have a look how Battery State Card implemented this, maybe it can be adopted. I actually think it's a easy thing for Thomas.

https://github.com/maxwroc/battery-state-card#entity-filtering-and-bulk-renaming

RoboMagus commented 2 years ago

@thomasloven, would you reconsider a PR such as #103?

Though I have been using the workaround mentioned in this comment:

A workaround can be found in #110 (comment)

But this workaround is only working for cards like entities, but not for cards like history-graph. I think the best would be to support templates for all options similar to lovelace-template-entity-row. @thomasloven What do you think about this idea?

There are uses where other cards than template-entity-row have to be used, e.g. when using graphs. For those uses there is still very much a use-case for bulk renaming entities that are provided to the underlying cards, which can only realistically be done (from my point of view) from within the auto entities scope.

bcutter commented 1 year ago

Can we please have the information what is needed to finally implement this feature after almost 2 years of waiting?!?

Would e. g. some donation motivate one to add it?

There was already information given how other implement such feature. For a pro dev it should be a 15 minutes finger exercise...

ildar170975 commented 1 year ago

@bcutter Developing HA & plugins is a voluntary job. People are doing it in their spare time. No one have a right to urge. And everyone may become a developer within 2 years if he desire it so much & implement all needed features by himself.

bcutter commented 1 year ago

Partly agree with you. Time alone doesn't transform users (like me) to developers. Using tools is sometimes difficult enough, building them is a whole other story.

In https://github.com/thomasloven/lovelace-auto-entities/issues/166#issuecomment-934517692 I referenced another frontent integration which does exactly what this FR from @RoboMagus is about. Honestly, looking at the source of that project and even trying to find the code which does the bulk_rename is beyond my capabilities. Not to speak of how to integrate it into lovelace-auto-entities.

I was just wondering and asking and even a donation seems to be no motivation, can't imagine why else the 👎 came from.

Let's face the facts: almost two years and possible solution (implementation example, mentioned above again) for developers lies before us, at least 13 others (users, too?) voted up 👍 for this FR.

Hopefully someone capable of implementing this feature will catch up on this, probably Thomas himself, who knows.

ildar170975 commented 1 year ago

Time alone doesn't transform users (like me) to developers. Using tools is sometimes difficult enough, building them is a whole other story.

Agree. Even me - a dev since 1996 - started to change some Lovelace card and failed ))) Never used before these py, ts, js and others "yes, this is a language too", need to learn...

even a donation seems to be no motivation

Probably depends on a size of a donation )))). How can we measure a person's time in Euros?

at least 13 others (users, too?) voted up

Sometimes it does not matter. See, there is a "template" option - a universal way to implement almost anything. Now 333 persons are asking about a new small option to get a result - which may be achieved by this universal "template" option. Later another 333 persons will ask for another small option to get another result - which currently is also may be achieved by this "template" option. This is infinite.

bcutter commented 1 year ago

Using template stuff is what I tried many times and even I got close a) I never got close enough (meaning not having visual side effects or not running into limitations) b) the level of complexity added to auto-entities is just mind blowing.

My latest status is at https://github.com/thomasloven/lovelace-auto-entities/issues/110#issuecomment-1221438175, this is where I gave up.

So having to use

          options:
            secondary: >
              {{ state_attr(config.entity, 'last_triggered') | relative_time }}
            type: custom:template-entity-row
            name: >
              {{ state_attr(config.entity, 'friendly_name') | replace('Switch-Control_', '') }}
            toggle: true
            active: "{{ is_state(config.entity, 'on') }}"

which still fails for the static secondary_info information is just way too complicated compared to a native bulk rename like

bulk_rename:
  - from: "Battery Level" # simple string replace (note: "to" is not required if you want to remove string)
    to: "sensor"

(https://github.com/maxwroc/battery-state-card#entity-filtering-and-bulk-renaming).

bcutter commented 1 year ago

Meanwhile I managed to almost rebuild my use-case used in this issue, at last by

Unfortunately, still:


Full card with default auto-entities:

type: custom:collapsable-cards
title: 🔲 Übersicht Switch-Controls (bis 2023-01-09 - STANDARD ohne Bulk Rename)
defaultOpen: desktop-only
buttonStyle: 'font-size: medium'
cards:
  - type: custom:auto-entities
    card:
      type: entities
      title: null
      state_color: true
      show_header_toggle: false
    entities: null
    filter:
      include:
        - entity_id: automation.switch_control*
          options:
            secondary_info: last-triggered
      exclude:
        - name: zzzOLD*
    show_empty: true
    unique: true
    sort:
      method: last_triggered
      reverse: true

Template based auto-entities with "bulk" renaming the hard way:

type: custom:collapsable-cards
title: 🔲 Übersicht Switch-Controls
defaultOpen: desktop-only
buttonStyle: 'font-size: medium'
cards:
  - type: custom:auto-entities
    card:
      type: entities
      title: null
      state_color: true
      show_header_toggle: false
    entities: null
    filter:
      include:
        - entity_id: automation.switch_control*
          options:
            secondary: >
              Vor {{ state_attr(config.entity, 'last_triggered') | relative_time
              | replace ('seconds','Sekunden') | replace ('minutes','Minuten') |
              replace ('hours','Stunden') | replace ('days','Tage') | replace
              ('weeks','Wochen') }}
            type: custom:template-entity-row
            name: >
              {{ state_attr(config.entity, 'friendly_name') |
              replace('Switch-Control_Switch', '') }}
            toggle: true
            active: '{{ is_state(config.entity, ''on'') }}'
            card_mod:
              style:
                state-badge:
                  $: |
                    ha-state-icon { color: #ffc107 !important;}
      exclude:
        - name: zzzOLD*
    show_empty: true
    unique: true
    sort:
      method: last_triggered
      reverse: true

So, guys: templating just to get rid of text in the entities is NOT AN OPTION! I only discovered those 3 pointed disadvantages. I still encourage smart people to implement a bulk rename option DIRECTLY in auto-entities as initially requested by @RoboMagus.

I mean, the last update brought so many small improvements (including useless ones like the and operator :-) ), can we please focus on this feature?

thomasloven commented 1 year ago

I just had a flash of inspiration!

Here's a bit of yaml that displays every entity in the Kitchen area but removes the first word in its name:

type: custom:auto-entities
filter:
  include:
    - area: Kitchen
card_param: input
card:
  type: custom:auto-entities
  card:
    type: entities
  filter:
    template: |
      {% set ns = namespace(retval=[]) %}
      {% for e in config.input %}
        {% set ns.retval = ns.retval + [
          {
            "entity": e.entity,
            "name": (state_attr(e.entity,"friendly_name").split()[1:] | join())
          }
        ] %}
      {% endfor %}
      {{ ns.retval }}
igorsantos07 commented 1 year ago

Another reason why the custom:template-entity-row trick doesn't work in all scenarios: it depends on the final card accepting those custom rows - glance, for instance, doesn't 🤷

lichenophile commented 1 year ago
        "name": (state_attr(e.entity,"friendly_name").split()[1:] | join())

I've altered part of this line to [3:] to account for my devices having more than one word in it's name (such as Kotatsu Heater Plug). However I am scratching my head as to how to deal with entities having spaces in the remaining name, eg:

image

Any advice?

bcutter commented 1 year ago

No I don't. It just proves one more time this is way to complicated. Out of the box is still the way to do this, saving so many people so much time.

RoboMagus commented 1 year ago

@lichenophile, For most uses of removing the common friendly name part of auto-entities I've setup a decluttering-card (See example below). But use of this string replacement could be altered to your usecase 😉.

wifi_plug_card:
  card:
    type: custom:vertical-stack-in-card
    title: '[[name]]'
    cards:
      - type: entities
        entities:
          - type: custom:auto-entities
            card:
              type: custom:fold-entity-row
              padding: 0
              head: 
                type: section
                label: Info
            filter:
              include:
                - entity_id: 'sensor.[[entity_part]]*'
                  options:
                    type: custom:template-entity-row
                    name: "{{ state_attr(config.entity, 'friendly_name') |  replace('[[trim_name]]', '') | replace('_', ' ') }}"

Which is then used like this: Where trim_name is the common part of the friendly name that you'd want to remove for all entities.

      type: custom:decluttering-card
      template: wifi_plug_card
      variables:
        - name: TV Plug
        - trim_name: "NEO Coolcam 2"
        - entity_part: neo_coolcam_2
igorsantos07 commented 4 months ago

Sorry to bother once again, but... Why is it so hard to implement this feature? The only response from the maintainer came two years after the request, and it was a very complex (and dirty) templating workaround. One more year has passed so far - I know this is open source, people are busy and all, but: why?

I mean, isn't it similar to what's done in the Battery State Card?

This is paramount for a clean dashboard with a warnings card that doesn't freaking blink and lags whenever a device changes state.

bcutter commented 4 months ago

I bet this one will still exist 3 more years.

I'd even pay someone to implement this. Others too, I'm sure about that.

Absolute killer feature. Man that would finally boost all my dashboards MASSIVELY.

So frustrating sitting and waiting, looking that there's a probably easy to adopt (copy & paste) solution someone "just" needs to implement here...

FoxxMD commented 1 month ago

@lichenophile add a separator string to the join() function IE join(' ')

"name": (state_attr(e.entity,"friendly_name").split()[1:] | join(' '))
deadsmiily commented 3 weeks ago

You can change the name of the Entity if you go to "filters" -> options -> add: name:

Screen01

bcutter commented 3 weeks ago

You can change the name of the Entity if you go to "filters" -> options -> add: name:

Screen01

Not sure if either I don't get your solution or you didn't get the issue.

Renaming one entity as proposed does not fit the requirement of renaming many entities, does it?

deadsmiily commented 3 weeks ago

You can change the name of the Entity if you go to "filters" -> options -> add: name:

Screen01

Not sure if either I don't get your solution or you didn't get the issue.

Renaming one entity as proposed does not fit the requirement of renaming many entities, does it?

You are absolutely right. I misunderstood the threat, sorry.

igorsantos07 commented 2 weeks ago

And here we are again, spending hours and hours battling with Jinja's restrictive templates (you can edit anything BUT a dict) to try to edit a freaking dict... My objective is to feed further options to the resulting card without having to re-type everything, or having to configure options inside the terrible JSON-like syntax from the template.

Anyone has any guess on why this doesn't work? The resulting string in Dev Tools > Template seems to be the same as @thomasloven's comment, which rewrites the whole dict.

type: custom:auto-entities
card_param: input
card:
  type: custom:auto-entities
  filter:
    template: |
      {% set ns = namespace(entities=[]) %}
      {% for e in list %}
        {% set ns.entities = ns.entities + [
          dict(e.items(), name=(
            state_attr(e.entity,"friendly_name")
            |replace('CPU percent', '')
            |trim
          ))
        ] %}
      {% endfor %}
      {{ ns.entities }}
  card:
    type: entities
filter:
  include:
    - entity_id: '*_cpu_percent'
      integration: hassio

Other template tries I made which also have the same result:

{% set ns = namespace(entities=[]) %}
{%- for e in list -%}
  {%- set entry = e|items|list -%}
  {%- set entry = entry + [("name",state_attr(e.entity,"friendly_name")
        |replace('CPU percent', '')
        |trim
  )] -%}
  {%- set ns.entities = ns.entities + [dict.from_keys(entry)] -%}
{%- endfor -%}
{{ ns.entities }}

I also tried namespace(**e) and go from there, which would be more natural in Jinja... But then it seems auto-entities doesn't accept a list of Namespaces as entities list (sort of expected, I guess?) and I found no way to turn a namespace into the usual dict.

Either result seems to be valid, as both respond true to is mapping and trying ns.entities.__class__.__name__ causes a complaint that it's unsafe to access "class" from... "dict".