mini-graph-card: Bug: `points_per_hour` artificially creates "fake" data points

1st request - https://github.com/kalkih/mini-graph-card/issues/366 2nd request - https://github.com/kalkih/mini-graph-card/issues/1038 3rd request for smoothing - https://github.com/kalkih/mini-graph-card/issues/1039

As for points_per_hour per-entity - not ready to create this FR yet. Someone who needs it and have some ideas - is more than welcome to do it.

Closing the issue now. Yet the topic surely may be discussed here.

@filmkorn There are 2 methods to represent a graph between 2 points: – stepline (history-graph); – line (mini-graph-card). The “line” method allows to show nice graphs (especially if smoothed) - but it shows really “fake” data. “Fake” does not mean they are wrong - it only means that these data were not read from a sensor. The “stepline” method shows the exact data read from a sensor.

The mini-graph-card (m-g-c) does not show ONLY exact data read from a sensor (“actual data”). Instead, it creates an array of data - which contains: – either some SUBSET of “actual data” (if points_per_hour < than number of readings), – or an “enriched” SUPERSET of “actual data” (oherwise).

Since m-g-c uses the “line” method - the SUBSET may or may not represent an actual curve accurately, it depends on partucular “actual data”. In your example an interpolated “history graph explorer” for “PM25” is “ugly” since it does not show a “sudden peak”, it is smoothed. In some other cases the SUBSET may reflect an actual trend.

The “enriched” SUPERSET allows to mimic a stepline method. Assume we have a “speedtest” sensor with readings each 3 hours. Showing a graph with the “line” method will give an impression of presence of actual readings every hour/minute - which is wrong. That is why a user may decide to have a high points_per_hour which shows “steplines”.

So, using high points_per_hour is a trick to mimic a “stepline”. But it requires more resources. Probably m-g-c should support points_per_hour per-entity - i.e. to mimic “steplines” for some particular entity.

Imho the best solution could be supporting “actual data” (https://github.com/kalkih/mini-graph-card/issues/366, https://github.com/kalkih/mini-graph-card/issues/126, https://github.com/kalkih/mini-graph-card/issues/538) - along with added “stepline” method (no dedicated FR so far).

---

As for you graphs: For me, m-g-c shows these graphs rather precise (but I would use smoothing: false):

Imho the “history graph explorer” graph is “ugly” since it is not as accurate as history-graph for these particular data.

Updated my previous response with a screenshot of the history (I assume this is equivalent to the history card but makes it easier to adjust the time period).

All I’m saying is that after some more investigation, mini-graph-card does plot the sparse data more accurately than if it was interpolated (see incorrect blue line History Graph Explorer’s default spline interpolation in my previous reply).

This graph is quite ugly.

Then show a standard history-graph for these entities with same hours_to_show. Otherwise how can people understand if a graph is wrong/correct.

Defining a high value (at least equal to a real freq) for points_per_hour is a way of displaying “exact data” (like in history-graph). “Smoothing” - is an opposite goal.