Questions/ideas

[jensrossbach]

Hi @cataseven,

I have some ideas but would like to check if the possible features are already supported or can be realized by existing functionality before creating feature requests.

1. Currently it is possible to change values via the value transform function (value_transform) but from my knowledge it is only possible to access data from the "own" entity and not from any other entity of the same chart. It would be great to also access data from other entities as this would allow to create graphs solely from data of other entities in the chart without a separate "own" entity (kind of virtual entity). For instance, you have 3 graphs in your chart and want to add a fourth graph which represents the sum of the other graphs (or some of the other graphs) without the need to create a helper entity for it. Then it should also be possible to omit a real entity for a graph.
2. It would also be nice to have the Y axis scale adapting when zooming into a chart. From what I observed, the Y axsis scaling always takes the whole chart into account, even if in the zoomed area much less data is visible.
3. When using invert: true the values are inverted on the chart (i.e., positive values are inverted and drawn in the negative area) but in the statistics legend, they are printed as is (i.e., not inverted). On the other side, MIN and MAX statistics are flipped, which is a bit strange. So, for instance if your sensor delivers values from, say 3 to 10, they are drawn in the area from -3 to -10 on the chart (correct) but in the legend, MIN is 10 and MAX is 3. It would be more understandable if MIN is -10 and MAX is -3 (applying the inversion also to the values) or MIN is 3 and MAX is 10 (completely ignoring the inverted flag here).
4. Very low values in a bar chart may lead to very thin bars (just a one pixel line in extreme case), which doesn't look so nice. It would be good if it's possible to define a kind of threshold for values and if they are below, the bar is not drawn.

[cataseven]

Hi @jensrossbach

1. We can do this for 2 entities. But for more than 2 helper will be needed.

For 2 entities please see the part:

    ref_op: add
    ref_entity: sensor.temperature_2

type: custom:statistics-graph-chart-card
show_legend: true
tooltip_match_axis: false
tooltip_order: default
height: auto
show_full_period: true
x_grid_style: dashed
y_grid_style: dashed
entities:
  - entity: sensor.temperature
    show_in_legend: null
    ref_op: add
    ref_entity: sensor.temperature_2
    graph_type: bar
annotations: []
grid_options:
  rows: auto
  columns: 12

[jensrossbach]

Ok, so do you think it's worth to create a feature request? Or don't you plan such extension?

[cataseven]

I think it is not worth it, it will also make the card more complicated. I am trying to improve the card but also we need to keep it clean and simple as much as we can.

Supporting up to 2 entitites and redirect to helpers for above is fair, I think

[cataseven]

2. It would also be nice to have the Y axis scale adapting when zooming into a chart. From what I observed, the Y axsis scaling always takes the whole chart into account, even if in the zoomed area much less data is visible.

I will try to fix this

[cataseven]

3. When using invert: true the values are inverted on the chart (i.e., positive values are inverted and drawn in the negative area) but in the statistics legend, they are printed as is (i.e., not inverted). On the other side, MIN and MAX statistics are flipped, which is a bit strange. So, for instance if your sensor delivers values from, say 3 to 10, they are drawn in the area from -3 to -10 on the chart (correct) but in the legend, MIN is 10 and MAX is 3. It would be more understandable if MIN is -10 and MAX is -3 (applying the inversion also to the values) or MIN is 3 and MAX is 10 (completely ignoring the inverted flag here).

I will also try to fix this on the next update

[cataseven]

4. Very low values in a bar chart may lead to very thin bars (just a one pixel line in extreme case), which doesn't look so nice. It would be good if it's possible to define a kind of threshold for values and if they are below, the bar is not drawn.

I'll solve it slightly differently than proposed. A value threshold would have two problems: it hides real data (you couldn't tell "no data / zero" apart from "small value"), and "small" is different for every sensor and unit, so everyone would have to tune it per entity.

The actual problem isn't the value, it's the rendering: a small value on a large axis collapses into a ~1px sliver. So the fix will be a minimum visual bar height: any non-zero value is drawn at least 2px tall (matching the card's default line/point weights), while zero and missing data still draw nothing. You keep all three visual states, no bar (zero/no data), a 2px stub ("there is a value, but tiny at this scale"), and a normal bar and the tooltip always shows the exact number. No new option needed; it just works for every sensor at every scale.

[cataseven]

@jensrossbach Please see update v4.02