mini-graph-card icon indicating copy to clipboard operation
mini-graph-card copied to clipboard

Graph lines should be drawn in reverse order

Open i00 opened this issue 5 years ago • 18 comments

When drawing my graph three series on it the last series specified gets drawn on top of the others...

I think that this should be the other way around ... so the "primary" appears on top.

i00 avatar Feb 13 '20 22:02 i00

Even better would be a way to manually set the order, for example an "index" property

Mikk36 avatar Jun 19 '20 08:06 Mikk36

+1, until (or if) a graph "drawing order" is supported, can we please get the the first defined entity in the list be "on top" of all the others (i.e. graphed last)? The first entity is the one that gets the official "accent color" in it is counter-intuitive that it gets pushed to the background by the other entities.

In the past, to work around this problem in mini-graph, I used to manually define colors for each entity, and I would use the theme's accent color manually set in the "last entity" graphed which was the one I needed to prioritize so that it overlaps all the others. This triggers a lot of manual work that has to be re-done with every theme change. This would be avoided if the graphing order is reversed as requested here, then one would simply add as "first entity" the one that one needs to prioritize

arigit avatar Apr 25 '21 23:04 arigit

Second this. lease reverse the display order or provide an index-option.

emufan avatar Sep 06 '21 13:09 emufan

I was just looking for this option. I have a graph that displays temperatures, and I'd like the "main" temperature to be displayed as the default "state" value for the graph, so I put it first in the list, but then it gets drawn underneath all the temperatures...

eddyg avatar Sep 14 '21 13:09 eddyg

I wanted this feature too. So I just implemented it. @kalkih can make it available to everyone by merging #658

ricardoboss avatar Oct 13 '21 23:10 ricardoboss

Recap from #658 : the PR provided by Ricardo introduced a order attribute along with the fix to reverse the drawing order. While more options are always better, we have to take into account that the maintainers only have so much spare time to dedicate to this project. If there is sufficient need for an order: key (instead of just making sure that the primary entity appears on top, as would indeed be expected.) we can still consider this, but it's a seemingly simple feature that adds significant complexity in maintainability & increased risk for bugs (as we only have limited capacity available, this is something we'd rather avoid)

This would be avoided if the graphing order is reversed as requested here, then one would simply add as "first entity" the one that one needs to prioritize

To be very clear: Reversing the graphing order to have the primary (first listed) entity on top will happen as part of the next (0.12) update; expected in Q1 this year. (and probably still this month on a beta release).

jlsjonas avatar Jan 18 '22 18:01 jlsjonas

Thanks @jlsjonas for stepping in! it's awesome to hear this is coming in the next major update and that the card is getting dev attention!

arigit avatar Jan 18 '22 21:01 arigit

will happen

Great!.

emufan avatar Jan 19 '22 07:01 emufan

I have been able to replicate this effect using card-mod. While this functionality is still something that should happen (basically either reversing the draw order for the entities, or having the state draw from the last entity rather than the first one), in the meantime here is an example of how to achieve the same result. Posting that workaround here to help out the other people who want this feature.

Basically, just add the card_mod snippet to your mini-graph-card config and then set show_state: true on your last entity (or whatever other entity it is you wanted to have the state rendered from). The show_state: true on the last entity will cause it to show it's state on the right side of the card, and the card_mod snippet will hide the primary state display (allowing the secondary state to move to the left side) and then clean up the left side padding on the secondary state to get it positioned exactly where the primary state used to be at. Here is the example

type: custom:mini-graph-card
name: Downstairs Temperature
icon: mdi:thermometer
card_mod:
  style: |
    .states > .state {
      display: none;
    }
    .states--secondary {
      margin-left: 0 !important;
    }
entities:
  - name: Cooling Target
    entity: climate.downstairs
    attribute: target_temp_high
    smoothing: false
    show_fill: false
    color: blue
  - name: Heating Target
    entity: climate.downstairs
    attribute: target_temp_low
    smoothing: false
    show_fill: false
    color: red
  - name: Current Temperature
    entity: sensor.downstairs_current_temperature
    show_fill: false
    show_state: true
    color: yellow

cryptk avatar Sep 14 '22 22:09 cryptk

Some notes from a duplicating https://github.com/kalkih/mini-graph-card/issues/825:

  1. Graphs should be displayed in opposite Z-order: the last entity = bottommost, the 1st entity = topmost (as already concluded here).
  2. There is a good way to see an order - applying card-mod:
card_mod:
  style: |
    .fill {
      fill: white;
      opacity: 1 !important;
    }

image Whole card's code:

type: custom:mini-graph-card
entities:
  - entity: sensor.mijia_300_1_temperature
    color: blue
    show_state: true
    name: Temp
  - entity: sensor.mijia_300_1_co2
    color: red
    show_state: true
    y_axis: secondary
    name: CO2
name: Climate
card_mod:
  style: |
    .fill {
      fill: white;
      opacity: 1 !important;
    }
show:
  icon: false

ildar170975 avatar Sep 15 '22 02:09 ildar170975

Unfortunately, there is no way to change an order to reversed (last entity = bottommost, the 1st entity = topmost) by card-mod. Elements in svg cannot be re-ordered by z-index. Changes in a code are required.

ildar170975 avatar Sep 15 '22 02:09 ildar170975

To be very clear: Reversing the graphing order to have the primary (first listed) entity on top will happen as part of the next (0.12) update; expected in Q1 this year. (and probably still this month on a beta release).

Reversed z-order is still needed. I was really happy to saw it announced 8 months ago for Q1. Do you have an estimate, when it will come?

emufan avatar Sep 15 '22 05:09 emufan

Noticed this issue here as well, want to have a card with Temperature and humidity with the temperature being the primary element but still the humidity is drawn on top which doesn't make sense. (And want to see Temperature state left and Humidity right so I can't just put them in in reverse order..) would be great to have this working correctly (either reverse everything or make it configurable (stacking order))

github-k8n avatar Jan 29 '23 11:01 github-k8n

This also affects graphs where you have a secondary series, such as displaying night or day. You don't want that first in the legend, but you also don't want it rendered on top, because it's last in the list.

I saw the points on complexity, and I understand that, but there's from what I can see no workaround. I'd take a card-mod workaround, but Ildar's investigation showed this route can't work.

parautenbach avatar Nov 03 '23 09:11 parautenbach

Related: https://github.com/kalkih/mini-graph-card/issues/972 Since we cannot define "indexes" - this issue is about defining the entity for which a state should be shown as "main".

ildar170975 avatar Jan 20 '24 06:01 ildar170975

Related: #972 Since we cannot define "indexes" - this issue is about defining the entity for which a state should be shown as "main".

Already in roadmap for Q1 2022.

To be very clear: Reversing the graphing order to have the primary (first listed) entity on top will happen as part of the next (0.12) update; expected in Q1 this year. (and probably still this month on a beta release).

emufan avatar Jan 20 '24 08:01 emufan

@emufan Please confirm: this is not about adding "indexes" - this about a reversing a graphing order, i.e. processing will depend on a fixed order of entities in a card's code.

ildar170975 avatar Jan 20 '24 08:01 ildar170975

Yes. Confirmed. But as reference above, I think, neither will happen unfortunately. Most probably until a fork from another maintainer.

emufan avatar Jan 20 '24 08:01 emufan