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

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

Closed
QkulleQ opened this issue Oct 22, 2019 · 18 comments
Closed

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

QkulleQ opened this issue Oct 22, 2019 · 18 comments
Labels
bug Something isn't working released

Comments

@QkulleQ
Copy link

QkulleQ commented Oct 22, 2019

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 :)

@kalkih
Copy link
Owner

kalkih commented Oct 22, 2019

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.

@maxwroc
Copy link
Contributor

maxwroc commented Oct 22, 2019

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

@kalkih
Copy link
Owner

kalkih commented Oct 22, 2019

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... ?

@QkulleQ
Copy link
Author

QkulleQ commented Oct 22, 2019

@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!

@maxwroc
Copy link
Contributor

maxwroc commented Oct 22, 2019

@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.

@QkulleQ
Copy link
Author

QkulleQ commented Oct 22, 2019

@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)

@kalkih
Copy link
Owner

kalkih commented Oct 24, 2019

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 kalkih added enhancement Something that can be improved bug Something isn't working feature request New feature or request labels Oct 26, 2019
@stale
Copy link

stale bot commented Feb 7, 2022

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 stale bot added the stale Stale issue - closed due to inactivity label Feb 7, 2022
@ildar170975
Copy link
Collaborator

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

@stale
Copy link

stale bot commented Feb 10, 2022

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

@stale stale bot removed the stale Stale issue - closed due to inactivity label Feb 10, 2022
@ildar170975
Copy link
Collaborator

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

@ildar170975 ildar170975 reopened this Feb 10, 2022
@ildar170975 ildar170975 changed the title Feature request: hours_to_show as real number Problems with "hours_to_show" = float value (particularly < 1.0) Feb 11, 2022
@ildar170975 ildar170975 removed enhancement Something that can be improved feature request New feature or request labels Feb 11, 2022
@stale
Copy link

stale bot commented Apr 12, 2022

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 stale bot added the stale Stale issue - closed due to inactivity label Apr 12, 2022
@ildar170975 ildar170975 removed the stale Stale issue - closed due to inactivity label Apr 12, 2022
@akloeckner
Copy link
Collaborator

akloeckner commented Jan 27, 2024

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.

@ildar170975
Copy link
Collaborator

ildar170975 commented Jan 27, 2024

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...

@akloeckner
Copy link
Collaborator

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
Copy link
Collaborator

Just to have the info here: this is where the magic happens:

setTooltip(entity, index, value, label = null) {

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...

@ildar170975
Copy link
Collaborator

ildar170975 commented Jan 28, 2024

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.

akloeckner added a commit to akloeckner/mini-graph-card that referenced this issue Jan 28, 2024
* basically: use milliseconds in constants rather than fractions of hours
* also remove strange intervall size of n_points if hours < 1 and points/hour < 1
* also use 1 minute offset for end only when group_by, because that is cosmetics actually

fixes kalkih#181
github-actions bot pushed a commit that referenced this issue Mar 20, 2024
## [0.12.1](v0.12.0...v0.12.1) (2024-03-20)

### Bug Fixes

* tooltip interval start could be after end ([#1065](#1065)) ([930ee39](930ee39)), closes [#181](#181)
Copy link

🎉 This issue has been resolved in version 0.12.1 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working released
Projects
None yet
Development

No branches or pull requests

5 participants