Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Incorrect report in bars vs history-graph #1054

Open
aik opened this issue Jan 14, 2024 · 5 comments
Open

Incorrect report in bars vs history-graph #1054

aik opened this issue Jan 14, 2024 · 5 comments
Labels
question Further information is requested

Comments

@aik
Copy link

aik commented Jan 14, 2024

2 cards reporting the same data differently. The cards are below, the amount of rain is >80mm but the second card says 55.
The rain sensor is an utility meter integrating from a rain gauge, daily. Interestingly, these cards work fine with another utility meter sensor which reports the rain data hourly, there I see the correct bars. What is missing in the second card?

type: history-graph
entities:
  - entity: sensor.daily_rain
type: custom:mini-graph-card
entities:
  - entity: sensor.daily_rain
name: Daily rain
hours_to_show: 168
group_by: date
show:
  graph: bar

Screenshot from 2024-01-14 15-46-05

@ildar170975
Copy link
Collaborator

ildar170975 commented Jan 14, 2024

group_by: date

  1. Why not testing with actual, not aggregated data?

hours_to_show: 168

  1. Why not testing with same hours_to_show (which is 24 for history-graph by default) ?
    Just to minimize possible errors.

On the next step of testing try with "line" graph & increase points_per_hour.

@aik
Copy link
Author

aik commented Jan 16, 2024

group_by: date
1. Why not testing with actual, not aggregated data?

I am not following, do you mean that this group_by is aggregating, or the sensor itself? I want a bar per a day, is this wrong way?

The actual sensor is a ever growing counter of a flipping bucker flips, 1 flip == 0.5mm. Then there is a template sensor to make it millimetres. On top of that there are daily and hourly utility meters. Hopefully this makes sense.

hours_to_show: 168
2. Why not testing with same hours_to_show (which is 24 for history-graph by default) ?
Just to minimize possible errors.

Ok, trying this. But I suspect I just expect something what the card is not designed to do. The sensor I am using is utility meter per day. A couple of days ago it was raining, 25.5mm and this card was showing exactly that at the left top corner. But next day the bar for the day before is 14.48mm.

On the next step of testing try with "line" graph & increase points_per_hour.

"Line" is even more confusing :) It is one dot per day, the numbers are same as with bars when hovering over the dots .

@ildar170975
Copy link
Collaborator

Any issue related to mini-graph-card (MGC) could be either a bug, or a consequence of implementation (undesired effect), or a wrong use, or other user's mistake.
We need to find out.
A possible way of investigating any issues with MGC:

  1. Minimize the card config to make it similar to history-graph (HG) (which we consider as "true").
  2. Compare these graphs.
  3. Add options to MGC one by one to find a possible culprit.

Note: MGC may be same as HG with it's simplest config (step 1) and may be not same with a desired config, it's ok, at least we'll localize the issue.

step 1:
HG: set same hours_to_show: 168.
MGC:

type: custom:mini-graph-card
entities:
  - entity: sensor.daily_rain
name: Daily rain
hours_to_show: 168
points_per_hour: ????
show:
  labels: true

As for points_per_hour - we need to set it at least same as an actual update frequency of the sensor.
And your words "It is one dot per day" are confusing since it does not fit the posted picture:

изображение

In the beginning of the graph I see many readings within an hour.
If you expect one reading a day - then HG is wrong, isn't it?

group_by is aggregating, or the sensor itself

The group_by option is aggregating data. Since you "want a bar per a day" - this is a proper option to achieve it.

The actual sensor is a ever growing counter

For the 1st step of our "investigation" a nature of this sensor is not important.
What could be important is a frequency of a real update of this entity (see above).

@ildar170975 ildar170975 added the question Further information is requested label Jan 27, 2024
@Joern-W
Copy link

Joern-W commented Feb 14, 2024

@aik try adding aggregate_func: max to your bar chart. This did the trick for me.

@akloeckner
Copy link
Collaborator

@aik try adding aggregate_func: max to your bar chart. This did the trick for me.

I also think, this should help. The default aggregation function is 'mean', I think.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

4 participants