Wildcard and filter support

[AleXSR700]

Is your feature request related to a problem? Please describe.
Not a problem. It would just be nice to be able to use wildcards, similar to auto-entities.

e.g.
sensor.*_power

Describe the solution you'd like
Support for wildcards such as
entities: sensor.*_power

and filters such as
area: garden

Describe alternatives you've considered
Using auto-entities card, but not sure if that even works with Sankey card and it would be nicer to have this as an integrated feature.

Additional context

[MindFreeze]

I can see this being useful when defining children but not so much for the main section entities. Unless it is last section with no children and you don't want to define names, colors or any other customizations, which seems kinda edgy.

[AleXSR700]

Well, my first section would e.g. be the sum of all consumers (since I cannot measure the grid directly).
The sum would be sensors.*_power
and then the next section would be the different areas (indoors & outdoors) and then ... wait, I will draw it differently

sensors.*power (wildcard only)
-
indoors & outdoors (wildcard + filter indoor/outdoor)
--
indoors areas and outdoors areas (wildcard + filter area)
-
indoors areas consumers & outdoort areas consumers (wildcard + filter area)

These levels/children would all be created on-the-fly if wildcards and filters were available. Unlike e.g. HA Energy, where you have to manually add each new consumer (which is currently also the case for the Sankey card).

Alternative would be to somehow make it compatible to auto-entities, but I don' see how this would work given the need for multiple levels and children.

[MindFreeze]

But how would you configure the connections in yaml?

Right now each entity has children. If you deifne all entities with sensor.*_power, then I don't see a way to define children per entity without listing them explicitly. And if you list them anyway, the wildcard would be pointless.

[AleXSR700]

This is based on your https://github.com/MindFreeze/ha-sankey-chart#daily-energy-use
So the chart would look similar to that but with my above scheme.

