Sorry, I don’t see me adding this.
This is meant to be a minimalistic graph. If you need a more complete graph solution I would recommend sticking with the default history-graph.
Sorry, I don’t see me adding this.
If I set a threshold and I have multiple entity, how will it behave?
Will the same threshold be applied on each entity or just the last will get it? Or none?
One more thing, maybe a bug
show: name: true icon: true state: true graph: line fill: false points: false legend: false extrema: false labels: false name_adaptive_color: true icon_adaptive_color: true entities: - entity: sensor.dark_sky_apparent_temperature name: Apparent Temperature color: '#FFFF00' name_adaptive_color: false icon_adaptive_color: false - entity: sensor.dark_sky_temperature name: Current Temperature color: '#FF5000' name_adaptive_color: true icon_adaptive_color: true
The bar color is taken from the last entity as the “always on top” one, while the name and icon are taken from the first.
As you can see I also tried the adaptive per entity but simply doesn’t work
Can this be fixed?
The threshold is applied to the whole graph and all its entities, unless you override it in the entity config with the
The bar color? not sure what you mean.
The name and icon color is based on the main entity (first in config) unless you hover over another entity’s point in the graph, then it will display the color for that entity.
icon_adaptive_color is not a config option for the entity object, you could remove them from there.
That’s cool, so I can have a static color for an entity and the other one use the treshold!
What I meant is, as per example.
Name and Icon colors are yellow, while I want them to be orange, but if I invert the apparent temperature with the current one, I will have the name and icon in orange and the graph main color in yellow.
Please let me know if that clrify.
I know the adaptive options were not supposed to be there, it was just a blind test
In the hope I could override what I was having as result
on “graph: bar” is it possible to disable the “on mouse over” values? ^^
Oh, I see what you mean now, you could achieve this with a small trick (I think ), try placing the orange entity first in the config and then insert it again as the last entity, should work!
No, not possible.
Ok I will try that workaround but basically will load the graph twice, is that correct?
Regarding the bar thing, ok
It’s an ugly workaround tho because (but I am not 100% sure about this) I think it query the database an extra (unnecessary) time.
Anyway, I achieved my result
There is something I am curious to understand:
This is set to 168 hours, which should provide a week worth of data (points_per_hour: 0.5) but the farest left value is from the 18th, am I missing something or missunderstanding something?
Sure, it’s a essencially a hack, but also the only way to achieve what you want, so I guess you’ll have to consider if the extra query is worth it…
The bar chart has a hard max limit of 96 bars, or else each bar would not be wide enough to be visible (< 1px), so there’s simply not enough space to render more bars than that.
If your hours_to_show * points_per_hour exceeds this limit the graph will automatically try to adjust your settings the best it can. You’ll see a notice about it in the browser console.
I would recommend you to decrease points_per_hour if you want to display a whole week of data.
Thanks for the clarification, I probably didn’t understand the points_per_hour functinality, but still 168x0.5 is less than 96… so… ehm… I am fairly overconfused now
But knowing the operation and the max number I can do some math
If I increase the value a lot (16.25) it looks very nice but still same days showed:
Could be an issue with the graph logic, I’ll check when I get home later.
@SeLLeRoNe, There was indeed an issue with the “max bars” check, I’ve fixed it now and will probably do a new release tonight or tomorrow.
Cool It is not me!! Yeeee!
I seem to be having issues with the font spacing on the latest versions with HA 0.90.1:
Any ideas why it’s gone all wide and weird? Usual fixes tried and failed (cache clear, CSS refresh, etc)
It doesn’t seems to have improved.
Also, can you clarify how to use the points_per_hour?
My undertanding was that smaller the number less points i would have, so less detail per hour, higher the number higher the amount of datapoints in each hour.
So I tried to bring the number to two, presuming it was 2 infos per hour, and did’t make much difference, I brought it up to 12, so to expect a data point each 5 minutes (if the sensor had it I guess) and the graph went way less detailed than expected.
While If I bring it down to 0.4, which by my understanding is a data point each 24h (not exact but close enough) the graph looks “smoother”
What am I missunderstanding?
A bit of letter spacing was added a few updates ago, but yes it looks kinda weird in your screenshot, idk why.
Did you clear cache?
Here’s an example of a week of data
- type: custom:mini-graph-card hours_to_show: 168 # 1 week points_per_hour: 0.083333333333333 # 2/24 = 2 data points per day ...
Yes, that’s exactly how the
points_per_hour, think of it as “how many data points per hour do I want the graph to display?”.
Lower number = fewer data points, smoother looking line.
Higher number = more data points, sharper looking line.
But even with a high value, the graph can’t display more data than what it’s provided with. If the sensor doesn’t update for an hour you’ll end up with a straight line, even if you’ve set
points_per_hour to 2000.
This is most likely the case in your screenshot example, you can see that the graph is actually very detailed (hence the sharp spiky changes) but then there’s no update to the sensor state for a long period of time and you end up with straight lines.
0.4 equals 9.6 data points per 24h. (0.4 * 24 = 9.6).
points_per_hour is set to 0.5 which equals one data point every two hours.
How did you get the day/date (and not just time) in the graph (the ones that shows 2 weeks per day)
It’s now (since two releases ago) visible by default if the graph display more than 24 hours of data.