If a point with a zero value is selected - then a wrong state is displayed

[DamianosS]

My weather station measures the amount of rain with a rain counter, which sums up the continuous amount of rain.
For showing the daily rain, I've configured the following card:

type: custom:mini-graph-card
name: Daily Rain
entities:
  - entity: sensor.weather_station_rain_counter
show:
  graph: bar
hours_to_show: 168
aggregate_func: delta
group_by: date
hour24: true
line_color: '#15317E'
labels: true 

The result seems correct:

27.4 mm is the total amount so far.

When hovering over the particular days, the card shows the correct value unless on that day there was no rain. Than it shows the total amount. However, IMHO it should show "0":

Is my configuration wrong, or is it a card issue?

Thanks!

[pleasereset]

Chiming in to say that I can reproduce the issue with a simple graph, no aggregation

type: custom:mini-graph-card
entities:
  - entity: sensor.master_bathroom_illuminance
    name: Lux
line_color: '#e3d5ca'
line_width: 8
font_size: 75
points_per_hour: 2

[bartoszkaminski]

I confirm that I also have this problem:
https://user-images.githubusercontent.com/11258617/186197427-94eecb65-3c86-4812-b0dd-eb1950b12b07.mov

[tomkessler]

I have a similar issue where it's not just 0 values that don't update the number displayed, it's also "small values". I used 0.55 hours of A/C on Saturday 3 Sept, but the number won't indicate that.

Here's the config of the card:

type: custom:mini-graph-card
entities:
  - entity: sensor.hvac_cooling_today
    name: A/C
    color: '#595BBD'
    show_state: true
show:
  graph: bar
  labels: true
  legend: false
hours_to_show: 196
lower_bound: 0
group_by: date
aggregate_func: max
name: Daily A/C Usage
icon: mdi:air-conditioner

The current value is 1.96 hr, yet mousing over the bar which should show 0.55 hr doesn't cause an update.

[Ascathon]

It just shouldn't show any bar at all when 0. First I thought chart was wrong with the shorter bar showing a higher value than the larger bar next to it. But it was the total 24 hour value.
0, no data, no bar. In my utility meter it looks like the was power consumed during the night.

[scharmach]

Not a solution, only a workaround:

color_thresholds:
  - value: 0
    color: '#1c1c1c'
  - value: 1
    color: '#a4958b'

• 0 = colour of the background
• ≥ 1 = colour of the bars

[ildar170975]

Everyone who faced this issue with a line graph and w/o an aggregation - have you tried to set points_per_hour more or equal to a real scan_interval ?

[wizake]

I'm also having this issue with a bar chart :(

[darynwilkinson]

I'm having the same issue with a line chart.

type: custom:mini-graph-card
name: Bedroom
entities:
  - entity: sensor.bedroom_temperature
    name: Current
    show_fill: false
  - entity: sensor.target_temperature_bedroom
    name: Target
    color: '#bc79f2'
    show_state: true
    show_fill: false
  - entity: sensor.heating_demand_bedroom
    show_line: false
    show_state: true
    name: Demand
    color: '#ccffcc'
    y_axis: secondary
show:
  icon: false
  labels: true
  labels_secondary: true
  average: true
  extrema: true
points_per_hour: 2
lower_bound_secondary: 0
upper_bound_secondary: 100

[ildar170975]

There is a bug here.

type: custom:mini-graph-card
entities:
  - entity: sensor.xiaomi_cg_1_co2
    show_state: true
  - entity: sensor.xiaomi_cg_1_pm25
    show_state: true
    y_axis: secondary
show:
  icon: false
  labels: true
  points: true
  name: false
  labels_secondary: true
line_width: 1
smoothing: false
aggregate_func: last
points_per_hour: 120
hours_to_show: 1
lower_bound: ~400
lower_bound_secondary: ~0

Both sensors are updated twice a minute.

When none graph is selected:

When a primary graph is selected (values vary from 400 ppm):

When a secondary graph is selected (values vary 0 .. 1 μg/m³):
for a non-zero point:

for a zero-point - the LAST primary sensor's value is displayed and the secondary sensor's UoM:

Note that the current value for the primary sensor is 689.

[akloeckner]

I do not yet understand fully the logics in this card, so forgive me, if I am stupidly mistaken. I'd also test this myself. But I don't know yet, how to do that. So, here I am, trying to help "offline"...

I browsed through the code and found this line:

mini-graph-card/src/main.js

Line 288 in 8e70381

${this.computeState(isPrimary && tooltipValue || state)}

It looks to me, as if the tooltipValue (which I believe to be the currently hovered-over point) is only displayed if it is "truthy". But 0 is not truthy. Hence, the state is shown. Could this be the cause for this bug?

[darkenbula]

