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

Problems with "hours_to_show" = float value (particularly < 1.0)

Open QkulleQ opened this issue 6 years ago • 17 comments

I would like to be able to show 5 min cpu load graphs. But this means the hours_to_show option should be of type real number (0.083333) instead of integer. Could this be made possible perhaps? Love this very nice card btw :)

QkulleQ avatar Oct 22 '19 13:10 QkulleQ

I actually think this should already possible, If I remember correctly I removed the integer check a while back, but there were some issues with the tooltip timestamps back then when hours_to_show < 1, but I think that should be fixed now as well.

A config like this should give you a data point for each minute.

hours_to_show: 0.083333
points_per_hour: 60

Give it a shot and if it works we could probably update the docs.

kalkih avatar Oct 22 '19 13:10 kalkih

We could do something as follows:

  • instead of hours_to_show have a setting timeframe_to_show
  • user should be able to specify unit after the number e.g. 1h, 5m, 7d
  • the default option would stay as hours (when there is no unit)
  • we could make this setting backward compatible - so take hours_to_show if it is present (but remove it from documentation)

The above should be fairly simple, right? I'd like to have such option for "point_per_hour", though it can be harder to implement.

@kalkih I can work on it next weekend as long you like the idea

maxwroc avatar Oct 22 '19 13:10 maxwroc

Sure, that would be great and improve usability. As you said points_per_hour, is tougher, not sure how we would go about changing it, will have to think about that one. 🤔

Something like points_per_unit maybe, but you would want to be able to specify a different unit than the one in timeframe, so maybe format like this: 6/h, 10/m, 1/d etc... ?

kalkih avatar Oct 22 '19 14:10 kalkih

@kalkih hours_to_show: 0.083333 is working! But the graph is plotted from left to right somehow (current time is on the left):

1 2 3

Also the time is written backwards (and without seconds): 5

Thanks so far, I can live with the small issues!

QkulleQ avatar Oct 22 '19 14:10 QkulleQ

@kalkih yes I was thinking about something like this as you suggested 10/h etc

@QkulleQ I think graph is plotted correctly it is just the time which is shown not correct. Possible that I have introduced this bug recently as I remember I was adjusting this time by reducing the val by one min. Can take a look on the end of the week.

maxwroc avatar Oct 22 '19 15:10 maxwroc

@maxwroc there's definetely something wrong with the timestamps. For an individual point the displayed time is changing every minute, like below snapshots. After a minute the same point is displayed with a different timestamp:

6 7

@QkulleQ I think graph is plotted correctly

Are you sure? The first graph of that post is the oldest snapshot. Snapshots 2 and 3 were taken after the first one. The newer points on those snapshots are added on the left side. Shouldn't that be on the right side?

I think this behavior is only happening with values below 1 for the hours_to_show option. For example the Gas Consumption graph has a 24 hour value. Here is the same graph somewhat later, new points are added to the right:

8

(BTW. notice the timestamp of the point has changed again)

QkulleQ avatar Oct 22 '19 16:10 QkulleQ

Yeah, there's definitely something funky going on when going below 1 hours_to_show. The timestamps and the graph is calculated separately and both seem wrong so probably more than one bug.

Another issue is that the graph only update/re-render when the entity state change, and in smaller timeframes like this it's def an issue, unless the sensor entity updates very frequently. We have the update_interval option that could solve it, but that requires the user to actually set it.

The timestamps does however update on every card re-render.

kalkih avatar Oct 24 '19 01:10 kalkih

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. If this is still an active issue, please let us know!

stale[bot] avatar Feb 07 '22 01:02 stale[bot]

The issue is stalled. There is no any reaction from the topic starter. I cannot confirm the issue: image

type: custom:mini-graph-card
entities:
  - entity: sensor.cleargrass_1_pm25
    color: green
    show_state: true
    show_points: true
hours_to_show: 0.25
points_per_hour: 120
aggregate_func: last
update_interval: 0
show:
  state: true
  points: true
  extrema: true
  name: false
  icon: false
line_width: 1
hour24: true
lower_bound: ~0
smoothing: false

ildar170975 avatar Feb 10 '22 22:02 ildar170975

Still an active issue, got it! Removing stale label.

stale[bot] avatar Feb 10 '22 22:02 stale[bot]

Reopen the issue! Reproduced the problem: image The code is provided above.

ildar170975 avatar Feb 10 '22 22:02 ildar170975

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. If this is still an active issue, please let us know!

stale[bot] avatar Apr 12 '22 17:04 stale[bot]

I think, the changing timestamp could just be because the binning is not fixed (e.g. start of minute until end of minute). This is only the case, when using group_by. If group_by is not used, the data points are calculated for bins, which constantly change, i.e. bins of equal size (1/n_points_per_hour) from now...

I suspect that the reversed order in which the times are shown is just a display/rounding issue. Maybe... But I haven't investigated.

akloeckner avatar Jan 27 '24 21:01 akloeckner

Interesting that now I managed to reproduce the glitch with hours_to_show > 1 and "integer":

image

type: custom:mini-graph-card
entities:
  - entity: sensor.xiaomi_cg_1_pm25
    color: green
    show_state: true
    show_points: true
hours_to_show: 3
points_per_hour: 120
aggregate_func: last
update_interval: 0
show:
  state: true
  points: true
  extrema: true
  name: false
  icon: false
line_width: 3
hour24: true
lower_bound: ~0
smoothing: false

although earlier it was reported with values < 1...

ildar170975 avatar Jan 27 '24 21:01 ildar170975

You're also asking a lot: 120 points per hour is less than a minute, which seems to be the resolution of the interval display. 😆 Still... Or should just show the same time twice. 🤔

akloeckner avatar Jan 27 '24 23:01 akloeckner

Just to have the info here: this is where the magic happens: https://github.com/kalkih/mini-graph-card/blob/af01df1e2a68cbdd367cf8e27ada26ea8f41d83b/src/main.js#L528

And there's some condition on points per hour and hours to show. So, this might have it's flaws. But I cannot look into this deeply right now...

akloeckner avatar Jan 27 '24 23:01 akloeckner

120 points per hour is less than a minute, which seems to be the resolution of the interval display.

The sensor is updated every 30 sec.

Or should just show the same time twice.

This, I think.

ildar170975 avatar Jan 28 '24 00:01 ildar170975

:tada: This issue has been resolved in version 0.12.1 :tada:

The release is available on GitHub release

Your semantic-release bot :package::rocket:

github-actions[bot] avatar Mar 20 '24 19:03 github-actions[bot]