Support is not there yet, but I’ve actually implemented it earlier today and it will be in the next release.
HI,
could it be Im missing out on an option, but my legend is unreadable because of the horizontal display. Would like to show the sensor names, but listed vertically…
if not yet possible, please consider adding that?
2 things: in your readme under entities object you have entities as option for multiple entities lists, while it should be entity:
secondly, if I use show state for a entities list, which state does it show?
and, adding to @jimpower remark about second info: it shows the same more info for all entities in my list …
This card is not meant to be a replacement of the history-graph
but rather a complement to it. There are many use cases where this card doesn’t work well, use cases it simply wasn’t designed for, plotting 5+ entities being one of them, but rather than implementing a hard limit, I left it up to the user to decide.
However, with that said, the legend could definitely scale better, I’ll see what I can do about it, thanks!
The first entry. But as discussed a few posts above, a show_state
option in the entity object would be nice. Would also enable showing multiple states at once…
This has been addressed, see one post above yours.
Not sure, hard to tell when I don’t have access to the sensor data, but I might have an idea on how to fix it.
The graph itself is actually correct but the timestamps are invalid, I’ve fixed this bug and the fix will be available in the next release. I basically forgot to invert the offset so right now it does (time - -offset), instead of (time - offset)
Great card, thanks!
Will you share this code? Do you use more than one graph-card card here?
You’re right, it must have been my sensor data because it is ok now…
Good to know, most likely caused by history entries with unknown state, will fix this by ignoring NaN entries when calculating min/max.
It’s actually already done in the graph calculations, but must have missed it when calculating the extrema!
It is one of the options
show:
extrema: true
Much better if you read the docs that way tou get to see all the options and don’t run the risk of me having made a mistake
NEW RELEASE v0.2.1
Including mostly fixes but also a few new additions such as support for displaying multiple states and 24 hour time format.
Changelog
-
Added: New
hour24
option to choose time format between 12-hour/24-hour clock -
Added: Support for showing multiple sensor states, see new
show_state
option for the entity object (#33) -
Added: Ability to press/click on entities in the graph legend to bring up their “more info” dialog (#31)
-
Fixed: Responsive design of the graph legend
-
Fixed: NaN values in extrema (#34)
-
Fixed: Extrema not rendering (#32)
-
Fixed: Times on points going backwards (#30)
It seems a bit churlish to ask for such a small (and maybe niche) change in such a great card but would it be possible to do something about the bottom left corner being cut off when using labels
in a card with rounded corners using card-modder?
Maybe have the min. value optional? Or remove the - (which would help if the min. value was only one digit).
Or, my preferred option would be to shift the whole thing including the y-axis over to be where the left side of the graph is? I think this would be more aesthetically pleasing even without rounded corners.
Just my thoughts, no big deal though and thanks again for a great card.
HI @kalkih
I’ve run into severe performance issues ( spontaneous restarts, resource depleting, frontend freezes…) using your card and the power-wheel card alongside each other. Having tested the power-wheel card on its own works much better now, since @gurbyz changed things in his card. Would you please check this post by @gurbyz, the author of the power-wheel-card, to see if anything familiar could be done with the mini-graph-card? Thanks for having a look!
somehow I have trouble gating the graph to show… Ive a few others that work, so must be me making an editing error, but Ive developed a blind spot for now…
would anyone please check for me what I am missing, as you can see, ive tested the various show options, but they don’t make any difference at all:
- type: 'custom:mini-graph-card'
name: 'Energie: verbruik - levering'
entities:
- entity: sensor.netto_verbruik
name: Netto verbruik
- entity: sensor.calculated_bruto_verbruik
name: Bruto verbruik
- entity: sensor.zp_actuele_opbrengst
name: Solar production
height: 100
line_width: 4
font_size: 75
# show:
# labels: true
# extrema: true
# fill: true
# points: true
# state: true
my sensors are valid, as seen in the regular glance card:
- type: glance
title: Energy flow
show_header_toggle: false
entities:
- sensor.netto_verbruik
- entity: sensor.calculated_bruto_verbruik
name: Bruto verbruik
- entity: sensor.zp_actuele_opbrengst
name: Solar production
Thanks, to be honest the labels look like **** even without border radius right now.
Please, if you have time, open an issue in the GitHub repo, that way I won’t forget the request.
Okay, yes I’ve been utilizing the shouldUpdate function in LitElement since the initial release of this card, meaning the card is only updated when changes are detected to entities used in the card.
Performance issues could still occur however, especially if you are using several heavily configured cards in the same view.
This particular card can be quite demanding because it has to compute history data, some sensors updates very regularly and could contain 10s/100s of history entries per hour of history. All this history data then has to be computed in order to render the graph. This becomes especially demanding when the card is configured with many entities or with a high hours_to_show
.
Think of a card, containing five sensors with each sensor being updated say 60 times an hour, with hours_to_show
set to 168 (one week), that would result in 30240 history entries. Now, think if you have five similar cards in the same view…you get the point
The problem is most likely caused by a delay when fetching the history from the backend, I’ve experienced that it sometimes can take a while or even timeout completely when fetching the history, especially when being on a bad connection and/or when having a lot of cards all fetching history.
You can edit the mini-graph-card-bundle.js file, and modify the div inside function _templateObject17()
I modified it from:
<div class='graph__labels flex'>
to:
<div class='graph__labels flex' style='padding-left:10px'>
Then you have to save, increase the js version in ui-lovelace and thats it.
You probably have to put maybe 20px instead of 10, try it out.
Here is mine (i have also removed the decimals from the labels cause i’m not interested in them)
@kalkih - Man, great work, these cards look awesome.
I have one question tho, does the live color line works ? (the option with line_color_above and below)
Cause i tried to set one, and the only color displayed is yellow:
- type: custom:mini-graph-card
name: Outside temperature history
icon: mdi:temperature-centigrade
animate: true
show:
labels: true
decimals: 1
entities: sensor.outside_temp
line_color_above:
- value: 0
color: '#c9ffff'
- value: 10
color: '#ede071'
- value: 20
color: '#ff8c42'
- value: 30
color: '#ff3c38'
line_color_below:
- value: -1
color: '#66b3ba'
- value: -30
color: "#2f6690"
And this is how it is displayed:
I’d like to be able to use this to show the current and target temperature from a climate entity. I could pull out the values into a template sensor, but could you consider support for doing that direct from the component? i.e. list the climate entity attributes as an alternative to a sensor entity?
Thanks!
Right now that feature changes the color of the whole line based on the current state, this is a limitation by how the graph is rendered right now. We’ve discussed this earlier and it’s possible that in the future the line could be rendered in smaller section making it possible to change color of each section individually.
I don’t think so, sorry.
A template sensor is quite easy to setup and should do the job just fine as you said.