Has this fix been pushed out? I am still getting the same value with zero values showing the max value and not zero

`entities:

• entity: sensor.skye_rainfall
  lower_bound: 0
  hours_to_show: 168
  name: Daily Rain
  line_color: '#3190de'
  aggregate_func: max
  group_by: date
  show:
  graph: bar
  labels: true
  type: custom:mini-graph-card
  `

[akloeckner]

#880 should fix this issue. But we haven't merged it yet.

[ntzb]

@akloeckner unfortunately I don't see that it fixed the issue.
can anyone else verify?

[akloeckner]

Did you download the branch from#880? If that didn't help, I'll have to fix #880. If it does help, I'll just need to merge #880. (I just didn't get around to this properly...)

[ntzb]

sorry, my bad, looks like it was a cache issue, I tried in another browser and it seems to do the job, so thanks!
but I still see something strange in Chrome (which is not replicated in Firefox).

edit: just stupid cache issues

[akloeckner]

Hmm... Maybe, it's the same cache issue?

Because I think the fix should be the same for both primary and secondary graphs. So, if #880 fixes the zero tooltip on the primary graph, I would expect it to fix the zero tooltip for the secondary graph, too. But I might be mistaken.

(Thanks for the feedback on #880 fixing the primary tooltip at least, for you too!)

[ntzb]

yes, same cache issue, sorry about that.
okay so from my testing, your PR seems to solve the issue

[akloeckner]

Ok, thanks for the feedback! I'll try and merge it soon. I just want to get some guidelines straight before that...

[ntzb]

@akloeckner I see you commit on the dev branch.
is there any plan on merging dev to master? or release a dev version?
HACS doesn't list dev branch

[akloeckner]

Yes, my plan was to create a release, now that I have merged all the fixes. But... I will have to understand how that works. :-) That might take some more days, because I guess there is some automated way to do this...

[github-actions]

🎉 This issue has been resolved in version 0.12.0-dev.1 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀

[akloeckner]

I just gave it a try on the dev branch... Great magic. But it has worked, I think. There should be a new pre-release with the latest changes.

[ntzb]

looking good, I'm on the dev release 0.12.0-dev.2
thanks a bunch! also for reviving the dev (beta) builds

[ntzb]

seems like this introduced a new bug (not sure):
https://imgur.com/a9YgO2E
the entity value is ~17% for ~10 minutes, from 5:17 to 5:27 (shown in the history), but the card shows 17% going back until the first point in time.
can anyone reproduce?

[akloeckner]

From how I understand the current - but also the old - code, that should have happened before as well. The first point on the graph is the first data point within the history period. So, 17%. But I might miss some subtlety.

Can you check with an older version of the card, before my change?

[ntzb]

before I saw your post, I updated to dev.3 (from dev.2), and I don't see it anymore.
if I see it again, I'll do as you suggested and post the results

[github-actions]

🎉 This issue has been resolved in version 0.12.0 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀

[adamzimnyy]

I'm on release 0.12.0 and I'm still seeing this issue.

The graph is showing max value from each day:

All of the green bars except the last one are wrong, they are all showing 4.7 which is the first peak value on Mar 8 (there is no data for this sensor before March 8):

[akloeckner]

I think, your seeing a different issue with similar symptoms. Since there is no data before March 8, the code just uses the earliest (I believe) data point also for the missing points in time. That makes sense for continuous data, because the home assistant history only stores data when the state changes. So, it's reasonable to assume the state hasn't changed if there is no data in a given interval. (Although we seem to do this after aggregating over the day, while we should actually do it before aggregating.)

While I acknowledge the result is not correct in your case, it's maybe ok to ignore for now. When - in 11 days - there's enough data, the issue should go away and not come back. 😉

[ildar170975]

There could be another explanation, we probably need more details like a m-g-c code, real db content.
We are trying to investigate the issue by comparing with a standard history-graph.
In general this is correct - but since 2024.3 the history-graph is broken and can show wrong results - for instance, for periods where:
-- the entity has no changes
-- the entity was not created yet
-- the entity's changes were not recorded
i.e. personally me cannot consider history-graph now as a 100% correct proof.

[lottor]

I'm having a similar problem with a water flow graph. The sensor sends updates every 10 seconds but the graph often seems to ignore the zero data. That long flat part in the graph to the right was zero that whole time but it gets graphed at the last non-zero value instead. I've verified the sensor was sending zeros the whole time.

[akloeckner]

I'm having a similar problem with a water flow graph.

I suggest you open a new issue for this, as it seems not the same as the original issue here. It's likely the same issue as adamzimnyy sees.

For troubleshooting, try to set points per hour really high, at least 360. (The aim should be for the first zero value to be in its own averaging time window. The average zero should then carry over to the following period.)