min_bound_range ignores lower_bound

[Tarudro]

min_bound_range ignores lower_bound

[ildar170975]

May I ask you why did you post:

• 3 unrelated screenshots
• a code for a card with no labels shown

?

This

However, when you look at my screenshot, the "Washing Machine" doesn't look like that due to the small value scaling.

is rather unclear.

The issue is a "bug report" for the developer. It should not be a puzzle.

As for min_bound_range question - please read Docs again about this option and compare values "10" & "5.1 + 4.9".
The min_bound_range option is applied "in the end" and define a range. Since you defined the "10" value - you got this unexpected "lower_bound" negative value.

I would suggest to make the following code change (I got no permissions to push it directly):

Changes CANNOT be applied directly. Please create a PR with proposed changes.

[Tarudro]

Sorry, I'm not a native English speaker and couldn't express myself well enough, I guess.

I tried my best to collect all the information and I also, of course, read the documentation and read 'The min_bound_range option is applied "in the end"', but this is exactly what I tried to point out that it doesn't make sense in my point of view and use case. When a lower_bound is applied, this should still be the fixed lower_point, instead of having the range overwrite the lower_point.

But anyway, if this is not understandable or not wanted, please excuse me and don't waste your valuable time.

[ildar170975]

@Tarudro
Currently the card is not fully maintained. Means - not all bugs are being rectified, not all FRs are in progress.
Contributors do what they can do in their available time.

Hence users have to find WORKAROUNDS in cases when something cannot be achieved explicitly.
Tell us what particular goal you need to achieve with these lower_bound etc options.
Probably there is a way around.

[Tarudro]

I totally understand!

My goal is to put the cards in a better relation to each other in regards to the Y axis of the plots and simultaneously set the lower bound to 0, such that the X-Axis basically sticks to the bottom of the card.

For example, even though my air purifier is just idling, the plot looks like it's consuming its maximum power:

To achieve my goal, the "min_bound_range" seams feasible, because I can put multiple cards to a range for let's say 100 and the 2 Watt shown in the picture above should look like that:

But instead, it looks like that:

I hope I've now properly made my problem clear.

I also understand the attributes, I also understand that the range is applied as last attribute, but I thought I can't be the only one that would need a range only to the positive side of Y-Axis.

My proposed code change that I submitted in my first comment would fulfill my requirement.

The code for my cards are like this btw.

- type: custom:mini-graph-card
  icon: mdi:air-filter
  name: Dyson
  hours_to_show: 6
  show:
    extrema: true
    legend: false
    average: true
    fill: fade
  line_width: 3
  lower_bound: 0
  min_bound_range: 100
  points_per_hour: 15
  entities:
    - entity: sensor.dyson_power
    - entity: sensor.dyson_energy_daily
      show_state: true
      show_graph: false

[ildar170975]

Have you tried with upper_bound specified in addition to lower_bound?

[Tarudro]

Thanks for your suggestion. I have, indeed. This is feasible for some devices, but not for all of them.

The benefit of having a min_range is that it still scales correctly when there are very big values coming.
E.g. some appliances are at ~200W most of the times. But sometimes it goes up to 2000W. In that case I would love to keep the flexible axis instead of having it locked to 0-2000W and most of the times it's around 200W and just a tiny plot.

[ildar170975]

1. min_bound_range, lower_bound & upper_bound seem to work as documented.
2. If there are any suggestions about these options - please propose a PR or at least a FR with a detailed description of proposed behaviour.

[Joern-W]

Hi,
I'm struggeling with this as well. My code is:

type: custom:mini-graph-card
entities:
  - sensor.regen_heute
aggregate_func: max
hours_to_show: 120
min_bound_range: 10
lower_bound: 0
hour24: true
points_per_hour: 1
animate: true
group_by: date
icon: mdi:water
bar_spacing: 20
line_color: '#1585e5'
height: 180
show:
  graph: bar
  state: true
  points: true
  labels: true

Note the two lines min_bound_range: 10 and lower_bound: 0

This is the result:

The expected behaviour would be:
The lower bound is always 0, the upper bound is 10 or higher, depending on the data.

I hope, this clarifies the problem.

Regards Jörn

[ildar170975]

Note the two lines min_bound_range: 10 and lower_bound: 0

As it was clearly said in Docs & explained already in this thread - the min_bound_range is applied at the end.
Suggest to not use min_bound_range in your case - the lower_bound could be enough.
Alternatively, use min_bound_range only if you are interested in the fixed minimal range.

This issue will be closed soon.
Described scenarios do not contradict Docs, no alternative solutions were provided in PR (I could agree that the current implementation MAY not cover all users' needs - but there are no PRs from people who need a different behaviour).

[Tarudro]

Hi,

I have proposed an alternative solution, even proposed the source code change.
From my view the documentation covers it, but at the same time it is also unexpected and only specifying the lower bound is also not bringing the desired solution of a fixed y axis scaling.

It could be a very easy change and also updating the docs accordingly would make sense.

However, after pointing it out I really didn’t feel like the feedback is appreciated, so I also gave up.

I don’t have the time to setup a development environment to verify any changes I propose, unfortunately.

If our problems and proposals don’t match your paradigm, just close it, sure.
No hard feelings. Came here with a good intention. And also happy to realize that I’m not the only one.

cheers

[ildar170975]

If our problems and proposals don’t match your paradigm, just close it, sure.
No hard feelings. Came here with a good intention. And also happy to realize that I’m not the only one.

This is not about "don’t match your paradigm".
We have very limited possibilities to maintain the project - I have already explained this to you, sad that have to come back to this again.
Proposals are better to be "proposed" as ready PRs.
Ofc some proposals may be implemented using just a detailed description - but this depends on a particular developer if he/she decides to spend his/her time for this. Sad but true.

Well, I may leave this issue open - but it may not change things.