Hope I did not make a logical error (since I cannot test it yet) but I think it would be along the lines of this (with wildcards & filters needed for sections and children.

- type: custom:sankey-chart
  show_names: true
  unit_prefix: k
  round: 1
  wide: true
  sections:
    - entities:                                              #first level with total consumed power
        - entity_id: sensor.*_power       
    - entities:                                              #second level splitting into indoors and outdoors
        - entity_id: sensor.*_power
            filter:
              entity_id: *.*outdoors
          children:
            - sensor.*outdoors            #or better an aka such as  outdoor_sensors
        - entity_id: sensor.*_power
            filter:
              entity_id: *.*indoors
          children:
            - sensor.*indoors
    - entities:                                              #third level splitting into areas
        - entity_id: sensor.*indoors
            filter:
              area: living_room
          children:
            - sensor.*_power_lr          #or better an aka such as  living_room_sensors
                filter: 
                  area: living_room
        - entity_id: sensor.*indoors
            filter:
              area: dining_room
          children:
            - sensor.*_power_dr
                filter: 
                  area: dining_room
        - entity_id: sensor.*outdoors          #which would then be outdoor_sensors if arbitrary names (NOT friendly_name!) instead of entities were possible
            filter:
              area: garage
          children:
            - sensor.*_power_garage
                filter: 
                  area: garage
        - entity_id: sensor.*outdoors
            filter:
              area: garden
          children:
            - sensor.*_power_garden
                filter: 
                  area: garden
    - entities:                                              #fourth level consumers per area
        - entity_id: sensor.*_power_lr
            filter:
              area: living_room
        - entity_id: sensor.*_power_dr
            filter:
              area: dining_room
        - entity_id: sensor.*_power_garden
            filter:
              area: garden
        - entity_id: sensor.*_power_garage
            filter:
              area: garage

Qucik question: can children also be assigned a name rather than an entitiy?
Because ideally for the use with wildcards and filters, the child will have an arbitrary name such as "living_room_consumers" rather than sensor._power_lr.
Because sensor._power_l would in reality be (as decribed above) not a real sensor but rather a filtered wildcard.

[MindFreeze]

This config doesn't make sense to me. I still can't understand how to draw the various connections by looking at it.

It seems you want all the functionality of auto entities + ha groups or templates. This is way way too much. It would be better to ask auto entities to support more complex configurations like for sankey chart.

If you want grouping, use HA templates.

[AleXSR700]

It really just requires wildcards and filters. Plus instead of defining children directly as entities, one would need to define children as given names (like the grid areas of grid cards).
So

- entity_id : sensor.*    #wildcard
     filters:         #filters for the above entity/wildcard   
       area:
       group:
  children: 
    - child1     #instead of the actual sensor entity give them a local label such as child1 or sub1
    - child2

It will be impossible to use auto-entities with the way Sankey is built because auto-entities can only return one set of entities and not one per section.

P.S.: I will try to create a flow chart at home and post a picture of what above code would look like.

[AleXSR700]

So, obviously there are multiple ways to handle this.
My suggestion is

1. allow wildcards
2. allow filters for wildcards
3. use alias for children (one line instead of listing 20 sensors)

It would then look something like this. And if we imagine that each house has e.g. 10 rooms and each room as 10 sensors, then the wildcard + filter + alias approach would reduce the amount of code significantly. Plus, all new sensors would automatically be available. So no additional maintenance after creation.

This would be an example where first we have the sum of all sensors. Then a separation into areas. Then splitting into each areas sensors. All with really simple code if using new approach.
(Again, if you think parts of the approach need changing, that is fine. But I hope this gives an idea of what I mean)

As you can see, current approach is a lot of work if you have e.g. 100 sensors you would like to display, especially given that you have to define the child for every single sensor in the first section.

[haraldpaulsen]

I see the need for this as well. Currently I have
Section 1: Main circuit
Section 2: Circuits 2-5
Section 3: Individual consumers, arranged by circuit. Might be per room in the future

Some sort of wildcards so I could define:

type: custom:sankey-chart
show_names: true
sections:

• entities:
  • entity_id: sensor.maincircuit_power
    children:
    • sensor.circuit2_power
    • sensor.circuit3_power
    • sensor.circuit4_power
    • sensor.circuit5_power
      remaining:
      name: other
• entities:
  • entity_id: sensor.circuit2_power
    children:
    • sensor.kitchen_*_power
  • entity_id: sensor.circuit3_power
    children:
    • sensor.office_*_power
    • sensor.livingroom_*_power
    • sensor.balcony_*_power
  • entity_id: sensor.circuit4_power
    children:
    • sensor.bedroom_*_power
    • sensor.basement_*_power
  • entity_id: sensor.circuit5_power
• entities:
  • entity_id: sensor.kitchen_*_power
  • entity_id: sensor.office_*_power
  • entity_id: sensor.livingroom_*_power
  • entity_id: sensor.balcony_*_power
  • entity_id: sensor.bedroom_*_power
  • entity_id: sensor.basement_*_power

Hope this was understandable.

I will eventually get around to just adding all these by hand.. :-)

[MindFreeze]

This is getting out of hand. Now there's 2 of you :)

I am currently working on version 1.0 of this card and the new code structure will make it easier to add this. But I really don't have much spare time so I don't know when I will get to it.

[AleXSR700]

Until this is added, I created a basic template for myself and thought I would share it. Just copy it to developer tools - templates

{% set sensors = states.sensor | selectattr('entity_id', 'search', 'energy_today') %}
  {% set filtered_sensors = sensors | selectattr('entity_id', 'search', 'energy_today(_\d+)?$') %}
  {% if filtered_sensors %}
{% for sensor in filtered_sensors %}
{{ "- " + sensor.entity_id }}{% endfor %}
{% endif %}

It will create a list of all sensors of type "ENERGY Today" which is the type that the tasmota integration creates (all my power monitoring is running tasmota).

Result type: string
- sensor.fixed_value_consumers_energy_today
- sensor.siemens_sx758x06te_42_energy_today
- sensor.naim_audio_nsub_energy_today
- sensor.light_dining_room_ambient_energy_today_0
- sensor.light_dining_room_ambient_energy_today_1
...

Just adjust as needed :)

Oh, and don't add a line break before the endfor or you will end up with empty lines in between the entities.

If you need a list of entity_ids rather than just a list of entities, simply change code to
{{ "- entitiy_id: " + sensor.entity_id }}{% endfor %}

P.S.: Remember to adjust indentation after copy&pasting into card.